How to fix CWE 829 issues in Veracode

Introduction

This article will help you to fix the CWE 829 issues that Veracode finds. It explains:
  • The basics of this flaw, and why Veracode flags it
  • What you can do to fix the flaw
  • What you can do if your fix causes incorrect behavior in the application.

About Content-Security-Policy

What is it?

Content-Security-Policy (or “CSP”) is a type of HTTP response header that your web applications can use to increase their security. A CSP protects an application against some types of attacks, like Cross Site Scripting (XSS) and data injection attacks. It lets you tell a web application to only run scripts from the sources you trust. Doing this helps the application to be secure because a hacker cannot force the application to run new scripts. It is a “defense-in-depth measure”, which means that you should use it in addition to other ways to prevent XSS, but not as the main way to stop XSS.

How does it work?

A CSP is made of parts that are called "directives". The directives let you list the places from where a page can load and run resources like scripts. If the application tries to run a script from a place that is not on the list, then the CSP will block it. There are different directives to use for different kinds of data. There are many types, but these two are most important for Veracode flaws:
  • Script-src: This directive lets you limit the sources of JavaScript to run.
  • Default-src: This directive is for the default setting. As the default policy, any data that other directive settings do not cover will be covered by this one instead. So for example, if script-src is not defined, then Javascript will be loaded according to the rules of default-src.
For example, to allow content only from the site’s own domain, you can use this CSP:
Content-Security-Policy: default-src 'self'

You can have more than one directive by using a semicolon between them, like this:
Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *


For example, in the example above, *.mailsite.com is on the “source list” of the default-src directive, so the application can load content if it comes from a domain ending in mailsite.com. Any directive that ends in -src lets you select a source list. You can also add special “keywords” to the source list, which allow extra options. There are many of these, but the two you need to know for Veracode flaws are:
  • self: This means that the page can load resources from the same “origin” as itself (the same scheme, host and port)
  • unsafe-inline: A dangerous keyword that we don’t recommend. It means that the page can run any inline scripts. If a hacker finds an XSS flaw in your app and uses it to insert a harmful inline script into the page, the CSP will allow it to run if this keyword is set. Later, this article will talk more about why it is most secure to load all scripts dynamically. If inline scripts are required and cannot be moved, there are also ways to mark the ones that are safe, which this article will also talk more about later.

There are more example CSPs in the references, which are at the end of this document.

Do I need to add a Content-Security-Policy?

We recommend that web applications use a Content-Security-Policy whenever it is possible. This is because a CSP makes it harder for a hacker to attack your application’s users with malicious scripts. If your app runs on a platform that supports CSP, then we recommend using it.
Sometimes, it is not possible to add a Content-Security-Policy. For example, it you are using technology that doesn’t support a CSP, then it will not be possible to add it. If you received a CWE 829 flaw but CSP is not supported, then it will not be possible to close the Veracode flaw by code changes. In a case like this, you can request a mitigation. We recommend also finding other ways to prevent XSS that work with your platform.

How to see details on Veracode findings

If Veracode reported a CWE 829 flaw and you need to fix it, you should first thing get more information about why the flaw exists. Currently, there are five possible reasons why Veracode can flag this flaw. You can see which one by viewing the details in the Triage Flaws view of the Veracode Platform, or in the JSON file for the flaw. To see Triage Flaws, first log into the Veracode platform, open your application’s profile, then open the scan with the CWE 829, and click “Triage Flaws” from the left-nav bar. Once there, click on the flaw(s) whose CWE ID is 829. You will see a detailed description of why the issue was flagged, including a record of the HTTP response that the scanner used to flag the issue (this is on the Request/Response tab). Please note: this information is not in the PDF reports. Do not use the PDF report if you are trying to fix the flaw – use the Veracode Platform instead.

Why did Veracode identify CWE 829 in my Dynamic scan?

A Veracode dynamic scan reports CWE 829 if it either sees that the web application does not use a CSP, or if it has a CSP that is configured insecurely. Veracode will report one instance of CWE 829 per unique host. Right now there are five possible reasons why CWE 829 could be flagged in a Veracode scan. These are:
    1. The app does not use a Content-Security-Policy at all.
    2. It uses a CSP, but the CSP has syntax errors. This is a risk because the browser will not apply the CSP if it has syntax errors.
    3. It uses a CSP, but it does not have a script-src directive OR default-src directive. A CSP needs to have at least one of these to make loading scripts secure.
    4. It uses a CSP with script-src or default-src, but the source list allows all sources.  If a CSP allows all sources and does not block any, then it does not add any security. For example, the source list might include *, http://* or https://*.
    5. It uses a CSP with the unsafe-inline directive, AND does not specify a nonce or hash.  If you add the unsafe-inline directive to a CSP, it allows the app to run any inline script in an HTML page or similar. Unsafe-inline could allow unexpected malicious code to run if a hacker uses XSS to add it to a document. This is why it’s called unsafe-inline. To mitigate this risk, you can use the optional nonce or hash features to allow only certain files. (There is more information about this below.) If these are not used, then unsafe-inline is a risk, so Veracode will report on it.
 

How can I fix CWE 829?

First, understand the reason for the CWE 829 issue. Then, take the following steps for that reason:

No CSP at all

