Part of the problem with securing buy-in to cybersecurity principles is how dense the language can be. Whether it’s the difference between malware and viruses, talk of trojans and worms, or firewalls and account controls, it can be hard to get people to engage.

Session hijacking is another one of those concepts that requires some explanation – both in terms of what it is and how dangerous it can be. Read on to learn more about session hijacking, the threat it poses to business servers, and how exactly you can protect against it.

What is session hijacking?

Each time you visit a website, you’re taking part in what’s known as a ‘session’. This encompasses everything you do on the website within an undefined period of time. Session data is used by tools such as Google Analytics to show what users do when they visit a website, such as which pages they visit and in what order, or how they interact with the site.

In order to allow you to connect to a site, a web server needs to differentiate between the users accessing it, so it can send them the correct information. The most common method of doing this is to send a token to the user’s browser once they have been authenticated. This token (often a string of characters) tells the web server who they are and their credentials, so that they do not need to reauthenticate.

Session hijacking is the process of stealing or imitating one of these tokens, and using it to pretend that you are an authenticated user. By pretending to be an authorised user, malicious actors can skip the checks that would normally be applied – such as firewalls or logins – gaining access to a web server, and using it to attack or steal from the server.

How exactly does session hijacking work?

There are various ways that cybercriminals can carry out session hijacking, but the most common is called packet sniffing. With this method, the attacker has already gained access to a user’s web traffic, and is monitoring what they are doing online. When they authenticate with a server, the attacker intercepts the session cookies, which act as a record of their visit that the server will check when they browse the site. As long as the entire site is not encrypted, the attacker can use these cookies to pose as the user and hijack the session.

Cybercriminals can also use a similar method to find out the session ID given to a user, which may be included in the URLs they browse to, or buried somewhere in the site code. As many websites use algorithms to generate these session IDs, it’s also possible to learn how the algorithm works, and produce your own session ID that fits the pattern used by the algorithm. This then grants the attacker access as if the server had authenticated them, when in reality no such check has taken place.

Common methods of session hijacking

There are a few methods of session hijacking which attackers use to steal or emulate unique identifiers, and gain access to remote servers. These include:

• Session tokens

As described above, session tokens such as cookies can be used by servers like passcards, where simply getting hold of one is enough to gain access. Stealing these session tokens or intercepting them en route to the client machine is one way of hijacking a session.

• Session sniffing

Session sniffing is the process of ‘sniffing out’ traffic to capture a session ID. Utilities such as Wireshark can capture information passed from a server to a client over an insecure connection, including the unique ID that the server gives to the client, which can then be used to gain access to the server.

• ID prediction

A weak algorithm may produce session IDs or other identifiers to an easily identifiable pattern. If these algorithms can be reverse engineered or their process decoded, it’s possible to predict the kind of ID they would accept, and create one that grants access to the server without any form of authentication.

• Man-in-the-browser attack

A man-in-the-browser attack uses a trojan on a user’s device to intercept and modify browsing requests. This kind of attack can secretly modify the commands being given by the user, detecting when they visit a website of interest, and passing on extra requests to the server that appear legitimate, but actually have a malicious intent.

• Cross-site scripting

Sometimes, vulnerabilities exist in web servers or applications which don’t allow direct access to the server, but do facilitate it. In cross-site scripting, cybercriminals can use these vulnerabilities to inject scripts into websites that give them access to users’ session keys. This then gives them the tools they need to gain free access to the server.

How to protect against session hijacking

What most of these methods have in common is the reliance on insecure connections to steal or intercept unique identifiers and tokens, which can then be used to connect securely to the server. As such, the best defence against session hijacking is to utilise encryption across your whole website, along with any web apps or other online resources on a server.

Adopting the HTTPS protocol across your website uses TLS to provide end-to-end encryption, protecting traffic from being intercepted. Once this is achieved, secure cookies and other unique identifiers can be used to reduce the ability of cybercriminals to steal them, while stronger algorithms can generate identifiers that are harder to spoof. Intrusion detection and prevention systems can also help to block suspicious traffic, preventing all but the most ingenious of attacks.

Sota offer a wide range of cyber resilience solutions, including fully managed cyber security and data protection services. Our vulnerability scanning and patching can fix issues with sites and servers, while our antivirus protection can protect individuals and networks against infiltration and theft. To learn more, get in touch with us today.