- From: Joel Weinberger <jww@chromium.org>
- Date: Tue, 06 Sep 2016 22:25:26 +0000
- To: chloe <chloe@chloe.re>, public-webappsec@w3.org, dev.akhawe@gmail.com
- Message-ID: <CAHQV2KnZvmEnf-SeTU8zOQAOvtaE_dHLMCQQx7XWZu9a48tZ1A@mail.gmail.com>
Hi, and thanks for the comments! Your graph *should* be incorrect, although it's always possible we're getting something wrong. The SOP should be applied symmetrically to execution contexts that have a Suborigin and those that don't, so the green arrows should be red in your example. If you think there's a specific bug in the spec so far, we'd love to hear more about it. It would be great if you can file a bug at https://github.com/w3c/webappsec-suborigins. --Joel On Wed, Aug 31, 2016 at 5:35 AM chloe <chloe@chloe.re> wrote: > As stated in the ED [0], suborigins are another way of constructing > origins. I think the draft fails to clarify the complete relationship. > > As an example: if XSS is found on example.com without any suborigin > namespace, will an attacker have the possibility to execute Javascript > within a suborigin namespace, for instance /foo/ that sends the response > header 'suborigin: foo'? > > I drew a simple SOP relationship chart and hopefully that clarifies how > I think the relationship works. This image is attached. Red arrows means > that SOP is denying access. Please correct me if I'm wrong. > > Thanks. > > [0] https://w3c.github.io/webappsec-suborigins/#suborigins-vs-origins >
Received on Tuesday, 6 September 2016 22:26:05 UTC