This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Session hijacking attack"
Line 2: | Line 2: | ||
==Description== | ==Description== | ||
+ | |||
+ | The session hijack attack consists of the exploitation of the web session control mechanism, which is normally managed for a session token. | ||
+ | |||
+ | Because a http communication use many different TCP connection, the web server need a method to recognize every user’s connections. The most useful method in use, depends on a token that the Web Server send to the client browser after a successful client authentication. A session token is normally composed by a string of variable width and it could be used indifferent ways, like: in the URL, in the header of the http requisition as a cookie or in the other parts of the header of the http request or yet in the body of the http requisition. | ||
+ | |||
+ | The Session Hijacking attack compromise the session token by stealing or predicting a valid session token to gain unauthorized access to the Web Server. | ||
+ | |||
+ | The session token could be compromised in different ways, the most common are: | ||
+ | • Predictable session token | ||
+ | • Session Sniffing | ||
+ | • Client-side attacks (XSS, malicious JavaScript Codes, Trojans, etc) | ||
+ | • Man-in-the-middle attacks | ||
+ | • Man-in-the-browser attacks | ||
+ | |||
==Examples == | ==Examples == | ||
+ | ===Example 1=== | ||
+ | |||
+ | ====Predictable session token==== | ||
+ | |||
+ | A session token is normally composed by a string of variable width, which randomness is very important to avoid its prediction. | ||
+ | Some bad implementation use sessions token composed by user information or other predictable information like timestamp or client IP address. In the worst case this information are in clear text or coded using some weak algorithm like base64 encoding. | ||
+ | In this case the session hijack is done guessing the token of a logged on user. So, looking at the example in Figure 1, the token used is a JSESSIONID cookie, witch content is user01 that correspond to the user ID. The attack consists in trying connection using valid userIDs in the hope that a valid user is authenticated in the moment of the attack. | ||
+ | |||
+ | |||
+ | <center> | ||
+ | [[Image:Predictable_cookie.JPG]] | ||
+ | |||
+ | Figure 1. Predictable cookie | ||
+ | </center> | ||
+ | |||
+ | |||
+ | ===Example 2=== | ||
+ | |||
+ | ====Session Sniffing==== | ||
+ | |||
+ | In the example as we can see, first the attacker uses a sniffer to capture a valid token session called “Session ID”, then he uses the valid token session to gain unauthorized access to the Web Server. | ||
+ | |||
+ | |||
+ | <center> | ||
+ | [[Image:Session_Hijacking_3.JPG]] | ||
+ | |||
+ | Figure 2. Manipulating the token session executing the session hijacking attack. | ||
+ | </center> | ||
+ | |||
+ | |||
+ | ===Example 3=== | ||
+ | ====Cross-site script attack==== | ||
+ | |||
+ | The attacker can compromise the session token by using malicious code or programs running at the client-side, the example will show how the attacker could use a XSS attack to steal the session token. If an attacker sends a crafted link to the victim with the malicious JavaScript, when the victim click on the link, the JavaScript will run and complete the instructions made by the attacker. | ||
+ | The example in figure 3 uses an XSS attack to shows the cookie value of the current session, using the same technique is possible to create a specific Javascript code that will send the cookie to the attacker: | ||
+ | |||
+ | <SCRIPT>alert(document.cookie);</SCRIPT> | ||
+ | |||
+ | |||
+ | <center> | ||
+ | [[Image:Code_Injection.JPG]] | ||
+ | |||
+ | Figure 3. Code injection. | ||
+ | </center> | ||
+ | |||
+ | |||
+ | |||
+ | ===Other Examples=== | ||
+ | The following attacks acts intercepting the information exchange between the client and the server | ||
+ | |||
+ | Man-in-the-middle | ||
+ | *[[Man-in-the-middle attack]] | ||
+ | |||
+ | Man-in-the-browser | ||
+ | *[[Man-in-the-browser attack]] | ||
+ | |||
+ | |||
+ | ==References== | ||
+ | *http://www.iss.net/security_center/advice/Exploits/TCP/session_hijacking/default.htm | ||
+ | * http://en.wikipedia.org/wiki/HTTP_cookie | ||
==Related Threats== | ==Related Threats== | ||
+ | |||
==Related Attacks== | ==Related Attacks== | ||
+ | * [[Man-in-the-middle attack]] | ||
+ | |||
==Related Vulnerabilities== | ==Related Vulnerabilities== | ||
+ | [[:Category:Input Validation Vulnerability]] | ||
+ | |||
==Related Countermeasures== | ==Related Countermeasures== | ||
+ | [[:Category:Session Management]] | ||
+ | |||
− | + | ==Categories== | |
+ | [[:Category:Session Management]] |
Revision as of 12:12, 27 August 2007
- This is an Attack. To view all attacks, please see the Attack Category page.
Description
The session hijack attack consists of the exploitation of the web session control mechanism, which is normally managed for a session token.
Because a http communication use many different TCP connection, the web server need a method to recognize every user’s connections. The most useful method in use, depends on a token that the Web Server send to the client browser after a successful client authentication. A session token is normally composed by a string of variable width and it could be used indifferent ways, like: in the URL, in the header of the http requisition as a cookie or in the other parts of the header of the http request or yet in the body of the http requisition.
The Session Hijacking attack compromise the session token by stealing or predicting a valid session token to gain unauthorized access to the Web Server.
The session token could be compromised in different ways, the most common are: • Predictable session token • Session Sniffing • Client-side attacks (XSS, malicious JavaScript Codes, Trojans, etc) • Man-in-the-middle attacks • Man-in-the-browser attacks
Examples
Example 1
Predictable session token
A session token is normally composed by a string of variable width, which randomness is very important to avoid its prediction. Some bad implementation use sessions token composed by user information or other predictable information like timestamp or client IP address. In the worst case this information are in clear text or coded using some weak algorithm like base64 encoding. In this case the session hijack is done guessing the token of a logged on user. So, looking at the example in Figure 1, the token used is a JSESSIONID cookie, witch content is user01 that correspond to the user ID. The attack consists in trying connection using valid userIDs in the hope that a valid user is authenticated in the moment of the attack.
Figure 1. Predictable cookie
Example 2
Session Sniffing
In the example as we can see, first the attacker uses a sniffer to capture a valid token session called “Session ID”, then he uses the valid token session to gain unauthorized access to the Web Server.
Figure 2. Manipulating the token session executing the session hijacking attack.
Example 3
Cross-site script attack
The attacker can compromise the session token by using malicious code or programs running at the client-side, the example will show how the attacker could use a XSS attack to steal the session token. If an attacker sends a crafted link to the victim with the malicious JavaScript, when the victim click on the link, the JavaScript will run and complete the instructions made by the attacker. The example in figure 3 uses an XSS attack to shows the cookie value of the current session, using the same technique is possible to create a specific Javascript code that will send the cookie to the attacker:
<SCRIPT>alert(document.cookie);</SCRIPT>
Figure 3. Code injection.
Other Examples
The following attacks acts intercepting the information exchange between the client and the server
Man-in-the-middle
Man-in-the-browser
References
- http://www.iss.net/security_center/advice/Exploits/TCP/session_hijacking/default.htm
- http://en.wikipedia.org/wiki/HTTP_cookie
Related Threats
Related Attacks
Related Vulnerabilities
Category:Input Validation Vulnerability
Related Countermeasures