Brief Summary
When an application does not renew its session cookie(s) after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).
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 as- sociated 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
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 protect- ed 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 gen- eral, 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 encryp- tion, 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 applica- tion 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 per- formed, 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 The application sets a new session identifier JSESSIONID=0000d-
8eyYq3L0z2fgq10m4v-rt4:-1 for the client.
Next, if the tester successfully authenticates to the application with the following POST HTTPS:
The tester observes the following response from the server:
As no new cookie has been issued upon a successful authenti- cation the tester knows that it is possible to perform session hi- jacking.
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 au- thentication is successful, provide another sessionID.
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 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 ...
which public documents a registered user downloads) it is es- sential 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 ex- pect 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 se- curity. 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 appro- priate 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: Pri- vate 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 sys- tems, 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 Script- ing (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.
If login.asp is badly implemented, it may be possible to log in using
the following URL: http://owaspapp.com/login.asp?Login=User-
name&password=Password&SessionID=12345678
Potentially insecure server-side scripts may be identified by checking each POST in this way.
Testing for Transport vulnerabilities:
All interaction between the Client and Application should be test- ed at least against the following criteria.
• How are Session IDs transferred? e.g., GET, POST, Form Field
(including hidden fields)
• Are Session IDs always sent over encrypted transport by default? • Is it possible to manipulate the application to send Session IDs
unencrypted? e.g., by changing HTTP to HTTPS?
• What cache-control directives are applied to requests/responses passing Session IDs?
• Are these directives always present? If not, where are the exceptions?
• Are GET requests incorporating the Session ID used?
• If POST is used, can it be interchanged with GET?
References Whitepapers
• RFCs 2109 & 2965 – HTTP State Management Mechanism
[D. Kristol, L. Montulli] - http://www.ietf.org/rfc/rfc2965.txt,
http://www.ietf.org/rfc/rfc2109.txt
• RFC 2616 – Hypertext Transfer Protocol -
HTTP/1.1 - http://www.ietf.org/rfc/rfc2616.txt
Testing for CSRF (OTG-SESS-005)
Summary
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authen- ticated. With a little help of social engineering (like sending a link via email or chat), an attacker may force the users of a web appli- cation to execute actions of the attacker’s choosing. A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the admin- istrator account, a CSRF attack can compromise the entire web application.
CSRF relies on the following:
[1] Web browser behavior regarding the handling of session-re-
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 Content-Length: 34 Login=Username&password=Password&SessionID=12345678
lated information such as cookies and http authentication infor- mation;
[2] Knowledge by the attacker of valid web application URLs; [3] Application session management relying only on information
which is known by the browser;
[4] Existence of HTML tags whose presence cause immediate ac-
cess to an http[s] resource; for example the image tag img. Points 1, 2, and 3 are essential for the vulnerability to be present, while point 4 is accessory and facilitates the actual exploitation, but is not strictly required.
Point 1) Browsers automatically send information which is used to identify a user session. Suppose site is a site hosting a web application, and the user victim has just authenticated himself to site. In response, site sends victim a cookie which identifies re- quests sent by victim as belonging to victim’s authenticated ses- sion. Basically, once the browser receives the cookie set by site, it will automatically send it along with any further requests directed to site.
Point 2) If the application does not make use of session-related information in URLs, then it means that the application URLs, their parameters, and legitimate values may be identified (either by code analysis or by accessing the application and taking note of forms and URLs embedded in the HTML/JavaScript).
Point 3) ”Known by the browser” refers to information such as cookies, or http-based authentication information (such as Basic Authentication; and not form-based authentication), which are stored by the browser and subsequently resent at each request directed towards an application area requesting that authentica- tion. The vulnerabilities discussed next apply to applications which rely entirely on this kind of information to identify a user session. Suppose, for simplicity’s sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If victim has already authenticated himself, submitting another request causes the cookie to be automatically sent with it (see picture, where the user accesses an application on www.example.com).
The GET request could be originated in several different ways: • by the user, who is using the actual web application; • by the user, who types the URL directly in the browser; • by the user, who follows a link (external to the application)
pointing to the URL.
These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There are a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email mes- sage, or appear in a malicious web site where the user is lured, i.e.,
the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the ap- plication. If the user clicks on the link, since it was already authen- ticated by the web application on site, the browser will issue a GET request to the web application, accompanied by authentication in- formation (the session id cookie). This results in a valid operation performed on the web application and probably not what the user expects to happen. Think of a malicious link causing a fund trans- fer on a web banking application to appreciate the implications. By using a tag such as img, as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing him to visit an URL re- ferring to a page containing the following (oversimplified) HTML:
What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well. This results in a request being automatically sent to the web ap- plication hosted on site. It is not important that the image URL does not refer to a proper image, its presence will trigger the re- quest specified in the src field anyway. This happens provided that image download is not disabled in the browsers, which is a typical configuration since disabling images would cripple most web ap- plications beyond usability.
The problem here is a consequence of the following facts: • there are HTML tags whose appearance in a page result in
automatic http request execution (img being one of those); • the browser has no way to tell that the resource referenced by
img is not actually an image and is in fact not legitimate; • image loading happens regardless of the location of the alleged
image, i.e., the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications.
It is the fact that HTML content unrelated to the web applica- tion may refer components in the application, and the fact that the browser automatically composes a valid request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information re- lated to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs im- possible.
The problem might be even worse, since in integrated mail/ <html><body>
...
<img src=”https://www.company.example/action” width=”0” height=”0”>
...
browser environments simply displaying an email message con- taining the image would result in the execution of the request to the web application with the associated browser cookie.
Things may be obfuscated further, by referencing seemingly valid image URLs such as
where [attacker] is a site controlled by the attacker, and by utiliz- ing a redirect mechanism on
Cookies are not the only example involved in this kind of vulner- ability. Web applications whose session information is entirely supplied by the browser are vulnerable too. This includes applica- tions relying on HTTP authentication mechanisms alone, since the authentication information is known by the browser and is sent automatically upon each request. This DOES NOT include form- based authentication, which occurs just once and generates some form of session-related information (of course, in this case, such information is expressed simply as a cookie and can we fall back to one of the previous cases).
Sample scenario
Let’s suppose that the victim is logged on to a firewall web man- agement application. To log in, a user has to authenticate himself and session information is stored in a cookie.
Let’s suppose the firewall web management application has a function that allows an authenticated user to delete a rule speci- fied by its positional number, or all the rules of the configuration if the user enters ‘*’ (quite a dangerous feature, but it will make the example more interesting). The delete page is shown next. Let’s suppose that the form – for the sake of simplicity – issues a GET request, which will be of the form
(to delete rule number one)
(to delete all rules).
The example is purposely quite naive, but shows in a simple way the dangers of CSRF.
Therefore, if we enter the value ‘*’ and press the Delete button, the following GET request is submitted.
with the effect of deleting all firewall rules (and ending up in a pos- sibly inconvenient situation).
Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL or by following a link pointing, directly or via a redirection, to the above URL. Or, again, by accessing an HTML page with an embed- ded img tag pointing to the same URL.
In all of these cases, if the user is currently logged in the firewall management application, the request will succeed and will mod- ify the configuration of the firewall. One can imagine attacks tar- geting sensitive applications and making automatic auction bids, money transfers, orders, changing the configuration of critical software components, etc.
An interesting thing is that these vulnerabilities may be exercised behind a firewall; i.e., it is sufficient that the link being attacked