1661597 - Possible to send XHR POST request from different origins - SOP bypass

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[René Kroka]

Attachment: XHR-POC.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36

Steps to reproduce:

Altough in console we can see that POST request was denied, it actually went through and sent the data.

1. Go to my domain for example: https://xdv.cz
2. In console enter:

function submitRequest()
{
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://www.website.com", true);
xhr.setRequestHeader("Accept", "/");
xhr.setRequestHeader("Accept-Language", "en-US,en;q=0.9,cs;q=0.8,sk;q=0.7");
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; charset=UTF-8");
xhr.withCredentials = true;
var body = "valid=value&another=valid";
var aBody = new Uint8Array(body.length);
for (var i = 0; i < aBody.length; i++)
aBody[i] = body.charCodeAt(i);
xhr.send(new Blob([aBody]));
}
submitRequest();
or simply host in script tags on your website (you have to edit the XHR request to where you want to send your POST data.)
3. Request being send and POST data saved.

PoC video attached - accounts.google.com - sent from my domain xdv.cz

I have reported this also to chromium bugs as it works there aswell not sure if FF is related with Chrome.

It seems that also same-site cookie is bypassed.

Actual results:

POST request accepted by Firefox browser allowing to send XHR request from different origins, allowing SOP bypass.

Expected results:

POST request not accepted by browser.

Comment 1

[:Gijs (he/him)]

(In reply to René Kroka from comment #0)

Altough in console we can see that POST request was denied, it actually went through and sent the data.

How do you propose the webbrowser should get the response headers that indicate the request was denied, without making the request? This is a chicken-egg problem. It was solved for "complex" requests by the invention of "preflight" OPTIONS requests, but your request in comment #0 is a "simple" request because it is a POST with application/x-www-form-urlencoded mimetype. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests .

This is expected behaviour. Note that this isn't a fetch/xhr issue:

Even without all this, a similar request could be made by e.g. creating an iframe with a <form> and calling .submit() on the form: the caller would not have access to the response, but the request would be made (even without the relevant CORS headers!). If the request being made is problematic then you should secure your web application against this kind of thing by e.g. using CSRF tokens, checking Origin and/or Referer headers, and other well-documented techniques (this is not a complete list; you're posting on a bug tracker, not a help forum).

I guess either way we'll need to keep this report hidden as it appears Google may wish to fix their accounts setup so it doesn't echo back passwords submitted in this way...

It seems that also same-site cookie is bypassed.

This would be a bug if it happened, but your "PoC" video doesn't show it happening. If I go to https://samesite-sandbox.glitch.me/ and then submit a POST to it using your snippet from comment #0 from a different website/origin, only the SameSite=None cookies are passed, which seems correct to me. Are you seeing something else? And if so, can you provide more detailed steps on how to reproduce this?