1BO4r2U

87 88
Web Application Penetration Testing
Web Application Penetration Testing
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.
Furthermore, the issue described above is problematic for sites that
issue a session identifier over HTTP and then redirect the user to a
HTTPS log in form. If the session identifier is not reissued upon authentication,
the attacker can eavesdrop and steal the identifier and
then use it to hijack the session.
How to Test
Black Box Testing
Testing for Session Fixation vulnerabilities:
The first step is to make a request to the site to be tested (example
www.example.com). If the tester requests the following:
They will obtain the following answer:
GET www.example.com
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
8eyYq3L0z2fgq10m4v-rt4:-1 for the client.
Next, if the tester successfully authenticates to the application with
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
The application sets a new session identifier JSESSIONID=0000d-
Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
The tester observes the following response from the server:
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
...
As no new cookie has been issued upon a successful authentication
the tester knows that it is possible to perform session hijacking.
Result Expected: The tester can send a valid session identifier to a
user (possibly using a social engineering trick), wait for them to authenticate,
and subsequently verify that privileges have been assigned
to this cookie.
Gray Box Testing
Talk with developers and understand if they have implemented a session
token renew after a user successful authentication.
Result Expected: The application should always first invalidate the existing
session ID before authenticating a user, and if the authentication
is successful, provide another sessionID.
Tools
• Hijack - a numeric session hijacking tool - http:/yehg.net/lab/pr0js/
files.php/jhijackv0.2beta.zip
• OWASP WebScarab: OWASP_WebScarab_Project
References
Whitepapers
• Session Fixation
• ACROS Security: http:/www.acrossecurity.com/papers/session_
fixation.pdf
• Chris Shiflett: http:/shiflett.org/articles/session-fixation
Testing for Exposed Session Variables
(OTG-SESS-004)
Summary
The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will
usually enable an attacker to impersonate a victim and access the
application illegitimately. It is important that they are protected from
eavesdropping at all times, particularly whilst in transit between the
client browser and the application servers.
The information here relates to how transport security applies to the
transfer of sensitive Session ID data rather than data in general, and
may be stricter than the caching and transport policies applied to the
data served by the site.
Using a personal proxy, it is possible to ascertain the following about
each request and response:
• Protocol used (e.g., HTTP vs. HTTPS)
• HTTP Headers
• Message Body (e.g., POST or page content)
Each time Session ID data is passed between the client and the server,
the protocol, cache, and privacy directives and body should be examined.
Transport security here refers to Session IDs passed in GET
or POST requests, message bodies, or other means over valid HTTP
requests.
How to Test
Testing for Encryption & Reuse of Session Tokens vulnerabilities:
Protection from eavesdropping is often provided by SSL encryption,
but may incorporate other tunneling or encryption. It should be noted
that encryption or cryptographic hashing of the Session ID should be
considered separately from transport encryption, as it is the Session
ID itself being protected, not the data that may be represented by it.
If the Session ID could be presented by an attacker to the application
to gain access, then it must be protected in transit to mitigate that risk.
It should therefore be ensured that encryption is both the default and
enforced for any request or response where the Session ID is passed,
regardless of the mechanism used (e.g., a hidden form field). Simple
checks such as replacing https:/ with http:/ during interaction with
the application should be performed, together with modification of
form posts to determine if adequate segregation between the secure
and non-secure sites is implemented.
Note that if there is also an element to the site where the user is
tracked with Session IDs but security is not present (e.g., noting which
public documents a registered user downloads) it is essential that a
different Session ID is used. The Session ID should therefore be monitored
as the client switches from the secure to non-secure elements
to ensure a different one is used.
Result Expected:
Every time the authentication is successful, the user should expect to
receive:
• A different session token
• A token sent via encrypted channel every time they make an HTTP
Request
Testing for Proxies & Caching vulnerabilities:
Proxies must also be considered when reviewing application security.
In many cases, clients will access the application through corporate,
ISP, or other proxies or protocol aware gateways (e.g., Firewalls). The
HTTP protocol provides directives to control the behavior of downstream
proxies, and the correct implementation of these directives
should also be assessed.
In general, the Session ID should never be sent over unencrypted
transport and should never be cached. The application should be examined
to ensure that encrypted communications are both the default
and enforced for any transfer of Session IDs. Furthermore, whenever
the Session ID is passed, directives should be in place to prevent its
caching by intermediate and even local caches.
The application should also be configured to secure data in caches
over both HTTP/1.0 and HTTP/1.1 – RFC 2616 discusses the appropriate
controls with reference to HTTP. HTTP/1.1 provides a number
of cache control mechanisms. Cache-Control: no-cache indicates that
a proxy must not re-use any data. Whilst Cache-Control: Private appears
to be a suitable directive, this still allows a non-shared proxy
to cache data. In the case of web-cafes or other shared systems, this
presents a clear risk. Even with single-user workstations the cached
Session ID may be exposed through a compromise of the file-system
or where network stores are used. HTTP/1.0 caches do not recognise
the Cache-Control: no-cache directive.
Result Expected:
The “Expires: 0” and Cache-Control: max-age=0 directives should be
used to further ensure caches do not expose the data. Each request/
response passing Session ID data should be examined to ensure appropriate
cache directives are in use.
Testing for GET & POST vulnerabilities:
In general, GET requests should not be used, as the Session ID may be
exposed in Proxy or Firewall logs. They are also far more easily manipulated
than other types of transport, although it should be noted that
almost any mechanism can be manipulated by the client with the right
tools. Furthermore, Cross-site Scripting (XSS) attacks are most easily
exploited by sending a specially constructed link to the victim. This is
far less likely if data is sent from the client as POSTs.
Result Expected:
All server side code receiving data from POST requests should be tested
to ensure it does not accept the data if sent as a GET. For example,
consider the following POST request generated by a log in page.
POST http:/owaspapp.com/login.asp HTTP/1.1
Host: owaspapp.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.0.2) Gecko/20030208 Netscape/7.02 Paros/3.0.2b
Accept: */*
Accept-Language: en-us, en
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded