Session hijacking attacks have been around since the mid-1990s. In 1994, HTTP version 0.9 beta was the first to be released with cookies support. Starting with HTTP 1.0, security vulnerabilities relating to session hijacking started to evolve into a permanent security risk.
Improved Web Servers, modernized HTTP 1.1 and featured browsers all contribute to this ongoing security problem, and as long as websites continue to use unencrypted communication or do not implement secured connections, session hijacking will continue to be a problem.
This article will cover a very common hacking technique called a “Cookie Theft Attack” or “Session Hijacking”. By the end of this article, you’ll understand the risks and security implications of giving information online and clicking unknown links. I will explain how hackers execute their attacks and what security breaches they’re looking for. In conclusion, I will discuss the best ways to prevent attacks and keep site visitors safe.
Understanding the Cookies Infrastructure
Cookies definition according to Wikipedia:
An HTTP cookie (also called web cookie, Internet cookie, browser cookie or simply cookie), is a small piece of data sent from a website and stored in the user’s web browser while the user is browsing it. Every time the user loads the website, the browser sends the cookie back to the server to notify the user’s previous activity.
What are Cookies Exactly?
Cookies are basically just text files, stored on your computer, used by the browser to save useful information about actions you take. One can look at cookies as messages passing between a browser and a web server. The browser sends the cookies to the web server when requesting data, and the web server sends them back to the browser with each response.
Cookies are stored in the local memory of a computer, typically inside the User profile folder, according to the browser type. Firefox saves all the cookies in a single file, whereas Chrome separates them into a different file for each cookie.
There are 2 main types of cookies:
- Session Cookies
These are temporary files that are erased when you close your browser or when the session reaches time out (it depends on the browser implementation when the actual erase is performed). - Persistent Cookies
These cookies remain on your local hard drive until they reach their expiration date (the programmer sets a Time to Live (TTL) for each new cookie), or until you delete them manually.
Each cookie, whether it is a session cookie or a persistent cookie, is either a first party or a third party cookie. Suppose you are browsing a website, and the cookie domain has the same domain as the website, then this cookie is first party. If the cookie domain and the website domain are different, then the cookie is a third party. In general, first party cookies can only be accessed by the website that served them, unlike third party cookies which can be accessed by any website.
By default, all common browsers allow both first and third party cookies. In addition, you can always change the settings to disable cookies from one or more specific domain/s.
Why Do Websites Use Cookies?
In order to understand the benefits we get from using cookies, we need to first understand the way a web server and a browser communicate with each other. The connection between the two is stateless, meaning the web server treats each request as an independent transaction that is unrelated to any previous request.
Imagine we want to give our clients a personalized experience based on their personal preferences. We need a way to save the point at which they left the site, even if they’re not logged into our service.
Cookies solve this problem easily by allowing websites to store the information they need, in local files on the client’s machine. Those files are then sent back and forth between the browser and the web server and pass all the data between the client and the server.
Using cookies, we’re now able to keep users logged in to our website, save their preferred verticals for Ads or do whatever we want with this persisted information. From the users’ standpoint, we can provide a better, more efficient, more personalized experience on our website.
Cookie Theft Attacks
At times when information worth power, even large, established and well-secured companies find themselves under continuous attempts of cookie theft attacks. Hackers will do everything they can in order to access private and sensitive information and gain control over private accounts.
WhatsApp Security Flaw (2012)
In 2012, a well-known security bug on the famous WhatsApp messenger app allowed users on the same local WiFi network to read each other’s messages – all messages! An app called WhatsApp Sniffer was made available on Google Play and took advantage of this bug. The app hijacked the user’s session on the same network, read all his messages from WhatsApp servers and shared them with all other WiFi peers.
Session Hijacking Methods
Session Hijacking definition according to Owasp:
The Session Hijacking attack consists of the exploitation of the web session control mechanism, which is normally managed for a session token.
The Session Hijacking attack compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the Web Server.
Because HTTP communication is based on many different TCP connections to the server, the web server needs a way to identify those connections and know which client sent them.
A session token is a string used to identify client requests sent from the same client to the web server.
A session hijacking attack is an exploit of stealing or guessing this token number, which is usually saved inside a cookie.
Method 1: Session Sidejacking
The WhatsApp Sniffer app used a sniffer on the same WiFi network to gain the session identifiers of all the other connected peers. It then authorized itself as the same user on WhatsApp servers to retrieve all the conversations.
Session sidejacking takes advantage of unencrypted communication inside a network. Tools like WireShark or Firesheep make it possible to listen to all the network messages and analyze them in a readable format. Public networks in coffee shops, airports, schools etc., are highly vulnerable to this kind of attack since the communication network is not usually secure.
Method 2: Session Fixation Attack
Session fixation attacks attempt to exploit the vulnerability of a service and allow the attacker to fixate (find or set) another person’s session ID.
Attack Scenario:
- Alice opens this URL
example.bank.com/login - The server responds with a generated session ID value which Alice can find in her cookies e.g.
sessionid=xyz - Alice wants to force Bob’s browser to use this session ID (so they will both share the same session, so Alice can later login and see Bob’s account information) when he logs into
example.bank.com, Alice has 2 choices:- Using a URL argument
Alice can send Bob an email with a link to the service and add the session ID parameter. i.e. linking Bob to
example.bank.com/login?sessionid=xyz
When Bob enters the service, his browser tells the service to use this particular session ID (in case the system allows setting session IDs using GET requests). - Issuing the cookie value
Since it is not possible to change a cookie on domain A from code running on domain B, Alice can use an XSS attack and inject a JavaScript code which will change Bob’s session ID cookie value.- Cross-site Scripting
Alice can send Bob an email with this link example.bank.com/<script>document.cookie=”sessionid=xyz”;</script> When Bob opens this URL, the browser sets the cookie session ID to the desired value. It is possible to set a persistent cookie to allow fixing the user’s cookie for a longer period of time.
example.bank.com/<script>document.cookie=”sessionid=xyz;%20Expires=Sunday,%201-Jan-2018%2000:00:00%20GMT”;</script>
When Bob will open this URL, his browser will fix his session ID to ‘xyz’ until 2018. By doing so, Alice will clearly gain long-term access to Bob’s computer. - META tag injection
Many servers scan the arguments for SCRIPT tags, which makes injection of META tags a better way to inject client code and fix the cookie value. Although META tags are usually placed between the HEAD tags, they are processed by the browser anywhere within the HTML document. When Alice sends Bob this link, and he opens this URL, it will fix Bob’s session ID, providing Alice access to his data. example.bank.com/<meta%20http-equiv=Set-Cookie%20content =”sessionid=xyz;%20Expires=Sunday,%201-Jan-2018%2000:00:00%20GMT”>
As contrast to injecting SCRIPT within the URL, on today’s browsers, it is impossible to turn off META tag injections, making this approach a far better hack than SCRIPT injections. - Session Adoption
Some servers can accept any session ID as a parameter in the URL and create a new session instance with this ID. All Alice needs now is to send Bob this link:
example.bank.com/?jsessionid=xyz
- Cross-site Scripting
- Using a URL argument
- Bob logs into example.bank.com and authenticates the session ID (without knowing he’s doing anything that will make his session vulnerable).
From now on, Alice and Bob share the same session and Alice can retrieve all Bob’s information.
Common Technologies and Their Vulnerability to Cookie Theft Attacks
Programmers often face the decision of choosing the best way to implement and manage the client side information on their website. Each method has its own security risks that need to be taken in account.
Below are few commonly used technologies, which can sometimes replace session cookies. Each one has its own pros and cons and can solve a different problem you might have.
Flash Cookies
Flash cookies are different from other cookies, as they are designed to be permanently stored on the user’s machine in a different location than all other cookies. These cookies can share information across multiple domains, unlike regular cookies which are restricted to the same domain policy. Removing them is not an easy task and needs to be done manually.
Adobe refers to these cookies as Locally Shared Objects (LSO), and they can be generated from any website the user visits which uses Flash (like YouTube). Some super cookies have additional capabilities, like regenerating regular cookies to prevent their removal by the user.
Flash cookies are used to give users the ultimate experience when they browse a website. Imagine a user creates an account on a website which uses flash cookies, and uses his Chrome browser to purchase an item on this website. The next day, when the same user browses this website from his Firefox browser, the website can read the LSO data, which basically contains all the information Chrome generated when the user browsed the website the other day and creates all the necessary cookies needed in order to authenticate the user and log him into the system. Clearly this is something all website owners would want, but, unfortunately for them, storing information this way is against many privacy standards, not to mention it is even illegal in some countries to collect information from the user without him knowing it.
Security Risks for Using Flash Cookies
- Cross-Site Request Forgery (CSRF) attack
When a website receives a request, it cannot distinguish whether the action was initiated by the user or if it is an attack, injected by a different harmful website. OWASP describes this attack and gives a detailed look about reviewing code for potential risks. - Cross-Site Scripting
This attack is less common but worth mentioning. When attacked, the attacker needs to place an exploit inside a cookie. Since flash cookies usually generate regular cookies, the attacker needs to find the first cookie in the creation chain. Therefore, such attacks become difficult to execute.
Supercookies
Another type of cookie, which makes it harder to prevent session hijacking attacks, is supercookies.
A supercookie allows malicious websites to affect requests to domain A, even if the cookie originated from domain B.
An Attacker can run this code on his server and affect other domains’ cookies.
In other words, it is enough for a user to just visit a malicious website in order to get his session hijacked and become exposed to security risks like someone stealing his identity or getting his most private information from other online services.
HTML5’S Local and Session Storage
HTML local storage provides two objects for storing data on the client:
- window.localStorage – stores data with no expiration date
- window.sessionStorage – stores data for one session (data is lost when the browser tab is closed)
Both Local and Session storage make it possible to save information on the client side without sending it to the server (in contrast to cookies). It enables up to 5MB of data to be saved locally on the user’s machine. Information used both by the client and the server should not be saved inside that storage, simply because this is client only storage. Therefore, session or local storage cannot replace cookies in the user authentication process.
Session storage does solve a common problem we have with cookies. Suppose we have multiple browser windows open on our favorite e-commerce website, and in each window, we look at a different item we are considering purchasing. Since cookies are shared between all windows, this could result in accidentally purchasing the same item twice (in case the item inside the cart is stored in a cookie).
Session storage is unique to each browser window, guaranteeing that the data we have on one window is totally independent from the others, thus eliminating the possibility of multiple purchases of the same simultaneously.
Security Risks for Using Local Storage
- Storing session identifiers or any other sensitive information in local storage is a bad practice as the data is always accesible by JavaScript.
- There is no way to restrict the visibility of an object stored inside the local storage to a specific path, therefore try to avoid hosting multiple applications on the same origin, use multiple sub-domain instead. (multiple applications on the same domain share the same local storage object)
Protecting Yourself Against Cookie Thefts
The best way to know if your session has been hijacked is to pay attention to unrecognized activity on your various accounts. Many websites support the “last login” feature which tells you when the last login to your account was executed and from which IP address. Use it to make sure no one else has accessed your data without your permission. Google provides a good tool to analyze your recent account activity by showing you the IPs, sessions, locations and many other useful information regarding your recent activity.
Google’s Safe Browsing API
According to Google’s site stats checker:
Google’s Safe Browsing technology examines billions of URLs per day looking for unsafe websites. Every day, we discover thousands of new unsafe sites, many of which are legitimate websites that have been compromised. When we detect unsafe sites, we show warnings on Google Search and in web browsers. You can search to see whether a website is currently dangerous to visit.
Google released an API to check if a website is safe of not. When you encounter a website you suspect, such as a PayPal link sent to your Inbox that you are not sure about, just run a check with Google’s web API and remove your doubts.
Protecting Your Clients Against Cookie Thefts
As a programmer, you can take several actions to make sure hackers won’t be able to hijack sessions on your websites. Of course, these do not provide a 100% guarantee that hacking won’t be successful, but they definitely reduce the possibility.
- Require the use of SSL/TLS connection on all your website pages. Doing so increases the CPU load time so at least consider using SSL/TLS for login pages and pages which transmit cookies.
- Set a session timeout to make sure the session is deleted after a fixed amount of time – provide a “remember me” button to make it easy for users to stay logged in after the session has timed out.
- Mark the cookie as an HttpOnly cookie (using the attribute) to ensure that this cookie cannot be transmitted via scripts. I read a good post about it here.
- Restrict the cookie domain to a minimum.
- Do not use consecutive numbers for session ID values, as they are easy to guess.
- Invalidate the session before authenticating a new user.
Programmers’ Mistakes That Make it Easy to Steal Sessions
- Posting login data to HTTPS, but loading the login form itself over HTTP makes the login form vulnerable to man in the middle attacks. Anyone can then manipulate the form and collect the credentials sent, using this simple injected script inside chrome dev tools console or any equivalent on other browsers:
- Another common problem is when programmers authenticate users without first invalidating the session. It enables anyone to fix the user’s session ID and to retrieve all his information. (read more about session fixation)
HTTP/2 Cookie Management
With the new HTTP/2 slowly arriving, it is likely that session security will be significantly improved. But, among all the great features it offers, there is one that directly affects cookies and the way they are represented.
Header Compression
HTTP/2 compresses request and response headers using the HPACK compression format. This compression reduces header size by about 85%, as compared to the previous version HTTP 1.1. This significantly improves the website’s page load latency. HPACK algorithm was introduced to us in 2012, becoming the lead compression algorithm since SPDY, which was found to be potentially vulnerable to session hijacking attacks named “CRIME“. HTTP/2 has improved security by forcing TLS connections, making it impossible to sniff packets on the network and thus reducing the vulnerability to session hijacking.
Conclusion
In a world where information is everything, secured data is something you must provide to all your clients. They expect your web services to work 24/7 without security flaws. Investing time and effort in making your services safer definitely pays off.
Cheers
