 |
| How to Break Web Software: Functional and Security Testing of Web Applications and Web Services |
By Mike Andrews, James A. Whittaker
240 pages; $31.49
Addison-Wesley |
|
|
|
|
In this excerpt from Chapter 4 of How to Break Web Software: Functional and Security Testing of Web Applications and Web Services, authors Mike Andrews and James A. Whittaker identify session management techniques developers can use to protect against session hijacking attacks.
Session management is a necessity of Web applications, and if done correctly, it can be an effective protection mechanism against a number of attacks, including session hijacking. That's why it's typical for Web developers to utilize sessions, despite their security implications. Here's some advice about doing it right.
Protection of a session needs to focus on the unique session identifier because it is the only thing that distinguishes users. If the session ID is compromised, attackers can impersonate other users on the system.
The first thing is to ensure that the sequence of identification numbers issued by the session management system is unpredictable; otherwise, it's trivial to hijack another user's session. Having a large number of possible session IDs (meaning that they should be very long) means that there are a lot more permutations for an attacker to try.
Developers also need to pay attention to the random qualities (those that are nonsequential and hard to guess) of chosen individual IDs so that an attacker cannot easily determine the algorithm used to generate the session IDs.
Taking care to generate good session IDs is just the beginning. After you've generated the ID, you must protect it, which is a concept called session management. Good session management consists of the following:
- Using cookies for storing session values. Cookies are generally more difficult to modify than hidden fields or CGI parameters. You can protect them by using mechanisms like setting the secure flag (so they cannot be "sniffed" unencrypted on the network). In addition, you can restrict cookies to a particular site or even a section of a site (using the path attribute of the cookie), or set them to expire automatically.
- Not allowing users to choose their own session identifiers. Some session management systems allow users to reactivate their session if they have a valid session ID but it has been expired. There is no good reason why an existing session should be reactivated because a new session can be created with a different session identifier but the same stored state. If an attacker discovers that session identifiers are being reused, he can gather a number of valid ones and have an immediate advantage in a session fixation attack.
|
| More Information |
Want to learn more about state-based attacks and how to prevent them? Download the entire chapter -- it's free.
Visit our resource center for news, tips and expert advice on how to to combat Web application attacks. |
|
|
|
|
- Ensuring that each user gets a "clean" session identifier number with each visit and revisits to your site.
Users should get a new session number each time they visit your site, because that makes the attacker's job of giving them a compromised ID irrelevant. You can check this by comparing the referring page against the URL of the site. If they are different, you should create a new session identifier. However, a downside to this is that it might break the "remember me" and "single-click shopping" that some e-commerce sites use.
- Time-out session identifiers so someone cannot reuse them after a predetermined period of time. Storing session variables on the server allows the Web application to keep track of what sessions have been created and when. If no one has used a session for a specified period (based on user activity or a predefined time), you should expire it. This gives the attacker a smaller window of opportunity to guess (or brute force) valid session identifiers.
- Allowing users to log out and clear their session. When a user logs out, this action should invalidate identification numbers from both the client and the server. Not only should it clear the current sessions, but it should clear all other sessions that the users may have initiated but have failed to log out of because of forgetfulness (browsing away from the site) or some other issue like server failure.
- Utilizing the HTTP referer field to identify multiple clients browsing with the same ID. If the Web application can "track" users through the site and has clear paths of browsing that users follow, it's possible to discover situations where two or more people are using the same identifier. The basic idea is to know the correct page sequence of the site. If a request for a page that should not be accessible is received, then either a URL-jumping attack is in progress, or another user is using the same session identifier and is out of step with the original user. In both situations, the session identifier should be invalidated.
- Ensuring that session cookies are sent only over secure channels to prevent them from being captured in transit. You wouldn't want credit card numbers being sent in clear text across the network, and because session identifiers are indirect references to users' information, you should protect them equally. Because cookies are sent with every request matching a specified domain and path, it's easy for them to be inadvertently sent over a nonencrypted channel where an attacker may be listening. Therefore, you should set the secure flag for all session identifier cookies to ensure that they are sent only over HTTPS.
Even with these precautions, there's the possibility of an attacker discovering a current session ID by "stealing" a cookie through cross-site scripting, so protecting against that attack is a crucial facet of protecting against this one.
Want to learn more? Download the entire chapter here.
