Everybody knows that the internet is a dangerous place. You constantly hear about data breaches, stolen or leaked passwords and are reminded to keep your personal information safe from malicious entities. So, what do you do to keep your information safe? You use a strong password, avoid websites without https and even use a 2FA. But what if I tell you that all of this can be easily bypassed?<\/p>\n\n\n\n
In this article, I will talk about browser session hijacking, and how it can be used (at least to some degree) to bypass all currently used security measures. (Justin Warner, 2018) Later I will propose changes that can be implemented to reduce the risk of a successful session hijacking, or at least mitigate the damage caused by it.<\/p>\n\n\n\n
First of a quick rundown of what a browser session is and why we even need one. The web uses http\/https to communicate information between the client and the server. But http has the problem, that it is a stateless protocol, therefore it does not remember either the user, or possible data the user previously transmitted. To be able to save information the user submitted and for the server to remember the current user cookies are used. These store some information about the user\u2019s system and a unique identifier, with which the server can identify incoming traffic to the user. These identifying cookies are the browser session cookies which function as an authentication token for the user. (Johnson, 2021) (The TechCave, 2021)<\/p>\n\n\n\n
We use these sessions cookies to allow users to navigate to new sites on our website without having to reauthenticate themselves or resubmit information. Furthermore, a lot of websites allow these cookies to be saved with long lasting lifetimes, to reduce the need for reauthentication after browser or system restarts. This allows the websites to offer a fluent browsing experience to the user, which allows users to just use the website without having to worry about logging into every service once they have started a browsing session. (Johnson, 2021)<\/p>\n\n\n\n
Since the cookie is used to identify the current user and keep it logged in, it allows this file to be used instead of the login information to validate the current session. Therefore, it functions as a purpose-built bypass of the security measures for authorized access to the system. And herein is the crux of the problem: How are these security bypassing measures secured? Most often not. And even worse, to identify the current sessions, these cookies are sent to the server via the web, which leads to another potential point of attack, if the traffic is not sufficiently protected. (The TechCave, 2021)<\/p>\n\n\n\n
Most of the assumed security of session cookies is the difficulty to access or load these cookies. But cookies are usually written to and read by many different JavaScript\u2019s from the website and are not necessarily encrypted by any measure. A lot of browsers allow exporting and importing of browser sessions as well, which includes the cookies. This implies, that if the system of the user is in any way compromised, the attacker might be able to access these cookies and import them into another browser on another machine. (The TechCave, 2021)<\/p>\n\n\n\n
As previously mentioned, the browser session cookies have no predefined lifetime. The server can choose which lifetime it assigns to the session. This leads to a simple file saved in your browser, being able to be used as a bypass for your security measures for a prolonged period. While services like financial institutes are quite good at keeping the accepted lifetime of the cookie to a minimum, a lot of services choose to prioritize user comfort over security. This allows attackers a greater time frame to steal and use a session cookie, which makes these attacks easier to execute as well as more attractive attacks. (The TechCave, 2021)<\/p>\n\n\n\n
A big problem with session cookies is their identifiable name. The server uses a set name for the session cookie to identify it as such a cookie and uses the data contained to identify the user. This enables attackers to look up the name of the session cookie for a given service in their own browser, as long as they are logged into their own account. With this given name they can identify the session cookie of any user once they gained access to their cookies or web traffic. (wunderwuzzi, 2018)<\/p>\n\n\n\n
There are a lot of possible ways to get access to browser cookies, but some are more commonly used than others. The following are examples of these common attack vectors.<\/p>\n\n\n\n
A common attack vector to gain access to cookies of users, are man in the middle attacks. If the user is using an unprotected network the attacker can read the user\u2019s internet traffic and use a package sniffer to listen for the packages that contain the session cookie. Even private networks can be susceptible to these attacks once the attacker gained access to a device in that network. In the age of smart devices this attack vector has become a rising risk.\u00a0(Justin Warner, 2018) (OWASP, 2023)<\/p>\n\n\n\n
Another possibility to gain access to a valid session cookie of a user, is the usage of session fixation. This kind of attack only works for services, which create the session cookie, before the user is logged into an account. This is often the case since many services track the users inputs even if the user is not logged in, to already allow information to be saved. In this process the attacker generates a valid session cookie by visiting the target site without logging in. Afterwards the attacker sends a link containing the generated session cookie to the user. Once the user clicks on the link, the session ID which is embedded in the link is set in their browser. The server recognizes the cookie and once the user logs in it is associated with the current user. Therefore both user and attacker to access the service. (Johnson, 2021)\u00a0(OWASP, 2022)<\/p>\n\n\n\n
If an attacker finds some vulnerabilities in a web server, they might be able to inject JavaScript into the website. These kinds of attacks are called cross-site scripting. Since JavaScript\u2019s are used by the server to write information to the cookies to identify the user and save their information, the browser trusts the server to access them. This allows the malicious scripts to read the session cookie of each user and send it to the attacker, which can therefore use it to access the system. (OWASP, 2023) (The TechCave, 2021)<\/p>\n\n\n\n
If the attacker manages to install malware on the target machine, they can try different strategies to access the cookies. They can either try to directly access the storage location of the browser cookies on the disc, try to generate a process dump of the browser containing the cookie, install malicious add-ons into the browser that read the cookies or use package sniffing to listen for the cookie. (Justin Warner, 2018) (OWASP, 2023)<\/p>\n\n\n\n
Once the cookie is acquired the attacker can import this cookie into their own browser and will be immediately logged into the account of the user once they open the website the cookie is referring to. From there they might try to steal sensitive information, change the current security measures, or use the account for malicious activities. (Johnson, 2021)<\/p>\n\n\n\n
The malware might even allow the attacker to use the users network as a VPN, to be able to send the request of the attacker with the same IP address as the user. This can bypass further session cookie protection measures.<\/p>\n\n\n\n
As with most security flaws in IT-Systems, they are not something inevitable but most often a result of poor execution. The same goes for session cookies, which can easily be improved to offer similar quality of life, while reducing the risk that a session might be used by an unauthorized user.<\/p>\n\n\n\n
If we use system information like, browser version, IP-Address and so on to identify the current session that a user is using to connect to the server, then we force the attacker to be able to copy all these information to be able to use the hijacked cookie. If this method of authentication is used it will slightly reduce the ease of use of session cookies, since mobile devices will require reauthentication after switching networks. On the other hand, this would make session hijacking such a difficult endeavor that attackers might ignore this attack completely. (wunderwuzzi, 2018)<\/p>\n\n\n\n
If we only use https to communicate between client and server, we can mitigate an easy identification of which packages contain the session cookie that the attacker tries to gain access to. Currently a lot of servers use http traffic for information it does not consider sensitive information, which often contains cookies as well. This change would not have any impact on the browsing experience while almost eliminating package sniffing attacks. (Bugliesi, 2015) (The TechCave, 2021) (Johnson, 2021)<\/p>\n\n\n\n
A very attractive attack to gain access to session cookies is accessing the saved browser cookies on disc. This attack allows the attacker to gain access to all saved cookies at once and might give them multiple valid session at once. To reduce the risk of these cookies being accessed, the browser could encrypt all cookies before writing them to disc. This method would force attackers to use a process dump attack to gain access to these cookies, which might be more difficult to execute.<\/p>\n\n\n\n
Not saving cookies and limiting their lifetime would highly reduce the window of opportunity that an attacker can use to gain access to the service. This method is often used by financial institutions, which force a logout after a short period of time, but would generate a lot of frustration in users, which would be forced to repeatedly log into low-risk services. (wunderwuzzi, 2018)<\/p>\n\n\n\n
Another possibility to reduce the window of opportunity for a successful attack is the implementation of ever-changing session identifiers. After each successful interaction with a server through a session cookie, the server sends a new session cookie and invalidates the old one. This system reduces the lifetime of each session cookie to a minimum and therefore limits the time a stolen cookie can be used to until the user performed the next action. A problem that might arise through this system is through the asynchronous communication of server and client. This might lead to a request getting delayed and another request using the same valid session cookie. The first request will therefore be denied by the server since that session cookie was used up by the second request. This might lead to unexpected errors while using the service. (The TechCave, 2021) (Wikipedia, 2023)<\/p>\n\n\n\n
Most of the damage that can be caused by an attacker lies in the entire hijacking of the account. With a valid session the attacker might be able to change security credentials and lock the current user out of their account. To prevent this the server can ignore the currently valid session before taking any security relevant actions and request an authentication via 2FA or password. This limits the possibilities of the attacker to cause damage while being a generally accepted approach to increased security by the user. (wunderwuzzi, 2018) (The TechCave, 2021)<\/p>\n\n\n\n
Additionally, the user can try to use common techniques to reduce possible attack vectors. These include encrypting all internet traffic with a VPN, avoiding public unsecured Wi-Fi if possible, deleting old cookies and adhering to anti-malware best practices. But in the end, the server dictates how the session cookie is set up and used, which puts most of the responsibility on its side.<\/p>\n\n\n\n