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 "Testing for Session Fixation (OTG-SESS-003)"
(New page: {{Template:OWASP Testing Guide v3}} '''This is a draft of a section of the new Testing Guide v3''' == Brief Summary == <br> ..here: we describe in "natural language" what we want to test...) |
|||
Line 4: | Line 4: | ||
== Brief Summary == | == Brief Summary == | ||
− | + | When an application does not renew the cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie knowed by the attacker. | |
− | |||
<br> | <br> | ||
== Description of the Issue == | == Description of the Issue == | ||
<br> | <br> | ||
− | ... | + | Session fixation vulnerabilities occur when:<br> |
+ | * A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user. | ||
+ | * An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session. | ||
+ | In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session. | ||
<br> | <br> | ||
== Black Box testing and example == | == Black Box testing and example == | ||
− | '''Testing for | + | '''Testing for Session Fixation vulnerabilities:''' <br> |
− | ...<br> | + | The first step is to access to the domain to test, for example www.example.com. If we request the following: |
+ | GET www.example.com | ||
+ | We will obtain the following answer: | ||
+ | <pre> | ||
+ | HTTP/1.1 200 OK | ||
+ | Date: Wed, 14 Aug 2008 08:45:11 GMT | ||
+ | Server: IBM_HTTP_Server | ||
+ | Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure | ||
+ | Cache-Control: no-cache="set-cookie,set-cookie2" | ||
+ | Expires: Thu, 01 Dec 1994 16:00:00 GMT | ||
+ | Keep-Alive: timeout=5, max=100 | ||
+ | Connection: Keep-Alive | ||
+ | Content-Type: text/html;charset=Cp1254 | ||
+ | Content-Language: en-US | ||
+ | </pre> | ||
+ | We can notice that the application will set a new JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 on the client browser.<br> | ||
+ | Now, if we authenticate on the application, for example sending the following POST HTTPS: | ||
+ | <pre> | ||
+ | POST https://www.example.com/authentication.php HTTP/1.1 | ||
+ | Host: www.example.com | ||
+ | User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 | ||
+ | Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 | ||
+ | Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 | ||
+ | Accept-Encoding: gzip,deflate | ||
+ | Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 | ||
+ | Keep-Alive: 300 | ||
+ | Connection: keep-alive | ||
+ | Referer: http://www.example.com | ||
+ | Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 | ||
+ | Content-Type: application/x-www-form-urlencoded | ||
+ | Content-length: 57 | ||
+ | |||
+ | Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in | ||
+ | </pre> | ||
+ | if we obtain an answer as the following: | ||
+ | <pre> | ||
+ | HTTP/1.1 200 OK | ||
+ | Date: Thu, 14 Aug 2008 14:52:58 GMT | ||
+ | Server: Apache/2.2.2 (Fedora) | ||
+ | X-Powered-By: PHP/5.1.6 | ||
+ | Content-language: en | ||
+ | Cache-Control: private, must-revalidate, max-age=0 | ||
+ | X-Content-Encoding: gzip | ||
+ | Content-length: 4090 | ||
+ | Connection: close | ||
+ | Content-Type: text/html; charset=UTF-8 | ||
+ | ... | ||
+ | HTML data | ||
+ | ... | ||
+ | </pre> | ||
+ | we can understand that the application does not renew the user cookie after a successful authentication. | ||
+ | <br> | ||
'''Result Expected:'''<br> | '''Result Expected:'''<br> | ||
− | . | + | Now we can try to inject a valid cookie to a user (using a social engineering trick) and verify that it is possible to hijack the user session. |
+ | <br> | ||
== Gray Box testing and example == | == Gray Box testing and example == | ||
'''Testing for Topic X vulnerabilities:'''<br> | '''Testing for Topic X vulnerabilities:'''<br> | ||
− | + | Talk with developers and understand if the | |
'''Result Expected:'''<br> | '''Result Expected:'''<br> | ||
...<br><br> | ...<br><br> |
Revision as of 15:07, 14 August 2008
OWASP Testing Guide v3 Table of Contents
This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.
OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here
This is a draft of a section of the new Testing Guide v3
Brief Summary
When an application does not renew the cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie knowed by the attacker.
Description of the Issue
Session fixation vulnerabilities occur when:
- A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
- An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.
Black Box testing and example
Testing for Session Fixation vulnerabilities:
The first step is to access to the domain to test, for example www.example.com. If we request the following:
GET www.example.com
We will obtain the following answer:
HTTP/1.1 200 OK Date: Wed, 14 Aug 2008 08:45:11 GMT Server: IBM_HTTP_Server Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure Cache-Control: no-cache="set-cookie,set-cookie2" Expires: Thu, 01 Dec 1994 16:00:00 GMT Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=Cp1254 Content-Language: en-US
We can notice that the application will set a new JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 on the client browser.
Now, if we authenticate on the application, for example sending the following POST HTTPS:
POST https://www.example.com/authentication.php HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://www.example.com Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 Content-Type: application/x-www-form-urlencoded Content-length: 57 Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
if we obtain an answer as the following:
HTTP/1.1 200 OK Date: Thu, 14 Aug 2008 14:52:58 GMT Server: Apache/2.2.2 (Fedora) X-Powered-By: PHP/5.1.6 Content-language: en Cache-Control: private, must-revalidate, max-age=0 X-Content-Encoding: gzip Content-length: 4090 Connection: close Content-Type: text/html; charset=UTF-8 ... HTML data ...
we can understand that the application does not renew the user cookie after a successful authentication.
Result Expected:
Now we can try to inject a valid cookie to a user (using a social engineering trick) and verify that it is possible to hijack the user session.
Gray Box testing and example
Testing for Topic X vulnerabilities:
Talk with developers and understand if the
Result Expected:
...
References
Whitepapers
...
Tools
...