If there is no CSP at all, you should try to add one. You can add a CSP at the web server level. The References at the end of this article have links to other guides that show you how to add a CSP in several modern web servers. Read them to get started.

CSP with syntax errors

If the CSP has syntax errors, then you should fix them. This is the same as fixing syntax errors in code. Is there an unclosed angle bracket? (a < without a matching >) Is there an extra or missing “, or is one of the directives spelled wrong? The Veracode tool cannot tell you the exact syntax error, but your eyes can.

CSP with no script-src or default-src

If your CSP does not have a script-src or default-src directive, you should add one. For its source list, list all of the hosts from which your application can load and run scripts. If you have inline JS, you might have to move the scripts to separate files and store them in these locations.

CSP with script-src or default-src that allows *

If your CSP has a source list that allows the app to load content from any source (by including *, http://* or https://*), you should remove these entries from the source list. Instead, list the specific domains that files can be loaded from. Please note: you can still use * wildcards as part of elements like *.example.com, and Veracode will not flag this as an issue. Only when the * allows every host is it unsafe.

CSP with unsafe-inline (without nonce/hash)

If you use a CSP with unsafe-inline, you should try to move the inline JS into separate files, then include those files in the HTML pages. Make the file watch and attach itself to the DOM when needed, like in this example:
In HTML:
<script src="/dist/something.js"></script>

something.js:
$(document).ready(function() {
    $('foo').click(function() {

    });
})();

This is a good alternative to mixing lots of JS into your HTML.
Next, you remove unsafe-inline from the CSP, and add a script-src directive to it. In that directive, you include a source list with the domains that you’ve moved the files to.

Another reason?

These are the only current reasons why a Veracode dynamic scan will flag CWE 829. Older results may have included different reasons like unsafe-eval, but current results will not report this. If you have results that show a CSP flagged because of unsafe-eval, run a new dynamic scan to get more current results. Otherwise, all CWE 829 flaws will belong to one of these three categories.

I tried to fix it, but now my web app is not functioning correctly

Sometimes, if a CSP is incorrectly configured, it will cause a page to not load correctly. Here are some tips to troubleshoot:

  • First, see the specific error message in your browser console before seeking outside help. The error message has more information about why the page is not loading correctly, which you or someone else can use while researching a solution for the problem. There will probably be an error message that specifies the source that data tried to be loaded from, and that the source isn’t on the CSP’s list.
    • Advanced: in addition to seeing errors in the browser console, you can also enable violation reports, which send reports about CSP violations to a destination on a server. You can enable sending them by adding the report-uri policy directive to the CSP, and listing at least one URI to deliver the reports to. Next, you need to set up your server to receive the reports. It can store or process them in whatever manner you determine is appropriate. Steps to do so can be seen here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP.
    • By default, these reports are not sent.
  • Did the problem begin once you removed unsafe-inline? If so: have you already tried to move all inline JS to external files, and add the location of these files to a CSP? If you have not done this, this is the first step. If you have done this but are still seeing incorrect behavior, obtain an error message by following the previous step, and use the information in that message to correct the problem.
  • To help troubleshoot, you can also temporarily run the CSP in “report-only mode”. When this mode is on, the policy is not enforced, but any violations are reported to a URL that you provide. You can use the report-only header to test changes to the CSP without deploying it.
  • Unsupported browser? It's supported by all major browsers except Internet Explorer, which is now deprecated. If your app is IE-only, then we can't offer recommendations for how to make a CSP. If you want your app to be secure, your bigger priority should be migrating the app off of IE.
  • Make sure that you understand the CSP you are adding. Do not copy a CSP from other references like StackOverflow or other apps in your company without checking or altering it to ensure it meets your application’s needs. If you do so and seek help from another person on resolving the CWE 829 flaw, be prepared to explain and defend the CSP’s design choices. Do not ask Veracode to write your CSP for you.
  • Remember, CSP can’t be set for everything. If your web application is built or hosted with technology that does not support it, you can consider mitigating CWE 829. We still recommend finding a different way to prevent XSS if you do this.
 

Alternatives to removing inline scripts

It is still easier to move your inline scripts to .js files and have a simple CSP, than to have a complex CSP with many sources. This will require the least work and be the most maintainable. would be to put scripts in .js files. If you do not want to try this, alternatives include:
  • Add hashes for all of the inline scripts in your app. To do this, you have to collect the hashes for every inline script. If you have many of them, you'll eventually hit the header size limit of 8 KB. And every time a script gets added or updated, you have to change the CSP.
  • Implement something that calculates hashes for scripts in the request and puts them in the CSP header dynamically. This is more work and possibly difficult to implement depending on the platform. A poor implementation could add hashes to injected scripts, which would defeat the purpose.
  • Implement something that adds nonces for inline scripts in each request. It would be difficult to do this correctly. Its effectiveness will be lessened if you hardcode or re-use nonce values, or use a low-entropy RNG, or things like that. You would also still need to touch every single inline script in the app to add a nonce attribute anyway.
For these reasons, our main recommendation is to move your inline scripts to external JS files and allow their location in a CSP.

More information


 

Topics (5)

Related Articles

Related Topics

    Ask the Community

    Get answers, share a use case, discuss your favorite features, or get input from the Community.