ASP.Net Forms Authentication is a great way to authenticate users for the application. Microsoft has done a really good job at implementing this to make it simple and straightforward for developers. Forms Authentication allows for a user to enter their user name / password combination for an application and have that validated against a backend data source. There are some built in providers to help make this a pretty seamless and painless process for developers. The basic workflow for forms authentication is:
- User attempts to access a resource (details.aspx).
- Server requires the user to be authenticated and redirects the user to the login page (login.aspx).
- User enters user name and password and submits these to the server.
- Server Validates the credentials and if valid, creates an authentication cookie (most common) and sends it back to the user.
- With valid cookie, user no longer needs to enter a user ...
It was recently announced that there is a vulnerability in ASP.Net Forms Authentication. The vulnerability allows an attacker to assume the identity of another user within the application without the need to know the victim's password. This is a critical vulnerability as it could allow users to execute commands they do not have access to. There are a few requirements that are needed for an application to be vulnerable:
The application must be using Forms Authentication to perform the authentication of each user.
The application must allow the user to control their user name.
The attacker must know, or be able to guess, the username of an existing user.
This vulnerability allows an attacker to impersonate another valid user in the system by tricking the system into creating the forms authentication ticket for the wrong user. Here is how the attack would work:
- The attacker knows the user name of a valid user of the application.
- The ...
It was recently discovered that there was a vulnerability within the ASP.Net Forms Authentication process that could allow an attacker to force a user to visit a malicious web site upon successful authentication. Until this vulnerability was found, it was thought that the only way to allow the Forms Authentication redirect (managed by the ReturnUrl parameter) to redirect outside of the host application's domain was to set enableCrossAppRedirects to true in the web.config file. If this property was set to false, the default value, then redirection could only occur within the current site.
So how does it work? When a user navigates to a page that requires authentication, and they are not currently authenticated, ASP.Net redirects them to the login page. This redirection appends a querystring value onto the url that, once successful login occurs, will allow the user to be redirected to the originally requested page. Here is an example (Assuming that...
There's lots of advice on designing and building secure software. All you need to do is: Think like an attacker. Minimize the Attack Surface. Apply the principles of Least Privilege and Defense in Depth and Economy of Mechanism. Canonicalize and validate all input. Encode and escape output within the correct context. Use encryption properly. Manage sessions in a secure way.
But how are development teams actually supposed to do all of this? How do they know what's important, and what's not? What frameworks and libraries should they use? Where are code samples that they can review and follow? How can they test the software to see if they did everything correctly?
There aren't as many resources to help developers answer these questions. Here are the best that I have found so far.
First, there are the OWASP Prevention Cheat Sheets, which provide clear, practical advice...