Despite all of the changes made to the most recent version of the OWASP 10, some things, like Cross Site Scripting (XSS), stay the same. Yes, it’s been around for ages, but it’s a bit like the whack a mole game and difficult to completely eradicate. XSS is an issue for both large and small sites. As you can see in xssed.com, even large sites like and Amazon aren’t immune.

- image001 - Content Security Policy 101 | Pure Hacking

One of the core issues with Injection attacks like XSS is that by default, browsers can’t differentiate between valid assets (e.g. JavaScript, stylesheets and fonts) that it is instructed to download and malicious assets injected by an attacker. If an attacker injects a script tag into the comments section of a site. The browser has no reason not to trust the malicious code and will happily execute it.

The Content (CSP) was introduced as a defensive mechanism that allows site owners to define what assets are authorized to be consumed by the browser in the context of a given website. CSP is an effective countermeasure against Clickjacking, XSS, mixed content and content injection attacks. By simply defining what sources you allow browsers to load on your site, you can protect your visitors from a slew of content injection attacks.
Despite the fact that all major browsers support CSP, it is not very widely deployed. Breno de Winter made an amusing video demonstrating how prevalent the issue is. I highly recommend you watch it before continuing to read. The video was made by injecting this JavaScript into the browser console. You can do this too by

  1. Opening almost any website (e.g. www.google.com) in your browser
  2. Open the browser developer tools (press F12 or ctrl+shift+i)
  3. Click on the Console tab
  4. Copy and paste the JavaScript and press enter

While you may argue that this does not constitute a vulnerability because we’re essentially attacking ourselves, the fact remains that if an attacker can manage to reflect content to the HTML source (e.g. Reflected XSS) then they can reflect any malicious payload they choose, such as a script that steals credentials or the session token enabling session hijacking. In other words, if there are any XSS vulnerabilities on the site (and based on the OWASP Top 10 we know they’re everywhere), then its game over.
Now try to inject the same JavaScript into a site with a strong Content Security Policy implemented, such as https://www.mozilla.org/. As you can see, the browser does not shake and no music is played. If you look in the console, there are error messages indicating that the browser refused to load the external stylesheet and MP3 file because they violated the Content Security Policy.

- image002 - Content Security Policy 101 | Pure Hacking

You can easily inspect the CSP for www.mozilla.org because its returned in the server response headers in every request. As you can see below, Mozilla locks down which assets and which 3rd party domains are trusted:

- image003 - Content Security Policy 101 | Pure Hacking

Cross Site Scripting attacks are successful because the allow malicious users to modify the page’s contents. CSP provides a way that website owners can tell visiting browsers what content should be loaded, everything else is blocked. By implementing a solid CSP, you provide a secondary defence against XSS, block attackers from framing your site (Clickjacking) and help protect against Sidejacking attacks by preventing mixed content. In a follow up post, I’ll go into more details on how to implement and debug CSP.



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here