Security: Bypassing CORS restrictions using X-XSS-PROTECTION report value
Reported by
michael....@gmail.com,
Feb 13 2017
|
||||||||||||
Issue descriptionVULNERABILITY 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".
,
Feb 13 2017
,
Feb 14 2017
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).
,
Feb 14 2017
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/.
,
Feb 23 2017
,
Feb 24 2017
,
Feb 24 2017
,
Feb 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/220ff33573e9adaadc4264dab5b2bbbbe0d5e7f8 commit 220ff33573e9adaadc4264dab5b2bbbbe0d5e7f8 Author: mkwst <mkwst@chromium.org> Date: Sat Feb 25 13:09:21 2017 Change XSS Auditor report's MIME type. `application/json` might be dangerous to send to servers who aren't expecting it. Let's move to a MIME type specific to this reporting structure. BUG= 691726 Review-Url: https://codereview.chromium.org/2717463006 Cr-Commit-Position: refs/heads/master@{#453086} [modify] https://crrev.com/220ff33573e9adaadc4264dab5b2bbbbe0d5e7f8/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-expected.txt [modify] https://crrev.com/220ff33573e9adaadc4264dab5b2bbbbe0d5e7f8/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-full-block-expected.txt [modify] https://crrev.com/220ff33573e9adaadc4264dab5b2bbbbe0d5e7f8/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-replace-state-expected.txt [modify] https://crrev.com/220ff33573e9adaadc4264dab5b2bbbbe0d5e7f8/third_party/WebKit/Source/core/loader/PingLoader.cpp
,
Mar 7 2017
This is now fixed; Mike is leaving it open for a few more days to watch traffic on blink-dev@ discussion.
,
Mar 31 2017
Been a few weeks now, I presume this is OK to move to fix.
,
Apr 1 2017
,
Apr 18 2017
,
Apr 19 2017
,
Jul 8 2017
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
,
Apr 25 2018
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by elawrence@chromium.org
, Feb 13 2017