Today, I’ll discuss “Session Hijacking” attacks. But first, we need to understand what a cookie is.
What are “Cookies?”
A “cookie” is nothing more than a simple text file containing an arbitrary string of characters. When you visit many of your favorite web sites, the web server stores a cookie on your HD, allowing it to store information pertaining to your particular session with that same web server. The information is stored in name-value pairs; for instance, a web server can create a unique session identifier for you and store it in a cookie file on your system. That way, when you re-visit the web site later, your web browser will hand over the cookie for the web server to read, which eliminates the need to log back in to the web site.
Here’s a scenario: You’re shopping on an e-commerce web site and you have 10 items in your cart that you want to buy, but you accidentally close your tab. Not to worry! As long as the web server is storing the necessary information on your system, all you need to do is navigate back to the web site. If you had any settings you changed for the web site, that can be stored in a cookie too.
Some of these web sites even use your cookies to save your previous searches, which is then used for advertising. Every looked something up on Amazon and see it appear on your Facebook page 10 minutes later? One of the bigger security issues surrounding cookies is that they sometimes store your username and password. But, all an attacker really needs is the session ID contained in the cookie to do some damage.
In a “Session Hijacking” attack, the cyber criminal somehow learns the session ID of the victim.
A Man-in-the-Middle (MitM) attack is often the precursor to a more dangerous attack. Most MitM attacks are initiated through ARP poisoning or unicast flooding a switch. On a wireless network, MitM attacks are usually child’s play. As long as the attacker can intercept the victim’s web traffic, the attacker can “sniff” for cookies. Using Wireshark, an attacker can apply a filter for the capture file, such as http.cookie or http == cookie. Notice that we’re using unencrypted traffic. With HTTPS encryption using SSL/TLS, attackers can’t see the cookie. If the cookie and session ID are captured, however, the attacker can impersonate the victim by inserting the cookie into the header or by using a browser add-on that modifies cookies.
Back when HTTP was more dominant, it was very easy for cyber criminals to login to people’s Facebook accounts, bank accounts, and other accounts by stealing session IDs.
Cross-Site Scripting Attacks
A “Cross-Site Scripting (XSS) attack can also be used to steal sensitive information from the victim. In both persistent and non-persistent XSS attacks, the attacker can execute a malicious script that steals session IDs, usernames and passwords.
Let’s say you visit a popular healthboard forum. If the web server isn’t performing proper user input validation, then cybercriminals can post malicious java script code onto a message board that remotely steals session ID information. This becomes a persistent XSS attack because the code is now stored on the web site, or even the web server itself; henceforth, why this attack is also labeled a “Stored XSS attack.” Now, anyone who visits the attacker’s message board, they unknowingly execute the code. The attacker can now plug this information into their system to steal your session.
On the other hand, let’s say you were emailed a legitimate-looking message from Facebook containing a link that directs you to the Facebook login page. That link is a fake Facebook login page and it contains a malicious cross-site script that steals your username and password and records it for a cybercriminal. This would be a non-persistent XSS attack because the victim is directed to a site and the attack is reflected back and executes in the victim’s browser. For this reason, the attack is also known as the “Reflected XSS attack.
Session Prediction Attacks
Predicting session tokens can permit a cyber criminal to bypass authentication and gain access to a victim’s session, but it requires that the attacker knows the session ID generation process. This is usually accomplished by capturing a large amount of valid session IDs and then analyzing them further to identify some predictable information. For example, some applications would use a timestamp, the client’s IP address, or the client’s username. If the session ID truly isn’t random, the risk of a session hijacking attack increases.
Featured Image comes from https://www.wholikeit.com/internet-and-technology/web-security/what-is-session-hijacking-and-example/
Gibson, D. (2017). CompTIA SECURITY+ Get Certified Get Ahead SY0401 Study Guide. Virginia Beach, VA: YCDA, LLC