One security concern that web applications should address is session side-jacking. This is when an attacker intercepts unencrypted cookies (in which session data or identifiers are stored) and impersonates the session of the victim by using those cookies (and therefore session) for himself.
The easiest way to mitigate against this risk is to require your site be accessed via SSL and configuring your session cookies to be transferred only on SSL requests.
However, what if you don’t want all of your pages to be delivered va SSL? If you allow users to visit non-SSL pages, then you have at least three choices:
- Allow the sessions cookie to be present on non-SSL pages, which leaks the session and is vulnerable to session side-jacking
- Have no session on the non-SSL pages, which will “forget” that a user is logged-in until he returns to an SSL page
- Have two sessions — one for secure pages and one for insecure pages.
The third option could be effective, but it seemed like a lot of work, a lot of redundancy, and potential for thinks to get out of sync.
Therefore, I developed a fourth solution:
- Have an insecure session along with a secure signed cookie containing just enough data to “verify” or “confirm” that the insecure session is legitimate.
If the insecure session is side-jacked, the attacker can impersonate the victim on non-SSL pages, but for SSL pages, the attacker will not have the additional secure cookie, and our system can recognize that he is an imposter.
All pages that deliver confidential information or permit important actions should be secured with SSL (which will have the secure cookie), while less critical pages (like a FAQ) page are free to be non-SSL. The session might leak on these non-SSL pages, but an attacker who steals the session would only be able to impersonate the victim on the non-critical pages.
I outlined my approach in more depth in this stackoverflow answer a couple of years ago.
Bottom line: it’s more convenient just to make every page SSL, but sometimes client requirements prevent such an approach. In such cases, using an insecure session along with a secure signed cookie is an effective compromise.
gladtocode 