Closed Bug 1194847 Opened 9 years ago Closed 9 years ago

Synthesized responses shouldn't be subject to CORS checks

Categories

(Core :: DOM: Service Workers, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox43 --- fixed

People

(Reporter: jdm, Assigned: ehsan.akhgari)

References

Details

Attachments

(2 files)

<img src="http://cross.origin" crossOrigin="anonymous"> causes nsCORSListenerProxy::CheckRequestApproved to fail if the response doesn't include the Access-Control-Allow-Origin header, for example. If this response is synthesized by a service worker, rather than coming from the network, we should not perform such checks. This is tested by fetch-canvas-tainting.https.html and fails in a trunk build.
Blocks: 1194848
Assignee: nobody → ehsan
Attachment #8649485 - Flags: review?(michal.novotny)
Please note that this will be tested with bug 1194848.
Comment on attachment 8649486 [details] [diff] [review] Part 2: Bypass CORS checks if the response of a channel has been synthesized Review of attachment 8649486 [details] [diff] [review]: ----------------------------------------------------------------- I don't actually know this well enough to usefully review this.
Attachment #8649486 - Flags: review?(jonas)
Shouldn't a same-origin response get the same treatment? In general it seems to me that the distinction is "readable vs. opaque", not "synthesized vs. loaded from the network".
Comment on attachment 8649486 [details] [diff] [review] Part 2: Bypass CORS checks if the response of a channel has been synthesized Nikhil, see comment 5 please.
Attachment #8649486 - Flags: review?(nsm.nikhil)
Comment on attachment 8649486 [details] [diff] [review] Part 2: Bypass CORS checks if the response of a channel has been synthesized Review of attachment 8649486 [details] [diff] [review]: ----------------------------------------------------------------- Also add a note to ::: dom/security/nsCORSListenerProxy.cpp @@ +547,5 @@ > LogBlockedRequest(aRequest, "CORSRequestNotHttp", nullptr); > return NS_ERROR_DOM_BAD_URI; > } > > + nsCOMPtr<nsIHttpChannelInternal> internal = do_QueryInterface(aRequest); Since preflight requests aren't intercepted by SWs, it is ok to return early here and not validate the synthesized response for a correct preflight response (which is done later in this method). Could you add a very important comment to NS_StartCORSPreflight() near the call ForceNoIntercept() cataloging that if we ever change the situation to allow SWs to intercept preflights then the check this patch introduces is not enough. Thanks!
Attachment #8649486 - Flags: review?(nsm.nikhil) → review+
(In reply to Nikhil Marathe [:nsm] (please needinfo?) from comment #7) > Since preflight requests aren't intercepted by SWs, it is ok to return early > here and not validate the synthesized response for a correct preflight > response (which is done later in this method). Could you add a very > important comment to NS_StartCORSPreflight() near the call > ForceNoIntercept() cataloging that if we ever change the situation to allow > SWs to intercept preflights then the check this patch introduces is not > enough. Thanks! Good point, will do. I will also add a MOZ_ASSERT(!mIsPreflight) in the body of this condition for additional safety.
ping?
Comment on attachment 8649485 [details] [diff] [review] Part 1: Make it possible to tell whether the response of a channel has been synthesized; r=michal Patrick, can you please help review this? Thanks!
Attachment #8649485 - Flags: review?(mcmanus)
Attachment #8649485 - Flags: review?(michal.novotny) → review+
Comment on attachment 8649485 [details] [diff] [review] Part 1: Make it possible to tell whether the response of a channel has been synthesized; r=michal Thanks for the review!
Attachment #8649485 - Flags: review?(mcmanus)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: