Full Disclosure mailing list archives
Re: Session data pollution vulnerabilities in web applications
From: Yvan Boily <yboily () gmail com>
Date: Fri, 13 Jan 2006 07:41:10 -0600
There is nothing that you have provided that indicates that this is a new class of vulnerability; this is a classic state management issue. The application is designed to have a password reset function, and in order for that function to behave properly application state must be enforced. Essentially the issue here is that the application is not maintaining its state properly, and the result is that an attacker can force the application to engage in some unplanned functionality. Any web application must leverage some form of state management, and this is pretty easy for most developers to learn. What most developers have difficulty with is the idea that process flow should be enforced; if you have a 'Registration' module with 3 states, and a 'Password Reset' module with 4 states, then any state transition from the Registration module into the Password Reset module should result in the use being forced to start at Password Reset modules initial state. Without a strong means of enforcing the application logic it is trivial to move an application from a known to an unknown state, and this is never a good thing in an application, let alone an application that must make decisions about security based on application state. The reuse of the 'login' session variable in your example is still a case of poor software development, but if application state was properly maintained, then it wouldn't be an issue. On 1/13/06, Alla Bezroutchko <alla () scanit be> wrote:
Frank Knobbe wrote:The proposed fix is -- besides being only specific to this example -- equally flawed. The underlying issue is that you trust user supplied data. When a user supplies a user name for login purposes, you should only use that input to perform a search in your database. If a match has been found, take a *trusted* value from your database, for example an index ID, and carry that in the session object to identify the user.Suppose in my example resetpw3.php instead of doing $_SESSION['login'] = $_POST['login']; did $_SESSION['login'] = $db->getOne("SELECT login FROM users WHERE login=? AND secret_answer=?", array($_POST['login'], $_POST['secret_answer'])); As you suggest it takes a trusted value from the database. It is still does not prevent using register2.php to initialize $_SESSION['login'] and then jump to resetpw4.php and have it use the value to change password.In other words, don't accept any user input (even after proper input validation) and carry it as trusted data in your session object. Don't base further decisions on this data. Since it is user supplied it can not be trusted.Are you saying that user supplied data should never ever be stored in the session? Where do you suggest to keep the data that needs to be passed between different pages in the application? Say you have a form that is filled in in several steps, each step being a separate page. Where would you store the data that the user entered to have it all available on the last page? I can only think of carrying it around in hidden form fields, and this is not always possible.Your example is further flawed in that it allows the change of a password without being properly authenticated. Just having a valid 'login' session object present doesn't indicate that the user is authenticated.I think it does, if 'login' session object is only ever set by the authentication procedure after verifying user's credentials. I believe the usual approach to authentication in web applications is to check user's credentials and then store something in the session that indicates that the credentials were correct. Usually it is something like a user ID or an object or JavaBean storing user information. Then every pafge that needs to check auth just checks if the session object is present and valid. How do applications that you encounter check if the user is authenticated?I really, really hope this was just an example you made up, and not something you actually saw being used. If so, go back to that web site with a clue-by-four and give it a few whacks.I work for a company that does penetration testing, vulnerability assessments, and stuff like that. The contracts we usually sign do not authorise us to apply blunt instruments to customers' web sites. :) This particular example is made up. Giving real ones would violate non-diclosure agrements. It is similar to the real ones in the way that it has the same problem - one storage location is used to keep both trusted and untrusted data. I used the password reset example because the security implications are clear and one don't need application specific context to understand it. The bug does not have to do anything with authentication as such. And, in case you are wondering, the real ones were just as bad. :) Alla. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
-- ____ ygjb Computer Science is no more about computers than astronomy is about telescopes. E. W. Dijkstra
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Session data pollution vulnerabilities in web applications Alla Bezroutchko (Jan 12)
- Re: Session data pollution vulnerabilities in web applications Frank Knobbe (Jan 12)
- Re: Session data pollution vulnerabilities inweb applications Dave Korn (Jan 12)
- Re: Re: Session data pollution vulnerabilities inweb applications Frank Knobbe (Jan 12)
- Re: Session data pollution vulnerabilities in web applications Alla Bezroutchko (Jan 13)
- Re: Session data pollution vulnerabilities in web applications Yvan Boily (Jan 13)
- Re: Session data pollution vulnerabilities in web applications Frank Knobbe (Jan 13)
- Re: Session data pollution vulnerabilities inweb applications Dave Korn (Jan 12)
- RE: Session data pollution vulnerabilities in web applications Keenan Smith (Jan 16)
- <Possible follow-ups>
- Re: Session data pollution vulnerabilities in web applications mailinglist mailinglist (Jan 12)
- Re: Session data pollution vulnerabilities in web applications Frank Knobbe (Jan 12)