Tweet
Session hijacking at the application level focuses on gaining access to a target by obtaining legitimate session IDs from the victim.
A session ID is a unique identifier that is applied to a user's session that allows the server or web resource to identify the relationship it is having with the client. This is needed because web servers and browsers do not stay connected for very long and it is cumbersome for the user to log on and authenticate continuously just to do simple tasks. When the user has authenticated a session ID is allocated to the client/server relationship to avoid forcing the user to log on just because the browser and web server is no longer connected. The server is able to handle this scenario because it has identified the user's session ID and assumes it knows who the authenticated user is.
Vulnerabilities of lingering cookies or sessions from subpar coding or easier customer access is not that uncommon. Revisiting sites from your browser history may prove that you are actually still logged in - days later.
Session IDs comes in 3 flavors...
Embedded in a URL
A web application uses the GET request to follow links embedded in a web page. An attacker can easily browse through the victim's browser history and many times gain access by simply entering the URL of a previously visited web application.
Embedded as a Hidden Field
Forms for inputting user data many times include hidden fields that may be used for sending a client session ID. The ID is sent via the HTTP POST command when the form is submitted.
As Cookies
Cookies have been a potential avenue of exploit for quite a long time, and they have recently taken the blame for privacy issues such as tracking shopping activity or storing sensitive data. An attacker can obtain session information from cookies residing on the victim host.
When performing a session hijacking attack at the application layer, an attacker can choose from the following:
Session Sniffing
Session sniffing is a variation of sniffing where the attacker has a specific session token; some kind of a session ID, in sight.
Once this session token has been found, the attacker uses this it to gain access to the server or resource.
Predicting Session Tokens
Predicting a session token is to predict or make an educated guess as to what a valid session token will be. This task is accomplished by gathering a few session IDs that has been used already and some may still be valid or at least was valid at some point but is now expired. If they are then looked at carefully and analyzed the attacker may be able to predict what a new valid session will look like. Some times session tokens are predictable. Some part of the token may be static, while other parts may be dynamic in nature. A token may be build from date and time stamps or consecutive numbers.
Man-in-the-Middle
Even though a MITM attack is not a layer 7 or application layer attack it is included here as it works with web traffic as well.
A MITM attack is one of the most common forms of session hijacking and places the attacker directly between the victim and the server or the default gateway. An attacker will accomplish this using a technique such as ARP poisoning and will allow the attacker to freely and passively monitor traffic or actively inject malicious packets into either the victim or the server. First the attacker will sniff the network to find the victim and gateway IP addresses and MAC addresses. In ARP poisoning the attacker then sends Gratuitous or "poisoned" ARP replies to the victim and the gateway of the victim host, tricking the gateway to forward all traffic to the victim through the attackers computer, and all traffic from the victim to the gateway will also pass through the attackers computer. Then the attacker can manipulate or inject packets at will.
Man-in-the-Browser
The man-in-the-browser attack is a particularly interesting form of attack that consists of an attack surface that include Cross-Site Scripting (XSS), Trojans working as a proxy and JavaScript issues. XSS is a type of attack that can occur in one of many forms, but generally they can be said to occur when data of some type enters a web application through an untrusted source. Typically this data has not been properly validated or sanitized and is included as part of the dynamic content of a web site. The content that causes the attack to occur usually comes in the form of but not limited to JavaScript. HTML, flash or other kinds of executable code are other options for this attack and often has the goal of reading or stealing a cookie, interfering with session information, redirecting to a location of the attacker's choosing or any other task the attacker finds useful.
Stored and reflected XSS attacks are the two most common forms of this attack and the consequences are usually the same no matter the form the attack takes: Disclosure of the session cookie, allowing an attacker to hijack the authenticated users session, disclosing end-user files, installing Trojans, redirecting the user or modifying the website content in some way.
Session Fixation
This type of attack is targeted specifically at web applications. This attack exploits vulnerabilities in the way packages manage their sessions IDs. The vulnerability exists when an application tails to create a new session ID when a new user authenticates to the application. The attacker must induce a user to authenticate using a session ID known to the attacker and then hijack the session. There are several ways to execute this kind of attack, which vary depending on the application at hand. An attacker sends a link to the victim including a session ID. The attacker then knows the victim session ID and waits for the victim to authenticate using that session ID. The attacker then have the same privileges as the victim.
A session ID is a unique identifier that is applied to a user's session that allows the server or web resource to identify the relationship it is having with the client. This is needed because web servers and browsers do not stay connected for very long and it is cumbersome for the user to log on and authenticate continuously just to do simple tasks. When the user has authenticated a session ID is allocated to the client/server relationship to avoid forcing the user to log on just because the browser and web server is no longer connected. The server is able to handle this scenario because it has identified the user's session ID and assumes it knows who the authenticated user is.
Vulnerabilities of lingering cookies or sessions from subpar coding or easier customer access is not that uncommon. Revisiting sites from your browser history may prove that you are actually still logged in - days later.
Session IDs comes in 3 flavors...
Embedded in a URL
A web application uses the GET request to follow links embedded in a web page. An attacker can easily browse through the victim's browser history and many times gain access by simply entering the URL of a previously visited web application.
Embedded as a Hidden Field
Forms for inputting user data many times include hidden fields that may be used for sending a client session ID. The ID is sent via the HTTP POST command when the form is submitted.
As Cookies
Cookies have been a potential avenue of exploit for quite a long time, and they have recently taken the blame for privacy issues such as tracking shopping activity or storing sensitive data. An attacker can obtain session information from cookies residing on the victim host.
When performing a session hijacking attack at the application layer, an attacker can choose from the following:
Session Sniffing
Session sniffing is a variation of sniffing where the attacker has a specific session token; some kind of a session ID, in sight.
Once this session token has been found, the attacker uses this it to gain access to the server or resource.
Predicting Session Tokens
Predicting a session token is to predict or make an educated guess as to what a valid session token will be. This task is accomplished by gathering a few session IDs that has been used already and some may still be valid or at least was valid at some point but is now expired. If they are then looked at carefully and analyzed the attacker may be able to predict what a new valid session will look like. Some times session tokens are predictable. Some part of the token may be static, while other parts may be dynamic in nature. A token may be build from date and time stamps or consecutive numbers.
Man-in-the-Middle
Even though a MITM attack is not a layer 7 or application layer attack it is included here as it works with web traffic as well.
A MITM attack is one of the most common forms of session hijacking and places the attacker directly between the victim and the server or the default gateway. An attacker will accomplish this using a technique such as ARP poisoning and will allow the attacker to freely and passively monitor traffic or actively inject malicious packets into either the victim or the server. First the attacker will sniff the network to find the victim and gateway IP addresses and MAC addresses. In ARP poisoning the attacker then sends Gratuitous or "poisoned" ARP replies to the victim and the gateway of the victim host, tricking the gateway to forward all traffic to the victim through the attackers computer, and all traffic from the victim to the gateway will also pass through the attackers computer. Then the attacker can manipulate or inject packets at will.
Man-in-the-Browser
The man-in-the-browser attack is a particularly interesting form of attack that consists of an attack surface that include Cross-Site Scripting (XSS), Trojans working as a proxy and JavaScript issues. XSS is a type of attack that can occur in one of many forms, but generally they can be said to occur when data of some type enters a web application through an untrusted source. Typically this data has not been properly validated or sanitized and is included as part of the dynamic content of a web site. The content that causes the attack to occur usually comes in the form of but not limited to JavaScript. HTML, flash or other kinds of executable code are other options for this attack and often has the goal of reading or stealing a cookie, interfering with session information, redirecting to a location of the attacker's choosing or any other task the attacker finds useful.
Stored and reflected XSS attacks are the two most common forms of this attack and the consequences are usually the same no matter the form the attack takes: Disclosure of the session cookie, allowing an attacker to hijack the authenticated users session, disclosing end-user files, installing Trojans, redirecting the user or modifying the website content in some way.
- Stored XSS - These are attacks where the attacker will place code on a target server where the victim will visit and access the content. When the victim makes a request from the server, they will execute the injected script, which will in turn carry out what the attacker intended it to do.
- Reflected XSS - In this attack code is injected which is then bounced or reflected off a web server in the form of something such as an error message or other result. Typically these attacks makes their way to the victim in the form of an e-mail or via a different web server. A user may be tricked into clicking a link and once clicked, the link would then cause the user to execute code.
Session Fixation
This type of attack is targeted specifically at web applications. This attack exploits vulnerabilities in the way packages manage their sessions IDs. The vulnerability exists when an application tails to create a new session ID when a new user authenticates to the application. The attacker must induce a user to authenticate using a session ID known to the attacker and then hijack the session. There are several ways to execute this kind of attack, which vary depending on the application at hand. An attacker sends a link to the victim including a session ID. The attacker then knows the victim session ID and waits for the victim to authenticate using that session ID. The attacker then have the same privileges as the victim.
- The session ID is sent to the victim in a link and the victim accesses the site through the malicious URL.
- The victim is tricked into authenticating in the target web server, using a login form developed by the attacker. The form can be hosted on the web server or directly in a HTML-formatted e-mail.
- The attacker uses code injection, such as an XSS attack, to insert malicious code in the hyperlink sent to the victim and fix a session ID in its cookie.
- Using the META tag is also considered a code injection attack, although it is different from the XSS attack, where undesirable scripts can be disabled or the execution can be denied.
- A HTTP header response uses the server response to fix the session ID in the victim's browser. By including the parameter Set-Cookie in the HTTP header response, the attacker is able to insert the value of a fixed session ID in the cookie and send it to the victim's browser.