Session Hijacking is when an attacker interacts with a server as another user. The attack take advantage of the active session between the victim and the server. What is a session? It is time period that the communication of two system is active.
There are two types of session hijacking,
a) Application Level - It is the most common now days and include, ID Sniffing, Session Fixation, Session Donation.
b) Network Level - Due to advancement in this layer, session hijacking in network level is very low. It includes; blind hijacking, IP spoofing.
Session Persistence is what makes session hijacking possible. When a user login to a server, they get a token that they will use to send subsequent requests to server until that token expires. If the attacker get hold of the token, they can access all the resources that the user was able to access. Persistence is either on the cookies or in the URL. Session Persistence in Cookies Cookies can keep Session ID that are persisted on each request. Advantages Cookies are not logged in normal requests, session ID can be persisted even after closing the browser. Disadvantages It is vulnerable to cross site scripting(XSS) and you can only have one session per browser.
Session Persistence in URL The session ID form part of the url. This means it is only persistence per tab and can still work if client doesn’t accept cookies. Disadvantages Session IDs are sent in referrer and they are also stored in the logs.
How to Hijack Sessions in Web Applications(WA) We take advantage on WA session persistence mechanism.
Hijacking Cookies with XSS XSS allows attackers to run malicious code on the website/client. How does it work? An attacker craft a url that has a script that does anything that the attacker wants, in this case sending the cookie of the victim back to the attacker when the victim clicks on the link. Sometimes cookies are exposed on logs depending on the framework used. You can also use google dorks to find vulnerable sites to XSS.
inurl: “search.php?q=”URL based session IDS are exposed in different areas, in the log files as the url are always logged. When clicking on the outbound links, the session ID is sent on the referer.
Session Sniffing This is more like MITM attack, where the attacker is looking at the traffic going through the wire in open network(unencrypted connection(HTTP)) capturing a valid token/session ID. I have a detailed post on How to perform MITM attack.
Session Fixation As the name suggest, this is when an attacker predetermine the session ID for the victim. If the session ID is persisted on the URL, an attacker can send a link that the user will then authenticate and if the session ID remain the same the attacker will also be authenticated. If the session is persisted in the cookie, an attacker can send a link that has a javascript code that set the session ID. Ensuring that the session ID change when the user logs in can help you avoid this kind of attjack.
Session Donation Involves Social Engineering(SE) to make it possible. An attacker creates an account and send authenticated link to the victim. Convincing the victim to provide more information about their account but in reality it is not their account but attackers acccount. Users are used to be logged in different sites making it less suspicious when the user click link that they already authenticated.
BruteForce Session IDs Attacker can check the session ID to see if it has a pattern and try to bruteforce authenticated sessions. If session ID are incremental for example, it is very easy to check for authenticated session.
Tools to Automate Session Hijacking Attacks:
- ZAP - OWASP Zed Attack Proxy
- Burp Suite
- NetSparker
- Ettercap
- Bettercap
Mitigating Risks of Session Hijacking
Strong Session IDs You don’t have to reinvent the wheel by creating your own session ids. It is better to delegate session id creation to the framework you are using.
Keep Session IDs out of URL This will ensure that the id are not logged or passed in the referer when clicking outbound links.
Don’t Reuse Session IDs for Authentication Session fixation can be mitigated by ensuring that the ID change when a user authenticate to the system.
Flag Session ID Cookies as HTTP Only It makes the ID inaccessible via Javascript helping to mitigate XSS.
Use TLS Using SSL is not secure anymore as it have known vulnerabilities that attackers can exploit. Using TLS ensures that referer header is not sent when clicking outbound links. DNS Spoofing and MITM Sniffing are also reduced if not stopped.
Flag Session ID Cookie as Secure Ensure cookies are not observed by an attacker. Setting the secure flag ensures that he cookie is not transmitted over unencrypted channel.
Expire Sessions Expiring sessions after a period of time is a good way to mitigate how long hijacked sessions are active. It help protects the users as they have to create new session to be able to access the server and the attacker will have to try to hijack the session again.
Disable Sliding Session The expiration of the session is counted from the time of the last request and not when the session was created. For example, if a session expires after 30 minutes, and a user does not make any request until the 20 minute, the session will not expire for the next 30 minutes instead of 10. The problem here is that, if an attacker has hijacked the session, he/she just need to keep making request to ensure the session does not expire.
Encourge Users to Log Out When user logout, the session is terminated and all active session that were using that session ID are terminated.
Reauthenticate Before Key Actions When withdrwaing money from online Escrow, it is important to reauthenticate again to ensure that it is the legit user who is making the request. That is just an example of why you might need reaunthentication like CAPTCHA, Secret Question and so on depending on the resource being requested.