In my last post (Session Fixation & Forms Authentication Token Termination in ASP.NET),
I talked about ways to mitigate two types of session related
vulnerabilities in an ASP.NET MVC 4 application. One of these
vulnerabilities is also present in many WCF web services. In one mode of
operation, WCF web services can authenticate users and issue forms
authentication cookies. Since this token contains an encrypted set of
values and resides only on the client-side, the server cannot choose to
invalidated that token and end a user’s authenticated session. This
allows attackers to continue using stolen tokens, even after the user
logs out.
Continue reading this article on the Security PS Blog: http://blog.securityps.com/2013/07/forms-authentication-token-termination.html
Tuesday, July 9, 2013
Tuesday, June 4, 2013
Session Fixation & Forms Authentication Token Termination in ASP.NET
Read the whole article at the Security PS Blog: Session Fixation & Forms Authentication Token Termination in ASP.NET
ASP.NET applications commonly have one or more vulnerabilities associated with the use of ASP.NET_SessionId cookies and forms authentication cookies. This article briefly discusses those common vulnerabilities and explains one method of mitigating them in an ASP.NET MVC 4 application. Explanation of the exploits are not included, but I linked many of the keywords to OWASP or MSDN articles to provide more details. The security best practices for session cookies and use of sessions in general are provided in the OWASP Session Management Cheat Sheet.
Background
ASP.NET_SessionId cookies and forms authentication cookies can be used alone or together to maintain state with a user’s browser. Each cookie works a little bit differently. The ASP.NET_SessionId cookie value is an identifier used to look up session variables stored on the server-side; the cookie itself does not contain any data. The forms authentication cookie, named .ASPXAUTH by default, contains encrypted data, stored only on the client-side. When it is submitted in a request to the server, it is decrypted and used by custom application code to make authorization decisions... Read More at the Security PS Blog.
ASP.NET applications commonly have one or more vulnerabilities associated with the use of ASP.NET_SessionId cookies and forms authentication cookies. This article briefly discusses those common vulnerabilities and explains one method of mitigating them in an ASP.NET MVC 4 application. Explanation of the exploits are not included, but I linked many of the keywords to OWASP or MSDN articles to provide more details. The security best practices for session cookies and use of sessions in general are provided in the OWASP Session Management Cheat Sheet.
Background
ASP.NET_SessionId cookies and forms authentication cookies can be used alone or together to maintain state with a user’s browser. Each cookie works a little bit differently. The ASP.NET_SessionId cookie value is an identifier used to look up session variables stored on the server-side; the cookie itself does not contain any data. The forms authentication cookie, named .ASPXAUTH by default, contains encrypted data, stored only on the client-side. When it is submitted in a request to the server, it is decrypted and used by custom application code to make authorization decisions... Read More at the Security PS Blog.
Monday, May 20, 2013
Burp Suite Plugin: WCF Binary SOAP Scanner Insertion Point
In my last Burp Suite plugin post, I demonstrated a plugin for viewing and modifying binary encoded WCF SOAP messages. This new post builds on the previous one by allowing Burp Suite's native scanning interface to inject payloads into messages:
Subscribe to:
Posts (Atom)
Posts
