Am 21.11.18 um 11:01 schrieb Neil Madden: >> On 21 Nov 2018, at 09:25, Daniel Fett <[email protected]> wrote: >> >> Am 21.11.18 um 10:09 schrieb Neil Madden: >>>> If a page from origin A includes a third-party script from origin B, that >>>> external script runs in origin A and has access to all cookies and the >>>> JavaScript context of the page. >>>> >>>> The SPA from origin A would be compromised. That is why we need things >>>> such as Subresource Integrity. >>>> >>> I think we’re talking about different things. I am talking about scripts >>> from places like ad servers that are usually included via an iframe to >>> enforce the SOP and sandbox them from other scripts. If they get access to >>> an access token - e.g. via document.referrer or a redirect or some other >>> leak, then they still act within the same TLS context as the legitimate >>> client. >> Thanks for the clarification! I see that you highlight an important point >> there. >> >> The protection that would be required essentially boils down to something >> similar to a CSRF protection for the resource server. >> >> Luckily, CORS covers this: You can't set the Authorization header >> cross-origin unless the appropriate CORS headers are set. So while the third >> party origin would be able to send a request through the browser using the >> TLS context, it would not be able to attach the access token. (Unless, of >> course, that third party origin is whitelisted, or if the bearer token is >> sent in a different way, e.g., as a URL parameter.) > Right. But two points here: > > Firstly, this assumes the access token is actually passed in an Authorization > header and not just sent in a URL parameter or a CORS-safe form POST body > (e.g. application/x-www-form-urlencoded). This should probably be its own > security best practice recommendation, but I haven’t seen it anywhere. I > think most REST APIs already do this following RFC 6750, but we should spell > out that it has security benefits.
Exactly what I thought. I will prepare a proposal for the security BCP. -Daniel
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
