Apache Security - Ivan Ristic [143]
Cross-site scripting attacks
Cross-site scripting attacks (XSS) are the favorite methods of stealing a session token from a client. By injecting a small piece of code into the victim's browser, the session token can be delivered to the attacker. (XSS attacks are explained in the Section 10.6.2 later in this chapter.)
Brute-force attacks
If all else fails, an attacker can attempt to brute-force his way into an application. Applications will generate a new token if you do not supply one, and they typically completely fail to monitor brute-force attacks. An automated script can, in theory, work for days until it produces results.
The use of a flawed session token generation algorithm can dramatically shorten the time needed to brute-force a session. Excellent coverage of session brute-force attacks is provided in the following paper:
"Brute-Force Exploitation of Web Application Session Ids" by David Endler (iDEFENSE Labs) (http://www.blackhat.com/presentations/bh-usa-02/endler/iDEFENSE%20SessionIDs.pdf)
* * *
Session Management Design Flaw Example
As a young web developer, I once designed a flawed session management scheme. It used consecutive integer numbers for session tokens, making session hijacking trivial (well, not quite, since some other attributes of my scheme prevented hijacking, but the story sounds better when I do not mention them). Here is what an attacker could have done:
Log in to get a current session token.
Decrease the number one by one to go through all active sessions.
* * *
Typical session token problems include:
Tokens are short and can be cycled through easily.
Sequential session tokens are used.
Token values start repeating quickly.
Token generation is based on other predictable information, such as an IP address or time of session creation.
Good Practices
To conclude the discussion about session management, here are some best practices to demonstrate that a robust scheme requires serious thinking:
Create a session token upon first visit.
When performing authentication, destroy the old session and create a new one.
Limit session lifetime to a short period (a few hours).
Destroy inactive sessions regularly.
Destroy sessions after users log out.
Ask users to re-authenticate before an important task is performed (e.g., an order is placed).
Do not use the same session for a non-SSL part of the site as for the SSL part of the site because non-SSL traffic can be intercepted and the session token obtained from it. Treat them as two different servers.
If cookies are used to transport session tokens in an SSL application, they should be marked "secure." Secure cookies are never sent over a non-SSL connection.
Regenerate session tokens from time to time.
Monitor client parameters (IP address, the User-Agent request header) and send warnings to the error log when they change. Some information (e.g., the contents of the User-Agent header) should not change for the lifetime of a session. Invalidate the session if it does.
If you know where your users are coming from, attach each session to a single IP address, and do not allow the address to change.
If you can, do not accept users coming through web proxies. This will be difficult to do for most public sites but easier for internal applications.
If you can, do not accept users coming through open web proxies. Open proxies are used when users want to stay anonymous or otherwise hide their tracks. You can detect which proxies are open by extracting the IP address of the proxy from each proxied request and having a script automatically test whether the proxy is open or not.
If you do allow web proxies, consider using Java applets or Flash movies (probably a better choice since such movies can pretend