Common Topics

Recent Articles

Another way an attacker might steal the SESSIONID is to use a cross-site scripting (XSS) attack. The injected script simply accesses the cookie and sends it to the attacker. Another cookie flag called HttpOnly can protect against this attack, as it tells the browser not to allow scripts to access the SESSIONID. While most browsers respect the HttpOnly flag, many development environments do not yet make it easy to set. You may have to set your own cookie header something like this:

Avoid that URL re-write

Back in the early days of the web, the US Government (wrongly) concluded that cookies were evil and they banned them. Developers quickly came up with a workaround that involved including the SESSIONID directly in the URL. Unfortunately, URLs are frequently disclosed via bookmarks, referrers, web logs, cut-and-paste, and more. So the cure was much worse than the disease.

Given the small number of web users that do not allow session cookies and the high risk of SESSIONID exposure, this URL rewriting technique should not be used. Disabling this may not be trivial, as many frameworks fall back to this technique when cookies are not accepted. You can test your environment by disabling cookies and browsing your site.

Change SESSIONID on login and logout

One creative way for attackers to steal SESSIONIDs is to grab them before the user logs in. For example, imagine an evil coworker goes to your desk, browses to a sensitive internal application, and writes down your SESSIONID. Then when you come in to work and log in, the SESSIONID is now authenticated, and the attacker can use it to access the application as you.

The solution is to always change the SESSIONID whenever anyone logs in or logs out. This is simple to test for using the alert method described above. Many environments do not support changing SESSIONIDs, so you have to copy anything you need from the old session and put it in a brand new session.

Watch the skies

Even though these problems are easy to identify and relatively easy to fix, many web applications still have them. These issues seriously undermine your overall authentication scheme, preventing compliance with any application security standard, including the PCI. So protect your users and make sure your application doesn't make it easy for the bad guys to hijack their sessions. ®