search

annevk / orb

Opaque Response Blocking (CORB++)
Creative Commons Zero v1.0 Universal
35 stars 4 forks source link

It is unclear when "To determine whether to allow response response to a request request, run these steps" runs. #35

Closed smaug---- closed 1 year ago

smaug---- commented 2 years ago

.

anforowicz commented 2 years ago

I'd defer to @annevk for a more authoritative answer, but I imagine that ORB algorithm would be run at roughly the same time as things like X-Content-Type-Option checks in the main fetch algorithm:

If response is not a network error and any of the following returns blocked

  • should internalResponse to request be blocked as mixed content
  • should internalResponse to request be blocked by Content Security Policy
  • should internalResponse to request be blocked due to its MIME type
  • should internalResponse to request be blocked due to nosniff

then set response and internalResponse to a network error.

FWIW, the CORB steps removed in an earlier Fetch commit were triggered in a slightly different place, but I am guessing that this was because CORB (unlike ORB) was blocking by injecting an empty response body (rather than by causing a network error).

PS. I think that ORB's goals are quite close to the original idea behind Cross-Origin Resource Poilcy, so maybe these 2 things should be triggered together. OTOH, I am not sure where exactly CORP is triggered by the main fetch algorithm.

anforowicz commented 2 years ago

BTW, to get the full security benefits of CORP, ORB, CORB, etc one has to ensure that these algorithms are run before disclosing the response body (and response headers) to the renderer process hosting the execution context / origin that initiated the request. Since the Fetch spec is agnostic to the process model, CORB used to just have an implementation note saying something about this: https://github.com/whatwg/fetch/commit/78f9bdd73e8c6893d629c2ce4a3bde7eb01cac59#diff-b4827ee42aceaf9dc3e7216f72262d81c32217e9996fb70a657f259e3ac92604L4155

This is only an effective defense against side channel attacks if noCorsResponse is kept isolated from the process that initiated the request.

annevk commented 1 year ago

I tried to clarify this in https://github.com/annevk/orb/commit/61c1be761fca35288b6c90249da66ab563f1074c.

If you look at https://whatpr.org/fetch/1442.html#orb-algorithm and then click on the algorithm name you can find its caller (currently step 4 of HTTP fetch).

The CORP check runs slightly later as it also takes into account service worker responses due to the possibility of there being different enforcement policies.

Closing this as resolved therefore.