> On 18 Feb 2021, at 12:25, Philippe De Ryck > <phili...@pragmaticwebsecurity.com> wrote: > >> On 18 Feb 2021, at 13:08, Neil Madden <neil.mad...@forgerock.com> wrote: >> >> Thanks for following up, Brian. Responses below. >> >>> On 17 Feb 2021, at 22:48, Brian Campbell <bcampb...@pingidentity.com> wrote: >>> >>> Always appreciate (and often learn from) your insights, Neil. I'd like to >>> dig into the CSRF thing a bit more though to understand better and >>> hopefully do the right thing in the draft. >>> >>> It seems to me that a GET at the bff-token endpoint is "safe" in that it's >>> effectively just a read. >> >> Well it’s a read that returns an access token. It’s “safe” in the sense of >> side-effects, but we absolutely want to preserve the confidentiality of what >> is returned and only allow it to be accessed by authorized clients (the >> legitimate frontend). At the moment the only thing keeping that safe is the >> JSON content type. For example, imagine a world in which the token-bff >> endpoint instead returned the access token as HTML: >> >> <div id=“accessToken”>abcd</div> >> >> Then as an attacker I can simply embed an iframe on my site that refers to >> your bff-endpoint and then parse the access token out of the DOM. The >> browser will happily load that iframe and send along the cookie when it >> makes the request. > > You are overlooking basic browser security measures like the Same-Origin > Policy here. The browser will only allow access to an iframe if it has the > same origin as the context accessing the frame. If an attacker embeds this > frame in their site, it will be a cross-origin frame, and access will be > denied.
Right, HTML was a bad example. But again remember that at this point the content is already loaded into the renderer process and so vulnerable to Spectre and other side-channel attacks. As MDN says (https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy): “To prevent cross-origin reads of a resource, ensure that it is not embeddable. It is often necessary to prevent embedding because embedding a resource always leaks some information about it.” My point is that the server is performing essentially no real security checks and relying on the user-agent for pretty much all security guarantees. This is ok when those mechanisms are robust, but they really aren’t in the case of embeddable resources and browser vendors are still trying to close all the holes. > > FYI, simple CORS requests follow the same security pattern (when headers are > missing, browsers do not expose the response). But many sites already return those CORS headers to enable cross-origin functionality. On those sites bff-token is completely insecure because cross-origin clients can now use that access to get an access token intended for the first-party SPA and use it to access other APIs! I can’t emphasise enough how much of a security disaster this could be. > Preflighted CORS requests cover "new features" (i.e., stuff you traditionally > could not do with HTML elements) and ask permission before sending a request. But GET requests don’t trigger preflight unless they have custom headers. > Also, if you're worried about framing, it's much simpler to require the token > endpoint to send "X-Frame-Options: DENY" and "Content-Security-Policy: > frame-ancestors 'none'" response headers. This denies framing altogether > without going into complicated CORS territory. You’re pretty much entirely missing the point of my message if you think it’s about framing specifically. Think of all the possible ways there are to embed cross-origin resources: CSS stylesheets, script embedding, images, video, audio, fonts, WebGL textures, objects, etc. If a new endpoint requires setting 15 new CSP policies just to make it not obviously insecure, it’s maybe a clue that it’s not a sensible design. To say that we’re not comfortable with tokens in localStorage but to then expose a simple GET endpoint for retrieving access tokens is IMO not a good idea. The SOP protections applied to localStorage are *far* more robust than those applied to GET requests. — Neil -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
