Objective
The session management is a mechanism of a basic security component in the broad range of web applications. Since the session management plays a key role in web applications, they become the prime target for the attacks against that application. If a malicious attacker can break the session management of any application, they can easily bypass its whole authentication controls and cover up as other users without having their credentials. Our aim is to analyze two such vulnerabilities with different methods to exploit them and make a comparative study between them.
What is a Session?
A session can be defined as server-side storage of information that is desired to persist throughout the user's interaction with the web site or web application. It is a semi-permanent interactive information interchange, also known as a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and user.
Instead of storing large and constantly changing information via cookies in the user's browser, only a unique identifier is stored on the client-side, called a session id. This session id is passed to the web server every time the browser makes an HTTP request. The web application pairs this session id with its internal database and retrieves the stored variables for use by the requested page. HTTP is a stateless protocol & the session management facilitates the applications to uniquely determine a certain user across several numbers of discrete requests as well as to manage the data, which it accumulates about the stance of the interaction of the user with the application.
Importance of Session
What is Session Hijacking?
HTTP is a stateless protocol and session cookies attached to every HTTP header are the most popular way for the server to identify your browser or your current session. To perform session hijacking, an attacker needs to know the victim’s session ID (session key). This can be obtained by stealing the session cookie or persuading the user to click a malicious link containing a prepared session ID. In both cases, after the user is authenticated on the server, the attacker can take over (hijack) the session by using the same session ID for their own browser session. The server is then fooled into treating the attacker’s connection as the original user’s valid session.There are several problems with session IDs:
- Many popular Web sites use algorithms based on easily predictable variables, such as time or IP address to generate the session IDs, causing them to be predictable. If encryption is not used (typically, SSL), session IDs are transmitted in the clear and are susceptible to eavesdropping.
- Session hijacking involves an attacker using brute force captured or reverse-engineered session IDs to seize control of a legitimate user's session while that session is still in progress. In most applications, after successfully hijacking a session, the attacker gains complete access to all of the user's data and is permitted to perform operations instead of the user whose session was hijacked.
- Session IDs can also be stolen using script injections, such as cross-site scripting. The user executes a malicious script that redirects the private user's information to the attacker.
One particular danger for larger organizations is that cookies can also be used to identify authenticated users in single sign-on systems (SSO). This means that a successful session hijack can give the attacker SSO access to multiple web applications, from financial systems and customer records to line-of-business systems potentially containing valuable intellectual property.
Main methods of Session Hijacking
1. XSS: XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.
2. Session Side-Jacking: Sidejacking refers to the use of unauthorized identification credentials to hijack a valid Web session remotely in order to to take over a specific web server.
3. Session Fixation: Session Fixation attacks attempt to exploit the vulnerability of a system that allows one person to fixate (find or set) another person's session identifier.
4. Cookie Theft By Malware or Direct Attack: Cookie theft occurs when a third party copies unencrypted session data and uses it to impersonate the real user. Cookie theft most often occurs when a user accesses trusted sites over an unprotected or public Wi-Fi network.
5. Brute Force: A brute force attack consists of an attacker submitting many passwords or passphrases with the hope of eventually guessing correctly. The attacker systematically checks all possible passwords and passphrases until the correct one is found. Alternatively, the attacker can attempt to guess the key which is typically created from the password using a key derivation function.
Real-World Example
In 2001, a vulnerability was reported in the application servers and development tools provider company’s application server platform, where a user who authenticates with them receives a session id and a random unique identifier. This session id and identifier remain active for up to 15s after the user logs in, and a subsequent user can make use of those credentials to hijack the logged-in account.
What is Session Riding?
A session riding attack (also called a Cross-Site Request Forging attack) is a technique to spoof requests on behalf of other users. With Session Riding it is possible to send commands to a Web application on behalf of the targeted user by just sending this user an email or tricking him into visiting a (not per se malicious but) specially crafted website. Among the attacks that may be carried out by means of Session Riding are deleting user data, executing online transactions like bids or orders, sending spam, triggering commands inside an intranet from the Internet, changing the system and network configurations, or even opening the firewall.
The principle that forms the basis of Session Riding is not restricted to cookies. Basic Authentication is subject to the same problem: once a login is established, the browser automatically supplies the authentication credentials with every further request automatically.
Primary methods of Session Riding
- The victim is tricked into clicking a link or loading a page through social engineering and malicious links.
- Sending a crafted, legitimate-looking request from the victim’s browser to the website. The request is sent with values chosen by the attacker including any cookies that the victim has associated with that website.
Conclusion
The major key differences between Session Hijacking and Session Riding are as follows:
- The main difference is that the attacker does not know the session ID in case of Session Riding (CSRF). Instead abuses the fact that the browser will always send the session cookie with all request the victim makes, even if the victim did not intend to make them.
- Once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.
References
- http://www.lassosoft.com/Tutorial-Understanding-Cookies-and-Sessions
- https://www.netsparker.com/blog/web-security/session-hijacking/
- https://crypto.stanford.edu/cs155old/cs155-spring08/papers/Session_Riding.pdf
- https://www.paladion.net/blogs/session-riding-attacks
- https://discl.cs.ttu.edu/cybersecurity/doku.php?id=vulnerability_case_study:session_hijacking
- https://www.hack2secure.com/blogs/discover-what-session-management-is
- https://www.acunetix.com/websitesecurity/csrf-attacks/
- https://en.wikipedia.org/wiki/Cross-site_scripting
- https://www.techopedia.com/definition
Article Link: https://blog.lucideus.com/2020/04/session-hijacking-and-session-riding.html