• Description: Missing or misconfigured CSP headers and cross-domain configurations could allow unsafe content loading, unauthorized access from untrusted domains, and injection attacks.
• Location and Alerts:
o https://strr-ui-dev.web.app
CSP: Wildcard Directive
CSP: script-src unsafe-eval
CSP: script-src unsafe-inline
CSP: style-src unsafe-inline
Cross-Domain Misconfiguration
• Notes from Report:
The site allows unsafe configurations, including wildcard directives and unsafe scripts/styles in its CSP header, making it vulnerable to content injection. Additionally, cross-origin resource sharing (CORS) may allow untrusted domains to access the site’s resources.
Potential Fix
Add CSP Header: Configure a CSP header to control the sources for scripts, styles, and images.
Disallow Unsafe Directives: Remove unsafe-inline and unsafe-eval from script-src and style-src policies.
Specify Trusted Sources: Define specific, trusted domains in the CSP header and avoid wildcard directives.
Restrict Allowed Origins: Implement a restrictive CORS policy that allows access only from trusted domains.
Disable Wildcards in CORS: Avoid using * in Access-Control-Allow-Origin to prevent unrestricted access.
Potential Spike to Investigate
Check Existing CSP Headers: Open the developer tools in the browser on https://strr-ui-dev.web.app, navigate to the Network tab, reload the page, and look for CSP headers in the response headers of the initial page load.
Review CORS Configurations: Inspect the CORS policies by triggering cross-domain requests (e.g., using curl or a tool like Postman) and verify if non-trusted origins can access the API. Confirm if any Access-Control-Allow-Origin headers include wildcards (*).
Look for Policy Violations: If CSP headers exist, review browser console warnings for CSP policy violations to identify directives that may be too permissive.
Observations for Ticket 1
• Partial CSP: The current Content-Security-Policy header only limits framing and object embedding but does not include comprehensive CSP directives (e.g., script-src, style-src, img-src, default-src) to control the sources of scripts, styles, and images. This is an incomplete CSP, which means it may still be vulnerable to content injection attacks.
• Review Security of Permissive CORS Policy: If we can modify the server’s CORS policy, we could consider setting Access-Control-Allow-Origin to specific trusted origins instead of *. Could we do something like Access-Control-Allow-Origin: https://strr-ui-dev.web.app? Or we need to dynamically set allowed origins based on requests? Or optionally we could also try Access-Control-Allow-Origin: https://strr-ui-dev.web.app and Access-Control-Allow-Credentials: true. if we need to give access to public Apis. Is there a separate end point for them? I am inclined to think it put us at risk for CSRF which is Cross-Site Request Forgery. Ideally, we restrict Access-Control-Allow-Origin to specific domains given we serve sensitive data.
jdyck-fw
commented
1 week ago
• Description: Missing or misconfigured CSP headers and cross-domain configurations could allow unsafe content loading, unauthorized access from untrusted domains, and injection attacks. • Location and Alerts: o https://strr-ui-dev.web.app
• Notes from Report: The site allows unsafe configurations, including wildcard directives and unsafe scripts/styles in its CSP header, making it vulnerable to content injection. Additionally, cross-origin resource sharing (CORS) may allow untrusted domains to access the site’s resources. Potential Fix
Potential Spike to Investigate
Observations for Ticket 1 • Partial CSP: The current Content-Security-Policy header only limits framing and object embedding but does not include comprehensive CSP directives (e.g., script-src, style-src, img-src, default-src) to control the sources of scripts, styles, and images. This is an incomplete CSP, which means it may still be vulnerable to content injection attacks. • Review Security of Permissive CORS Policy: If we can modify the server’s CORS policy, we could consider setting Access-Control-Allow-Origin to specific trusted origins instead of *. Could we do something like Access-Control-Allow-Origin: https://strr-ui-dev.web.app? Or we need to dynamically set allowed origins based on requests? Or optionally we could also try Access-Control-Allow-Origin: https://strr-ui-dev.web.app and Access-Control-Allow-Credentials: true. if we need to give access to public Apis. Is there a separate end point for them? I am inclined to think it put us at risk for CSRF which is Cross-Site Request Forgery. Ideally, we restrict Access-Control-Allow-Origin to specific domains given we serve sensitive data.