Feeds

Attention developers: Your SESSIONIDs are showing

You don't know sidejack

Internet Security Threat Report 2014

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.

Remote control for virtualized desktops

More from The Register

next story
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
NSA SOURCE CODE LEAK: Information slurp tools to appear online
Now you can run your own intelligence agency
Whistling Google: PLEASE! Brussels can only hurt Europe, not us
And Commish is VERY pro-Google. Why should we worry?
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
Soz, web devs: Google snatches its Wallet off the table
Killing off web service in 3 months... but app-happy bonkers are fine
First in line to order a Nexus 6? AT&T has a BRICK for you
Black Screen of Death plagues early Google-mobe batch
prev story

Whitepapers

Designing and building an open ITOA architecture
Learn about a new IT data taxonomy defined by the four data sources of IT visibility: wire, machine, agent, and synthetic data sets.
5 critical considerations for enterprise cloud backup
Key considerations when evaluating cloud backup solutions to ensure adequate protection security and availability of enterprise data.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Protecting against web application threats using SSL
SSL encryption can protect server‐to‐server communications, client devices, cloud resources, and other endpoints in order to help prevent the risk of data loss and losing customer trust.