[Tenable] API missing/inadequate response headers (due 8/31/19)

[lbeaufort]

1. Insecure 'Access-Control-Allow-Origin' header:

Cross Origin Resource Sharing (CORS) is an HTML5 technology which gives modern web browsers the ability to bypass restrictions implemented by the Same Origin Policy. The Same Origin Policy requires that both the JavaScript and the page are loaded from the same domain in order to allow JavaScript to interact with the page. This in turn prevents malicious JavaScript being executed when loaded from external domains. The CORS policy allows the application to specify exceptions to the protections implemented by the browser, and allows the developer to whitelist domains for which external JavaScript is permitted to execute and interact with the page. A weak CORS policy is one which whitelists all domains using a wildcard (*), which will allow any externally loaded JavaScript resource to interact with the affected page. This can severely increase the risk of attacks such as Cross Site Scripting etc. Scanner detected that the CORS policy being set by the server was weak, and used a wildcard value. This is evident by the Access-Control-Allow-Origin header being set to *.
It is important that weak CORS policies are not used. Policies can be hardened by removing the wildcard and individually specifying the domains where the trusted JavaScript resources are located.
Remediation path: If the list of hosts for externally hosted JavaScript resources is excessive, then a whole top level domain can be whitelisted by using a combination of the wildcard and the domain (example: *.tenable.com).

References:
https://www.owasp.org/index.php/CORS_OriginHeaderScrutiny
https://developer.mozilla.org/en-US/docs/Waeb/HTTP/Access_control_CORS

2. Missing 'X-Content-Type-Options' Header:

The HTTP 'X-Content-Type-Options' response header prevents the browser from MIME-sniffing a response away from the declared content-type. The server did not return a correct 'X-Content-Type-Options' header, which means that this website could be at risk of a Cross-Site Scripting (XSS) attack.

Remediation path: Configure your web server to include an 'X-Content-Type-Options' header with a value of 'nosniff'.

References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xcto

3. Missing 'X-Frame-Options' header

Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. The server didn't return an X-Frame-Options header which means that this website could be at risk of a clickjacking attack.  The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page inside a frame or iframe. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
Remediation path: Configure your web server to include an X-Frame-Options header.
References:
https://www.owasp.org/index.php/Clickjacking
http://tools.ietf.org/html/rfc7034
https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

4. Missing 'X-XSS-Protection' Header

The HTTP 'X-XSS-Protection' response header is a feature of modern browsers that allows websites to control their XSS auditors. The server is not configured to return a 'X-XSS-Protection' header which means that any pages on this website could be at risk of a Cross-Site Scripting (XSS) attack. This URL is flagged as an specific example.
Remediation path: Configure your web server to include an 'X-XSS-Protection' header with a value of '1; mode=block' on all pages.
References:
https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xxxsp
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

5. Missing Content Security Policy

Content Security Policy (CSP) is a web security standard that helps to mitigate attacks like cross-site scripting (XSS), clickjacking or mixed content issues. CSP provides mechanisms to websites to restrict content that browsers will be allowed to load. No CSP header has been detected on this host. This URL is flagged as a specific example.
Remediation path: Configure Content Security Policy on your website by adding 'Content-Security-Policy' HTTP header or meta tag http-equiv='Content-Security-Policy'.
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://csp-evaluator.withgoogle.com/
https://developers.google.com/web/fundamentals/security/csp/
https://content-security-policy.com/

[lbeaufort]

Looks like the dev API is getting flagged and we don't have the API umbrella in place in dev, so we should make these changes on the application side.

[lbeaufort]

1. Recommend not to implement. Public APIs need to have a "*" in their 'Access-Control-Allow-Origin' header in order to stay public. Other applications need to be able to pull in our data in order for our API to stay public and open.
   References: https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/#
   https://fetch.spec.whatwg.org/#basic-safe-cors-protocol-setup

[lbeaufort]

CSP requires 'unsafe-inline' for Swagger docs to load: swagger-api/swagger-ui#3370

[lbeaufort]

There are a lot of moving parts here. I've been experimenting with manual deploys but I'm trying to understand the repercussions of all these headers.

[dorothyyeager]

Having a hard time connecting the issues but this issue is blocked by https://github.com/fecgov/fec-accounts/issues/201, which needs to be done first.

[dorothyyeager]

Removed the "blocked" since the issue blocking it was resolved with a hotfix today.