Feeds

Attention developers: Your SESSIONIDs are showing

You don't know sidejack

Security and trust: The backbone of doing business over the internet

Protecting passwords is important, but do you take the same care with your SESSIONIDs? You should.

Here's how they work: When you log into a web application, you exchange your credentials for a SESSIONID cookie. This cookie gets sent with every subsequent request from your browser until you log out or the session times out. During that window, if an attacker steals your SESSIONID, they have full access to your account.

What is your SESSIONID? Log into a website and type "javascript:alert(document.cookie)" into your browser. That number is very important and must be kept secret. Anyone who has it can hijack your account.

So what do you need to do to protect your application's SESSIONIDs? Here are some tips.

Don't roll your own

First, you want to make sure your SESSIONIDs are not guessable. Just like a password, they should be long and random so that attackers can't use a brute force attack. Some web applications and web services still create their own SESSIONID token, and a few even use a sequential integer. You should stick to the standard SESSIONID provided by your container.

Believe in SSL

Some web applications use SSL for the username and password, but then fall back to a non-SSL connection after authentication. Unfortunately, this means that the SESSIONID is transmitted in the clear in every HTTP request, where it can be easily read by anyone with access to the network. This attack is called "sidejacking," and there are simple tools available to exploit this weakness.

Don't forget your AJAX requests, as they may also contain a SESSIONID. Gmail has this problem, as the application sometimes falls back to non-SSL for AJAX requests, exposing the user's Gmail SESSIONID on the wire. Google recently added a setting to "always use SSL" that you should enable right now. Despite performance issues, the only solution to protect your SESSIONIDs on the wire is to use SSL for every single page from your login form to your logout confirmation.

Fly the cookie flags

Even if your application always uses SSL, attackers may try to trick the browser into exposing the SESSIONID over a non-SSL connection by getting victims to view a page including the following type of tag:

<img src="http://www.example.com">

When the browser sees this tag (even in the attacker's page), it will generate a non-SSL request and send it to www.example.com. The request will include the SESSIONID, and the attacker can sidejack the user's session. The solution is to use the "Secure" flag on your SESSIONID. This flag tells the browser to send the cookie only over an SSL connection.

Security and trust: The backbone of doing business over the internet

More from The Register

next story
New 'Cosmos' browser surfs the net by TXT alone
No data plan? No WiFi? No worries ... except sluggish download speed
'Windows 9' LEAK: Microsoft's playing catchup with Linux
Multiple desktops and live tiles in restored Start button star in new vids
iOS 8 release: WebGL now runs everywhere. Hurrah for 3D graphics!
HTML 5's pretty neat ... when your browser supports it
Mathematica hits the Web
Wolfram embraces the cloud, promies private cloud cut of its number-cruncher
Google extends app refund window to two hours
You now have 120 minutes to finish that game instead of 15
Intel: Hey, enterprises, drop everything and DO HADOOP
Big Data analytics projected to run on more servers than any other app
Mozilla shutters Labs, tells nobody it's been dead for five months
Staffer's blog reveals all as projects languish on GitHub
SUSE Linux owner Attachmate gobbled by Micro Focus for $2.3bn
Merger will lead to mainframe and COBOL powerhouse
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
WIN a very cool portable ZX Spectrum
Win a one-off portable Spectrum built by legendary hardware hacker Ben Heck
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
Protecting users from Firesheep and other Sidejacking attacks with SSL
Discussing the vulnerabilities inherent in Wi-Fi networks, and how using TLS/SSL for your entire site will assure security.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.