When cookies leak data
Written by Mike James   
Friday, 02 September 2011

We all know that cookies need to be handled with care and new research indicates that the Google search cookie has  particular problems.

 

Cookies - we programmers love them because they make it possible to turn a stateless web interaction into a stateful application. The trouble is cookies have a reputation for being evil - and perhaps they are if not managed with great care. A recent research paper from Alcatel-Lucent Bell Labs outlines in great detail how an apparently harmless session cookie can be used to find out a great deal about a user.

So much so that the title of the paper is "Show me your cookie and I will tell you who you are". This is a little misleading because the paper also explains how to get hold of the cookie even if the user doesn't want to show it.

 

cookies

 

The cookie in question is the Google SID cookie which is used to identify a user to a range of Google services including Search. The problem is that this cookie is used by many different services with differing security levels. For example, the SID cookie is used to personalize the search experience and keep a record of what a user searches for and even which websites they visit. This data is gathered on the basis of just the SID cookie without any further authorization, i.e. you don't have to supply a password.

If you do want to examine the data , Google does ask for you to log in so the data is secure even if the cookie isn't - or is it?

The paper explains first how to hijack a users SID cookie which is a fairly easy task because there are many services for which the cookie isn't considered a security risk and it is transmitted in the clear. The SID cookie is valid on the entire *.google.com domain so all you have to do is get the user to visit a spoof Google website that uses HTTP rather than HTTPS. This turns out to be fairly easy in most cases.

Once the attacker has the SID cookie it at first appears to be useless because to see the users search history say or to do anything else requires authentication. This is the clever part. If the user has enabled Web Search History then any search. results are returned by Google color coded to show how many times they have been visited by the user. Performing a search using the SID cookie doesn't require authentication and by examining the color coding of the returned links you can tell if the user has visited them before.

So all you have to do is perform a wide range of searches and read off where the user has visited. This is made much easier by the use of the "visited" and "social" filters. The first only returns results that have been visited and the second returns only social posts and comments made by user.

 

searchleakUsing the "Visited pages" filter and a search on the .info domain you'll discover I visit I Programmer a lot!

 

The authors conducted an experiment to see how much data they could retrieve just using the SID cookie. To do this they extended the FireSheep add-in to capture the cookie and display the results. Ten users were asked to run the experiment. All had search history enabled and 6 of the 10 knew nothing about it before the experiments. It is estimated that 50% of Google accounts have search history enabled and many are not aware of this.

Using a range of widely spread search targets, .com for example, with the visited filter on returns all of the .com sites that the user has visited. The experiment managed to retrieve typically between 10% and 80% of the sites that users had visited. The number of search targets was limited to avoid the user noticing the attack within their search history - although given that many were unaware that there was a search history this seems unlikely.

How can you protect yourself against this information leakage?

Simply use Google without logging into your account and the SID cookie isn't sent. You could also disable web search history. Alternatively always connect via a VPN.

In the long run Google needs to improve the security of even the apparently harmless SID cookie so that it is always transmitted encrypted.

cookies

Further reading:

Show Me Your Cookie And I Will Tell You Who You Are

arXiv:1108.5864v1

 

If you would like to be informed about new articles on I Programmer you can either follow us on Twitter or Facebook or you can subscribe to our weekly newsletter.

 

Banner


Apollo Adds REST APIs For GraphQL
29/10/2024

Apollo has added a simpler way to integrate REST APIs into a federated GraphQL environment. Available now in public preview, can be used to map REST API endpoints to their GraphQL schema using a decla [ ... ]



Azul Outperforms OpenJDK By Up To 37%
23/10/2024

Azul has announced that its Azul Platform Prime outperforms comparable OpenJDK distributions by as much as 37%. The company has also launched the Azul Java Performance Engineering Lab (JPEL) aimed at  [ ... ]


More News

Last Updated ( Monday, 05 September 2011 )