Web Security: With a Content Security Policy Against Cross-Site Scripting, Part 2

Cross-site scripting (XSS) remains one of the most common security threats to web applications. Despite advanced security mechanisms, attackers continue to find new ways to exploit XSS vulnerabilities. Development and security teams can use Content Security Policy (CSP) to effectively protect against XSS.

Advertisement

The first part of a two-part article series explains the concepts and processes of a content security policy. The next episode clarifies advanced problems and questions.

Problem with content protection policy

Modern web applications often use a variety of scripts that dynamically reload additional scripts. A widget that is integrated into a web application may require additional JavaScript files that it reloads independently.

For example, if a widget requires a JavaScript file https://platform/widget.js from an external content delivery network (CDN), add that domain to the CSP rules to allow loading of the external JavaScript file. Should be listed:

Content-Security-Policy: script-src 'self' https://platform/widget.js

so far so good. However, this external JavaScript file potentially reloads additional JavaScript files from other CDNs. These should also be in CSP:

HashiCorp: New names and features for Terraform, Packer, and Vault

Content-Security-Policy: script-src 'self' 
https://platform/widget.js 
https://platform_one/script.js  
https://platform_two/index.js 

This game can go on continuously and result in a large CSP rule that needs to be constantly maintained.

This is why many people use the Content Security Policy header Feeling impractical for a long time,

Luckily, new instructions arrived soon strict-dynamic The way out of suffering.

automatic trust transfer

keyword strict-dynamic Allows a script with nonce to load and execute additional scripts. This applies even if reloaded scripts are not explicitly listed as trusted in the CSP rules.

As shown in the figure, the CSP rules allow the browser to load and execute both https://platform/widget.js and the required https://platform_one/script.js, as long as the loaded script A nonce has been provided in . However, running the https://platform_one/evil.js script is prohibited because it neither contains a nonce nor is it loaded by a script that the browser already trusts.

There strict-dynamic Designed to deal with domain clutter in the CSP rule, it cannot be used for URLs, but only allows unapproved scripts to load additional resources and execute them. It automatically ignores URL-based expressions in CSP rules when a browser clicks. strict-dynamic Hit.

CSP nonsense in modern single page application

To use CSP nonce, it is necessary to calculate a new nonce value for each new request to the application and deliver it within the CSP HTTP header. However, this requires partial server-side rendering of the application, because the calculated nonce is also in script-The day will have to be shown. For Express applications, this can be done using the npm package ejs – Embedded JavaScript Templating For example look like this:

//index.ejs

  
    
  


//server.js
const csp_nonces = {
  directives: {
    'script-src': (NONCE) // NONCE refers to a 
                          // freshly calculated nonce
  }
}

app.get("/", expressCspHeader(csp_nonces), (req, res) => {
  // Render the EJS page with the nonce
  // The middleware exposes the calculated nonce on req.nonce
  res.render(`index`, { nonce: req.nonce });
});

express middleware expressCspHeader The CSP adds a new calculated nonce value to the HTTP header and also makes the value available as a request object. The application uses the latter to pass the new nonce value to the EJS file. When the HTML page is rendered, it inserts the passed nonce value. script-Tag for placeholder.

However, if the application is distributed without a template engine and without server-side rendering, the use of CSP nonce is often not possible and one must resort to CSP hashes instead. However, before resorting to hashing, it is recommended to familiarize yourself with the server-side rendering options of the framework you are using. For example, the front-end framework Angular has made a significant impact Developing features for server-side rendering Invested in making this process as easy as possible.

An alternative approach is to use Functions as a Service (FaaS) such as AWS Lambda or Microsoft Azure Functions. FaaS simply handles the rendering of the Index.html file using the template engine and automatically adds the required CSP nonces at the relevant locations. All other static files such as JavaScript, style sheets or frontend files can still be easily served by the content delivery network.

Incorporating CSP nonce into a content security policy often requires adjustments to the server architecture to ensure the security of web applications.

Unfortunately, sometimes teams want to protect themselves from cross-site scripting attacks but have no way to modify their application’s HTTP response headers. In this case, you can integrate some content security rules directly into the HTML document via meta tags to ensure at least basic protection against XSS attacks.

CSP as meta tag

Content security policy rules can be defined not only through HTTP headers, but also in meta tags within a website’s HTML documents. The alternative method is especially helpful if you don’t have direct access to the server’s HTTP header configuration or if you want to do a quick test.

To define CSP rules through meta tags, insert -in element -Bereich des HTML-Dokuments ein, setzt das Attribut http-equiv But Content-Security-Policy and gives guidelines content-Speciality: