Penetration Test - Security

httpOnly Cookies

Session cookies are used to track a user’s application session and are typically used to check the permissions that a specific user session has within the application with regard to its available resources and functionality. By acquiring another user's session cookie value, an attacker may be able to connect to the application as that user.

If the acquired session cookie value relates to an authenticated session, then the attacker would have access to the application resources typically available to the targeted user.

The HttpOnly flag is available to be set on cookie values to prevent the cookie from being accessed by non-HTTP resources, such as JavaScript. By not setting the HttpOnly flag on a number of session cookies, sites are left potentially vulnerable to session hijacking attacks through the exploitation of other application issues, such as cross-site scripting.

Quick Fix

<httpCookies httpOnlyCookies="true"/>

Recommendation

Set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

Alternatively, URL rewriting could be used, as is detailed in the following example.

 <rewrite>
    <outboundRules>
      <rule name="Add HttpOnly" preCondition="No HttpOnly">
        <match serverVariable="RESPONSE Set Cookie" pattern=".∗" negate="false" />
        <action type="Rewrite" value="{R:0}; HttpOnly" />
        <conditions>
        </conditions>
    </rule>
    <preConditions>
      <preCondition name="No HttpOnly">
        <add input="{RESPONSE Set Cookie}" pattern="." />
        <add input="{RESPONSE Set Cookie}" pattern="; HttpOnly" negate="true" />
      </preCondition>
   </preConditions>
  </outboundRules>
 </rewrite>

Cookies Not Set With Secure Flag

Secure is an additional flag included in a Set-Cookie HTTP response header. Using the secure flag when generating a cookie helps mitigate the risk of interception of cookies sent over encrypted communications, as otherwise they could be accessed outside of the secure session.

Recommendation

The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of the application that are accessed over HTTPS should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications.

 <system.web>
   <httpCookies httpOnlyCookies="true" requireSSL="true"/>

Incomplete HTTPS Cache Control

Web page configuration means that secure pages can be cached in the browser. This means that sensitive information could be accessed outside of an authentication session either through physical access to the machine or through compromise from another attack vector.

Recommendation

Web servers should be configured to should return caching directives instructing browsers not to store local copies of any sensitive data. This can be achieved using HTTP headers:

Set the Cache-Control HTTP Header with no-cache, no-store, must-revalidate, private. Set the pragma HTTP Header with no-cache.

Using ASP.NET-MVC

Response.Cache.SetCacheability(HttpCacheability.NoCache);  // HTTP 1.1.
Response.Cache.AppendCacheExtension("no-store, must-revalidate");
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.

Using ASP.NET:

Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.

Using ASP:

Response.addHeader "Cache-Control", "no-cache, no-store, must-revalidate" ' HTTP 1.1.
Response.addHeader "Pragma", "no-cache" ' HTTP 1.0.
Response.addHeader "Expires", "0" ' Proxies.

Using Ruby on Rails, or Python on Flask:

response.headers["Cache-Control"] = "no-cache, no-store, must-revalidate" # HTTP 1.1.
response.headers["Pragma"] = "no-cache" # HTTP 1.0.
response.headers["Expires"] = "0" # Proxies.

Using Google Go:

responseWriter.Header().Set("Cache-Control", "no-cache, no-store, must-revalidate") // HTTP 1.1.
responseWriter.Header().Set("Pragma", "no-cache") // HTTP 1.0.
responseWriter.Header().Set("Expires", "0") // Proxies.

Using Apache .htaccess file:

<IfModule mod_headers.c>
 Header set Cache-Control "no-cache, no-store, must-revalidate"
 Header set Pragma "no-cache"
 Header set Expires 0
</IfModule>

Using HTML4:

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />

HTTP X-Header Options Not Set

The web server does not set the X-Content-Type-Options and X-Frame-Options HTTP headers. These headers are used to prevent "clickjacking" attacks against the site and can be used to mitigate the risk from buffer overflow vulnerabilities on certain client web browsers that can be exploited should an attacker be able to upload malicious files.

Recommendation

Ensure the X-Frame-Options and X-Content-Type-Options HTTP headers are set on all web pages returned by the server. These headers are supported by most modern browsers. If the page will be framed by other pages on the server, then it should be set with SAMEORIGIN. Otherwise, if the page should never be framed, it should be set to DENY.

Configuring IIS

To configure IIS to send the X-Frame-Options header, add this your site's Web.config file:

<system.webServer>
  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <add name="X-Content-Type-Options" value="nosniff"/>
      <add name="X-XSS-Protection" value="1; mode=block"/> 
    </customHeaders>
  </httpProtocol>

  ...
</system.webServer>

Session Token in URL

The tester observed session tokens being used in the URL. This makes it more likely for an attacker to intercept the session token. An attacker can use this session token to hijack the session and obtain sensitive information.

Recommendation

Applications should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.

X-XSS-Protection Header Not Set

An anti-cross-site-scripting (XSS) header is not set within the responses returned by the assessed application. The presence of this header will enforce the use of XSS filtering mechanisms built into a user’s browser, offering an additional mitigation against such attacks providing that the browser supports the interpretation of this header.

Recommendation

onsider having each application return the following header to ensue that users' browsers have their XSS filters enabled:

x-xss-protection: 1; mode=block

 <httpProtocol>
   <customHeaders>
     <add name="X-XSS-Protection" value="1; mode=block"/> 
   </customHeaders>
 </httpProtocol>