Closed
Bug 1366500
Opened 9 years ago
Closed 9 years ago
CORS issue in Beacon
Categories
(Core :: DOM: Security, defect)
Core
DOM: Security
Tracking
()
RESOLVED
DUPLICATE
of bug 1364925
People
(Reporter: s.h.h.n.j.k, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Steps to reproduce:
1. Go to http://mallory.csrf.jp/beacon/index3.html
Actual results:
Origin header could not be seen in request header of both http://csrf.jp/corsredirector.php and https://csp.csrf.jp/csp/log.php.
Expected results:
I guess even request should not reach to https://csp.csrf.jp/csp/log.php because Access-Control-Allow-Origin header is not presented in http://csrf.jp/corsredirector.php (This is what Chrome does). And this is regression of https://bugzilla.mozilla.org/show_bug.cgi?id=1080987
Updated•9 years ago
|
Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM: Security
Product: Firefox → Core
Version: 1.0 Branch → Trunk
Comment 1•9 years ago
|
||
It's not a CORS request and I don't see how this is a security issue. Unless I'm missing something this is a duplicate of bug 1272302 which is itself a duplicate of a larger issue around the Origin header, but none of that is really a security issue (although it can be used for defense-in-depth once we've consistently enabled it).
| Reporter | ||
Comment 2•9 years ago
|
||
-----------------------------------------------------------------------------
Otherwise, if the payload is a Blob and the resulting Content-Type is not a simple header, then a CORS preflight is made and the server needs to first allow such requests by returning the appropriate set of CORS headers (Access-Control-Allow-Credentials, Access-Control-Allow-Origin, Access-Control-Allow-Headers); same as XHR/fetch.
-----------------------------------------------------------------------------
https://w3c.github.io/beacon/#h-privacy
Request is sent to cross origin with *Content-Type: application/octet-stream* which is not simple request. And that cross origin request redirects to another cross origin. All request when without origin header. So nothing here is same-origin request.
Comment 3•9 years ago
|
||
Yeah, that Content-Type issue was fixed in bug 1364925 five days ago. That has not made it to Nightly yet?
| Reporter | ||
Comment 4•9 years ago
|
||
Not sure. I'm testing on stable release.
Comment 5•9 years ago
|
||
Bug 1364925 has been in nightly for 4 days now. As for the rest, this is a duplicate of either bug 1364925 or bug 1289387 but in either case doesn't look like a security issue to me.
Updated•9 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Comment 7•9 years ago
|
||
(In reply to s.h.h.n.j.k from comment #4)
> Not sure. I'm testing on stable release.
I can highly recommend testing on Nightly. Gets you test exciting new features earlier :-)
| Reporter | ||
Comment 8•9 years ago
|
||
(In reply to Frederik Braun [:freddyb] from comment #7)
> (In reply to s.h.h.n.j.k from comment #4)
> > Not sure. I'm testing on stable release.
>
> I can highly recommend testing on Nightly. Gets you test exciting new
> features earlier :-)
hahaha, thanks! Will start testing on nightly then :)
Updated•6 years ago
|
Group: dom-core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•