HTTPOnly, Secure Flag, Strict Transport Security, X-Frame-Options, Content Security Policy
[Cross Post with http://blog.mozilla.com/webappsec/]
The vast majority of application security occurs within the application’s code. However, there are a few key security controls that are enabled by the web application dictating security properties to the web browser. These security properties enable the browser to impose additional security controls on items such as cookie handling, framing, and even the processing of JavaScript. These controls provide an additional layer of defenses which will either eliminate certain attack vectors or, at a minimum, minimize the impact of particular client-side attack types.
Some of these defensive controls have been around for awhile and others are newly supported in Firefox 4 and other modern browsers. Mozilla has been rolling out these controls across all of our websites with a high degree of success. It should be noted that these controls are not a substitute for secure development practices. Instead, they are another layer of defense that can be used to protect users and data in the event of an unknown gap elsewhere in your application.
HTTPOnly
Benefit: Minimizes impact of cross site scripting vulnerability by preventing JavaScript access to the session cookie.
Limitations: Does not prevent against any other malicious actions from XSS (phishing, malicious redirects, etc)
Example within HTTP Response:
Cookie: sessiondID=kljahsdf123; HTTPOnly;
Additional Reading:
http://www.owasp.org/index.php/HttpOnly
Secure Flag
Benefit: Instructs the browser to never send the cookie over a HTTP request. The cookie can only be sent over HTTPS. This works even if the user manually types in a request for HTTP. The HTTP request will be sent, but the browser will not send any cookies marked as “SECURE”
Limitations: The HTTP Request is still sent and this could be manipulated by a man in the middle to perform convincing phishing attacks (See Strict Transport Security for solution).
Example within HTTP Response:
Cookie: sessiondID=kljahsdf123; SECURE;
Additional Reading:
http://code.google.com/p/browsersec/wiki/Part2
https://developer.mozilla.org/en/DOM/document.cookie
Note: When setting both HTTPOnly and SECURE flags you will simply have both values for the cookie:
Cookie: sessiondID=kljahsdf123; HTTPOnly; SECURE;
Strict Transport Security
Benefit: Instructs the browser to never send requests to the domain over HTTP. Requests can only be sent over HTTPS. Think of this as the Secure flag for the entire request. This will protect the user even if they manually type in HTTP into the URL. The browser will upgrade this to HTTPS, assuming the site has previously enabled HSTS, and only the HTTPS request will be sent over the network.
Limitations: Only supported in most recent browser versions; however, support is quickly growing.
Example within HTTP Response:
Strict-Transport-Security: max-age=60000
Additional Reading:
https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security
X-Frame-Options
Benefit: Instructs the browser to disallow framing of a domain or limit framing to only sites of the same domain. This prevents clickjacking attacks and other malicious framing actions.
Limitations: Not supported in very old browser versions.
Example within HTTP Response:
X-Frame-Options: DENY
or
X-Frame-Options: SAMEORIGIN
Additional Reading:
https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header
Content Security Policy (CSP)
Benefit: CSP provides some amazing benefits. After a website is setup appropriately (no use of inline JavaScript) and a policy has been established, CSP will effectively prevent XSS where attacker controlled data is embedded in the HTML document. This works since the policy has established what JavaScript code is allowed and any other JavaScript that may make its way into the webpage via user input is flagged by the browser and blocked.
Limitations: Supported in Firefox 4 and plans for support in Chrome. It is still possible to introduce XSS vulnerabilities by not properly validating and sanitizing JSON content, or by including attacker controlled data in dynamically generated JavaScript code. Even if CSP is only supported by a portion of users it can act as an alerting system via the the report-uri to detect and report CSP violations that could be an attack.
Example within HTTP Response:
X-Content-Security-Policy: allow ‘self’ *.mydomain.com
Additional Reading:
https://developer.mozilla.org/en/Introducing_Content_Security_Policy
https://developer.mozilla.org/en/Security/CSP/Using_Content_Security_Policy
-Michael Coates - @_mwc