Neither authentication nor session management was considered when the HTTP protocol was invented, because it is a stateless protocol. So, managing these feature over the web can be challenging.
Attacking how a cookie is generated is very difficult to guess, even when a hacker has tons of processing power. A much more applicable attack is to ==investigate how the application uses the cookie.==
- This type of attack doesn’t require understanding how a cookie was generated, but instead focuses on ==accessing and using the cookie== in unpredictable ways
One failure is enough Authentication actually takes place in many other parts of the web application other than the main login page. It is also present when you change your password, update your account information, use the password recovery functionality, answering secret questions, and when you use the remember me option.
- If any of these authentication processes is flawed, the security of all the other authentication mechanisms may be compromised
Authentication and authorization attacks
- directory traversal (path traversal)
- session hijacking
- cracking cookies: crack the session-generation algorithm to predict the next cookie
- forced browsing
cookie related issues:
- Log out of the application, click the back bu on in your browser, and refresh the page to see if you can still access a page in the web application that should require an active session such as an my account page
- Copy and paste your valid session identifier into a text file (so you have a copy of the value) and use it again after logging out. You can use an intercepting proxy to plug in your old session identifier
- Simply walk-away from, or stop using, your browser all together for several hours to test the time-out limits of the application after you’ve received a valid session identifier. It’s all too common to simply have to click OK when it warns you that your session has been terminated when it actually hasn’t.
- Many applications will issue you a cookie when you first visit the site even before you log in. Copy and paste that session identifier into a text file and then log in. Compare the session identifier that was issued to you when you first visited the site and the session identifier you were issued after successfully authenticating. They should be different. If they aren’t, this is a big vulnerability related to session donation
- Log into the same application from two different browsers to see if the application supports dual logins. If both sessions persist, do they have the same session identifier? Is the first session warned that the same account has been logged into concurrently from a different location?