Cross-Domain Misconfiguration
quipo opened this issue · comments
When using this library, and pen-testing the application with OWASP ZAP, we get a Medium severity alert:
| Medium | Cross-Domain Misconfiguration |
|---|---|
| Description | Web browser data loading may be possible, due to a Cross Origin Resource Sharing (CORS) misconfiguration on the web server |
| URL: | https://cdn.segment.com/analytics.js/v1/XXXXXXXXXXXXXXX/analytics.min.js |
| Evidence: | Access-Control-Allow-Origin: * |
| Solution | Ensure that sensitive data is not available in an unauthenticated manner (using IP address white-listing, for instance).Configure the "Access-Control-Allow-Origin" HTTP header to a more restrictive set of domains, or remove all CORS headers entirely, to allow the web browser to enforce the Same Origin Policy (SOP) in a more restrictive manner. |
| Reference | https://vulncat.fortify.com/en/detail?id=desc.config.dotnet.html5_overly_permissive_cors_policy |
| Tags | OWASP_2021_A01 OWASP_2017_A05 |
| CWE Id | 264 |
| WASC Id | 14 |
How do we configure the script inclusion so it doesn't raise this warning?
Similarly, getting Strict-Transport-Security Header Not Set (Low) alert.
HTTP Strict Transport Security (HSTS) is a web security policy mechanism whereby a web server declares that complying user agents (such as a web browser) are to interact with it using only secure HTTPS connections (i.e. HTTP layered over TLS/SSL). HSTS is an IETF standards track protocol and is specified in RFC 6797.
Hi @quipo thank you for your report, we start looking into this.
X-Content-Type-Options Header Missing
The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the declared content type.
Hmm, this looks like a false alarm -- unless I'm missing something.
The CORS header:
- has no bearing on the server / node (this repo).
- Is a deliberate configuration choice to be permissive, as the CDN should be able to be fetched from any origin, and we will basically disregard any additional headers that might trigger pre-flight. This would be a problem if we were a banking api, but not relevant to us.
There are potentially other ways to configure CORS that would hide this warning, but they would not affect security at all.
Thanks @silesky. That makes sense. What about the Strict-Transport-Security and X-Content-Type-Options headers though?
HSTS - not relevant, we do allow http.
nosniff - not relevant to static .js files, where mime type sniffing isn't a thing. If you absolutely want this header, you probably want to add it by using a proxy.
PS. Feel free to contact support if you feel like our security team has gotten it wrong. (FYI, these are old APIs with many many people using them and looking at them, so my hunch is that this is all fine).