Tag: csrf

SameSite cookies

Recently, while reading through the updated 2017 OWASP Top Ten RC1 documentation, last updated in 2013, I noticed a recommendation to use Cookies with the “SameSite=strict” value set to reduce CSRF exposure in section A8.

Consider using the “SameSite=strict” flag on all cookies, which is increasingly supported in browsers.

Similar to the way that HttpOnly and Secure attributes have been added, SameSite allows for additional control.

Per the documentation, as of April 2017 the SameSite attribute is implemented in Chrome 51 and Opera 39. Firefox has an open defect, but I would expect it to be added soon to follow Chrome.


Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;

According to the specification you can issue the SameSite flag without a value and Strict will be assumed:


Set-Cookie: CookieName=CookieValue; SameSite

As many programming languages and server runtime environments do not yet support this for session cookies, you can use the Apache Tier1 configuration to append them.


Header edit Set-Cookie ^(JSESSIONID.*)$ $1;SameSite=Strict
Header edit Set-Cookie ^(PHPSESSID.*)$ $1;SameSite=Strict

It looks like PHP.INI might support the following attribute in a future release, but it’s not there yet!

session.cookie_samesite

REFERENCES:

clientaccesspolicy.xml

Similar to ‘crossdomain.xml’, Silverlight has some security features, this too is often noticeable by large number of HTTP 404 errors for a file named ‘clientaccesspolicy.xml’ in my webserver logs.

The most simple solution to the 404’s that restricts Silverlight is to add an empty file at the root of your websites.

REFERENCES:

crossdomain.xml

Adobe FlashPlayer 7 added several security features. I first became aware of this one as I saw a large number of HTTP 404 errors for a file named ‘crossdomain.xml’ in my webserver logs. (see also clientaccesspolicy.xml)

If you use flash on your website, I’d suggest adding an appropriate copy of this file to limit your exposure to some potential security issues.

Restricted domains

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com" />
<allow-access-from domain="example.com" />
</cross-domain-policy>

Open to all domains (not recommended, but fully backward compatible)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

REFERENCES:

X-Content-Type-Options: nosniff

To prevent XSS/CSRF exploits in MSIE8 and newer, it’s often best to close as many attack vectors as possible. An easy one to implement is an HTTP Header to prevent MSIE from “sniffing” the content to change it when incorrect.

Example: we would not want an HTML page intentionally served with ‘text/plain’ to be rendered as HTML.


X-Content-Type-Options: nosniff
Content-Type: text/plain

This could be added programatically to pages in your application, via a servlet or servlet filter or added to the httpd.conf file.

Apache2 example: httpd.conf

<IfModule headers_module>
Header set X-Content-Type-Options nosniff
</IfModule>

REFERENCES:

X-FRAME-OPTIONS HTTP Header

Added in MSIE8 and Mozilla Firefox 3.6.9, Apple Safari 4, IE8, and Google Chrome 2 are several mechanisms to defend against cross-domain forgeries.

You can add to your website to make sure it is not embedded in a frame or iframe. This avoids clickjacking.

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a “<frame>” or “<iframe>“. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

Supported Values:
X-FRAME-OPTIONS: DENY
X-FRAME-OPTIONS: SAMEORIGIN

NOTE: “ALLOW-FROM” is supported in some browsers

You can explicitly set this value for ApacheHTTP in the httpd.conf file, your .htaccess files or code it into the page(s) by the application itself.

Example, add this to the apache config file:

Header always set X-Frame-Options DENY