Summary: Content Security Policy (CSP) implemented unsafely.
Reported by
ajukjose...@gmail.com,
Sep 15 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/60.0.3112.113 Chrome/60.0.3112.113 Safari/537.36 Steps to reproduce the problem: 1. Manual 2. Scanning 3. Result What is the expected behavior? Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. What went wrong? Summary: Content Security Policy (CSP) implemented unsafely. Steps to reproduce: 1. Manual Scan 2. Implementation 3. Result Browser/OS: Chromium/Linux Attack scenario: Content Security Policy (CSP) implemented unsafely. This includes 'unsafe-inline' or data: inside script-src, overly broad sources such as https: inside object-src or script-src, or not restricting the sources for object-src or script-src. Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. A primary goal of CSP is to mitigate and report XSS attacks. XSS attacks exploit the browser's trust of the content received from the server. Malicious scripts are executed by the victim's browser because the browser trusts the source of the content, even when it's not coming from where it seems to be coming from. CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those whitelisted domains, ignoring all other script (including inline scripts and event-handling HTML attributes). As an ultimate form of protection, sites that want to never allow scripts to be executed can opt to globally disallow script execution. READ THIS TO KNOW HOW IT AFFECT A SAMPLE SITE : [ Let's consider a page located at http://example.com/signup.html. It uses the following policy, disallowing everything but stylesheets from cdn.example.com. Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports The HTML of signup.html looks like this: <!DOCTYPE html> <html> <head> <title>Sign Up</title> <link rel="stylesheet" href="css/style.css"> </head> <body> ... Content ... </body> </html> Can you spot the mistake? Stylesheets are only allowed to be loaded from cdn.example.com, yet the website tries to load one from its own origin (http://example.com). A browser capable of enforcing CSP will send the following violation report as a POST request to http://example.com/_/csp-reports, when the document is visited: { "csp-report": { "document-uri": "http://example.com/signup.html", "referrer": "", "blocked-uri": "http://example.com/css/style.css", "violated-directive": "style-src cdn.example.com", "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports" } } As you can see, the report includes the full path to the violating resource in blocked-uri. This is not always the case. For example, when the signup.html would attempt to load CSS from http://anothercdn.example.com/stylesheet.css, the browser would not include the full path but only the origin (http://anothercdn.example.com). The CSP specification gives an explanation of this odd behaviour. In summary, this is done to prevent leaking sensitive information about cross-origin resources. ] Thank You, Aju K Jose Did this work before? Yes Linux latest version. Chrome version: 60.0.3112.113 Channel: n/a OS Version: 14.04 Flash Version: Shockwave Flash 25.0 r0
,
Sep 21 2017
Unable to triage this issue from TE-end, hence adding TE-NeedsTriageHelp label for further triage
,
Sep 25 2017
I'm afraid I don't quite understand the concern. Could you perhaps provide a "this is what is happening"/"this is what I expect to be happening" to make it easier to identify what you're referring to?
,
Sep 25 2017
Sorry it was not a bug at chromium project. It was at an google domain
,
Sep 25 2017
Please see https://www.google.com/about/appsecurity/reward-program/ for details on reporting security issues for Google's applications and services. All Google teams are well aware of CSP, so please be sure to file an issue only if you can identify a specific site or service with a CSP problem. |
|||
►
Sign in to add a comment |
|||
Comment 1 by rdsmith@chromium.org
, Sep 15 2017