Attacking Web authorization: Web authorization-Session token security

This excerpt from Chapter 5: Attacking Web Authorization of "Hacking Exposed Web Applications, Second Edition," by Joel Scambray, Mike Schema and Caleb Sima provides authorization and session management technique best practices

Hacking Exposed Web Applications, Second Edition

Joel Scambray, Mike Shema, and Caleb Sima 

520 pages; $49.99


In this excerpt from Chapter 5: Attacking Web Authorization of Hacking Exposed Web Applications, Second Edition, authors Joel Scambray, Mike Schema and Caleb Sima provide seven best practices information security practitioners can use to prevent Web authorization attacks. 

Here is a synopsis of authorization-session management techniques best practices:

  • Use SSL. Any traffic that contains sensitive information should be encrypted to prevent sniffing attacks.
  • Mark cookies using the "Secure" parameter of the Set-Cookie response header, per RFC 2109.
  • Don't roll your own authz. Off-the-shelf authorization features, such as those that come with Web application platforms like ASP.NET and PHP that we will discuss shortly, are likely to have received more scrutiny in real-world environments than anything developed from scratch by even the largest Web app development shops. Leave the security stuff to the professionals and keep focused on your core business. You'll suffer fewer vulnerabilities for it; trust us.
  • Don't include personally sensitive data in the token. Not only does this lead to session hijacking (since this data is often not really secret—ever tried finding someone's home address on Google?), but if it's disclosed, the user is out more than just some randomly generated session ID. The attacker may have stolen their government ID, secret password, or whatever other information was used to populate the token.
  • Regenerate session IDs upon privilege changes. Most Web applications assign a session ID upon the first request for a URL, even for anonymous users. If the user logs in, then the application should create and assign a new session ID to the user. This not only represents that the user has authenticated, but it reduces the chances of eavesdropping attacks if the initial access to the application wasn't conducted over SSL. It also mitigates against session fixation attacks discussed earlier in the chapter, where an attacker goes to a site and gets a session ID, then e-mails it to the victim and allows them to log in using the ID that the attacker already knows.
  • Enforce session time limits to close down the window for replay attacks. Invalidate state information and session IDs after a certain period of inactivity (10 minutes, for example) or a set period of time (perhaps 30 minutes). In addition to relative per-session expiry, we recommend the application set global absolute limits on session lengths, to prevent attacks that attempt to fix session IDs far into the future. And always remember: the server should invalidate the ID or token information; it should not rely on the client to do so. This protects the application from session replay attacks.
  • Enforce concurrent login limits. Disallow users from having multiple, concurrent authenticated sessions to the application. This could prevent malicious users from hijacking or guessing valid session IDs.

Want more from Chapter 5: Attacking Web Authorization? Download the full chapter.

This was last published in August 2006

Dig Deeper on Application attacks (buffer overflows, cross-site scripting)