Protecting Suborigined content from non-suborigined content

[adob]

It is very useful to protect certain sensitive content, which can be put into a suborigin, (such as password change form OAuth consent forms) from being affected by XSS in the rest of the domain. The current spec already provides almost everything necessary except for the ability to protect sensitive data from leaking via XHR requests.

I propose we extend the XHR spec to block returning of responses to JS if the response contains a Suborigin header, and suborigin value does not match suborigin name of the requester document.

This blocking is similar to how it is done for simple XHRs when the response does not have CORS headers.

It is not good to punt on this to, say v2, because this is a potentially a breaking change.

Additional notes:

Depending on how Service Workers isolation is implemented, it may be possible for a SW to intercept fetches from a suborigin. It is desirable to also extend suborigin separation to SW, so that SW cannot intercept fetches from different suborigins. XSS in SW (or malicious SW) are rare, so risk seems low.

It might be useful to allow an endpoint to relax the XHR restriction with an Access-Control-Allow-Suborign header. This can be deferred to a later version, though.

[devd]

btw, have you seen #29 ?

basically, our thinking has always been: its doable but we need to think through all the scenarios and make sure we are safe and only then talk about it. I am not sure just blocking XHRs is enough.

Additionally, re punting to v2: this is one of the reasons we want to namespace (see some of the discussion in #40) . I don't think all suborigins want to be protected from parent origin and thus it will need to be an opt-in anyhow IMO. I am not saying we need to punt to v2 but that it is possible to do so.

[devd]

anyhow .. sorry for the delay; I need to dig up previous notes and read through your email to the list and respond. Hoping to do it this weekend.

[adob]

#29 and this are addressing same or similar use case, though I wouldn't phrase it as one origin being more trusted then another. 👍 to settling on some terminology like 'null suborigin'.

It's true that proposal here is not quite sufficient to protect servers in the general case. For example, if servers rely presence of certain request headers (like X-XSRF: 1) for security, then some refactoring would be needed. However, it makes it relatively easy to implement the protection.

With the current spec, if the server sees a 'Suborigin' header, it can infer that the request comes from the given suborigin and make a trust decision. However, if it does not see the header, it can't be sure if the request is coming from the parent or simply from a browser that does not implement Suborigins.

We should also forbid from clients from overriding the 'Suborigin' request headers on XHRs.

What kind of security/safety issues are you thinking about?

[annevk]

We should also forbid from clients from overriding the 'Suborigin' request headers on XHRs.

We should just name it Sec-suborigin then. https://fetch.spec.whatwg.org/#forbidden-header-name isn't meant to be extended. Filed #72.