On 21 Nov 2018, at 08:39, Daniel Fett <danielf+oa...@yes.com> wrote: > > Am 21.11.18 um 09:34 schrieb Neil Madden: >> On 21 Nov 2018, at 08:26, Daniel Fett <danielf+oa...@yes.com> wrote: >> >>> Am 20.11.18 um 13:24 schrieb Neil Madden: >>>> If we are discussing this in the context of client-side web apps/SPAs, >>>> then surely the threat model includes malicious 3rd party scripts - for >>>> which neither token binding nor mTLS constrained tokens are very effective >>>> as those scripts run in the same TLS context as the legitimate client? >>>> >>> Please correct me if I'm wrong, but if a page/SPA/origin includes a >>> malicious third party script, the third party script can access all data of >>> that JavaScript. It can exfiltrate tokens and/or send requests on behalf of >>> that page/SPA/origin (using the page/SPA/origin's TLS context, cookies, >>> etc.). >>> >>> So I doubt that there is any better solution than token binding or mTLS. >>> >>> If we assume that an SPA includes a malicious third party script, it is >>> completely compromised. >>> >> >> No - same origin policy prevents those things. TLS doesn’t have those >> protections though because it acts at the transport layer and SOP is an >> application-layer concept. > 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. — Neil _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
