CSP, SRI and CORS

Written on 13 February 2018, 09:10pm

Tagged with: , , ,

Content Security Policy (CSP)

The modern browsers are able to interpret the Content-Security-Policy HTTP header that defines which dynamic assets are allowed to load on a given website. Alternatively, the CSP content can be sent using meta HTML tags.

Example:


// allow everything but only from the same origin:
default-src 'self'; 
// allow JS but only from example.eu and from the same origin:
script-src 'self' https://example.eu/myapp; 
// allow XMLHttpRequests but only from example.eu and the same origin:
connect-src 'self' https://example.eu/myapp; 

You can find all the possible directives here and a tool that can generate your CSP header here.

The amazing thing about CSP is the Report-URI attribute, which will report the deviations from the policy to the specified URL:

Content-Security-Policy: default-src 'self'; 
report-uri http://reportcollector.example.com/collector.cgi 

One of the services collecting such reports is report-uri.com.

Subresource_Integrity (SRI)

SRI is a very simple and effective concept: the modern browsers load a given asset only if its hash matches the one defined in the ‘integrity’ attribute.

So instead of doing this:

<script src="//www.example.com/script.js" type="text/javascript"></script>;

it’s recommended to do this:

<script src="//www.example.com/script.js" type="text/javascript"
integrity="sha256-Abhisa/nS9WMne/YX+dqiFINl+JiE15MCWvASJvVtIk="
crossorigin="anonymous"></script>;

or even better, link each version of the remote asset with its own URL and hash:

<script src="//www.example.com/1.0.1/script.js" type="text/javascript"
integrity="sha256-Cng8gUe98XCqh5hc8nAM3y5I1iQHBjzOl8X3/iAd4jE=" 
crossorigin="anonymous"></script>

Cross-Origin Resource Sharing (CORS)

Problem:
– a script on client.com wants to access some data from server.com (ex. XMLHttpRequest)
– by default, the same-origin browser policy blocks this request

Solution:
– but by adding some special response headers, server.com can allow the script client.com to access the data.

The modern browsers have implemented a mechanism allowing scripts (like XMLHTTPRequest) to make cross-domain requests. This is Cross-Origin Resource Sharing and it uses a relatively less used HTTP request method (OPTIONS) plus several response headers (Access-Control-Request-Method, Access-Control-Request-Headers, etc)

Resources from Mozilla Development Network (MDN):

Glossary: CSP, SRI, CORS

Technical details: CSP, SRI, CORS

Context

Over the weekend, hackers injected thousands of websites—including UK and US government sites—with code that hijacked visitors’ computers to mine cryptocurrency.

The attack, noticed on Sunday by security researcher Scott Helme, was pulled off by compromising a single plugin that was used by all of the affected sites: Browsealoud, a reputable suite of accessibility and translation tools. According to Helme, the plugin was edited by attackers to embed a script that uses a site visitor’s computer to do the complex math that generates new digital coins (in this case, Monero). This process, known as “mining,” can slow down the victim’s computer.

The attack loaded malicious Javascript onto visitors’ computers. The hackers behind the attack chose to mine cryptocurrency, but they had the power to do almost whatever they wanted.
Cryptocurrency Mining Hack That Compromised Thousands of Sites ‘Could Have Been a Catastrophe’

Scott Helme: Protect your site from Cryptojacking with CSP + SRI
Troy Hunt: Trust in Third Party Libraries

Web PKI: 3 improvements

Written on 24 September 2017, 03:09pm

Tagged with: , ,

Some insights about web security from the excellent ‘Bulletproof SSL and TLS‘ book from Ivan Ristic.

– the Internet was not designed with security in mind
– the first efforts to improve this were in 1995, when SSL3 was released (by Netscape). Then TLS followed up.
– TLS 1.2 – the most recent version – was released in August 2008 (its successor – TLS 1.3 – is still under development, as of September 2017)
– the goal back in 1995 was to enable e-commerce. Today we have that (‘commercial security’), but we want much more.

One of the biggest problem with the Web PKI is the approach to certificate validation. The following improvements aim to fix that:
1. Public Key Pinning:
– addresses the fact that any CA can issue a certificate for any domain name without the owner’s permission.
– with pinning, site owners can select (pin) one or more CAs that they trust, creating their own (small) trust ecosystem
– delivered via HTTP headers (Public-Key-Pins)

2. HTTP Strict Transport Security (HSTS)
– allows web servers to declare that web browsers should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.
– also, when an invalid certificate is encountered, it instructs compliant browsers to replace warnings with errors, disallowing bypass.
– delivered also via HTTP headers (Strict-Transport-Security)

3. OCSP stapling
– There are two standards for certificate revocation (revocation is used when the private key is compromised or no longer needed)
– CRL (Certificate Revocation List) is a large list of revoked certificate serial numbers maintained by the CA. Because of the size, the lookup is slow
– OCSP (Online Certificate Status Protocol) allows browsers to obtain the revocation status of a single certificate.
– the problem with OCSP is that the individual lookup can slow down browsing and can affect the performance of the OCSP responder for high traffic websites
– to address this, OCSP stapling allows each server to embed an OCSP response directly into the TLS initial handshake

In the end, do not forget that the current Web PKI is controlled by 2 actors: Certificate Authorities (interested in profit) and browser vendors (interested in market share).

Neither group has strong security as its top priority, but they are not necessarily to blame—at least not entirely. They won’t give us security until we, the end users, start to demand it from them.

Update 10 October 2017: I have just enabled HSTS here. Inspired by Troy Hunt.

Random things – session hijacking

Written on 18 March 2017, 11:53am

Tagged with: , ,

Two notes about session hijacking methods:

Difference between stored and reflected XSS attack

Stored or persistent XSS attack – relies on user input stored on the server. Best example – a comment in a news site.
Reflected or non-persistent XSS attack – relies on user input sent in the HTTP query parameters. Best example – site search, showing the keyword after search
Play the XSS game: xss-game.appspot.com

Session fixation

In a nutshell, session fixation means that the attacker obtains a legitimate session ID from the server and then it makes the victim browser to use it. See example.
The counter-measures are quite simple:
– do not accept setting a session id via URL/POST parameters
– change session id after user login
– just use HTTPS and secure cookies, it’s 2017 and HTTPS adoption reached the tipping point