Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 3 users
Status: Fixed
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Android, Windows, Chrome, Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment
Security: Bypassing CORS restrictions using X-XSS-PROTECTION report value
Reported by michael....@gmail.com, Feb 13 2017 Back to list
VULNERABILITY DETAILS
By setting up a header of "X-XSS-Protection: 1; report=cross-domain-uri" it is possible to send cross-origin post request with content-type value of "application/json". According to the spec here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS any request containing content-type of "application/json" should trigger a pre-flight request - but this is not happening. Imagine a situation where an application isn't expecting any parameters for an endpoint of https://app.com/user/1000/delete for a POST request and the only CSRF-Protection is based on CORS - this would bypass this restriction.

VERSION
Chrome Version: 56.0.2924.87 stable
Operating System: Windows 10

REPRODUCTION CASE
By browsing the following url: http://mish.host-ed.me/index.php?a=%3Cscript%3Ealert(1)%3C/script%3E you can see that the xss protection is triggered and so a report is sent to "https://tweetdeck.twitter.com/metrics" despite the fact the endpoint is not sending an "Access-control-allow-origin" header. The sent report contains a content-type of "application/json".
 
Components: Blink>SecurityFeature
Does the report sent contain any credentials (cookies or authentication headers)? Is this limited to X-XSS-Protection, or any CSP / Expect-CT reporting?
Labels: Needs-Feedback
It seems the report doesn't contain any credentials, but it does work also for CSP reporting (with a different content-type: application/csp-report).
Comment 4 by mkwst@chromium.org, Feb 14 2017
Cc: elawre...@chromium.org
Labels: M-58 OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows Pri-2
Status: Available
We should probably give these their own content type, just as we've done for CSP reporting. Happily(?), none of this is specified, so we can just make something up: `application/xss-auditor-report`, for instance. Given that the attacker doesn't control the structure of the data, this seems unlikely to be an effective attack vector, but it's worth moving off of a content type that folks might be actively parsing.

Would you like to poke at this, Eric? Should be a tiny change to https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/PingLoader.cpp?rcl=2302333f9298327000a6d03d5c5adfe4ed874266&l=528

Note: Whenever we get around to implementing The Glorious Future, we should roll this reporting mechanism into https://wicg.github.io/reporting/.
Comment 5 by mkwst@chromium.org, Feb 23 2017
Labels: xssauditor
Comment 6 by mkwst@chromium.org, Feb 24 2017
Owner: mkwst@chromium.org
Status: Started
Labels: -Needs-Feedback Security_Impact-Stable Security_Severity-Low
This is now fixed; Mike is leaving it open for a few more days to watch traffic on blink-dev@ discussion.
Status: Fixed
Been a few weeks now, I presume this is OK to move to fix. 
Project Member Comment 11 by sheriffbot@chromium.org, Apr 1
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: Release-0-M58
Labels: CVE-2017-5069
Project Member Comment 14 by sheriffbot@chromium.org, Jul 8
Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sign in to add a comment