I’m going to respond inline and re-organize the previous message a bit.
> It's worth noting that it didn't get so much traction up to this time, and > that I stopped using it in multiple applications myself. That’s exactly what I meant with my statement of an “unproven approach”. If you, the creator of this pattern, are not even using it in a production application, I fail to see how this is a recommended best practice for securing frontends. After all, the goal of this document is defined as follows: This specification details the security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0 BFFs, on the other hand, are widely used in applications where security is a high priority (e.g., financial, healthcare). > Not because it's not a worthwhile pattern to solve the mentioned problem, but > because token leak is typically not the real issue. XSS is the first one to > solve, and I disagree it's unavoidable (and certainly at any level: extra > care for application start code can get you very far). It’s about more than XSS. Malicious JS ends up in applications through a variety of ways. In theory, you could argue that we know how to solve XSS or the issue of malicious JS. In practice, this is unfortunately absolutely false. Even if we just focus on XSS, where developers have full control over the code, I can easily argue that you cannot guarantee the absence of a vulnerability. For example, a well-established best practice for outputting data with benign HTML is running the unsafe data through an HTML sanitiser. A few years ago, both Google’s internal sanitiser and DOMPurify, a sanitiser built by the world’s best XSS experts, contained a bypass vulnerability (https://securityaffairs.com/83199/hacking/google-search-xss-flaw.html <https://securityaffairs.com/83199/hacking/google-search-xss-flaw.html> & https://portswigger.net/research/bypassing-dompurify-again-with-mutation-xss). In essence, this means that every project relying on these (which is a best practice) was potentially vulnerable to XSS. It remains true that you should aim to avoid having malicious JS in your app anyway, and do everything in your power to make this happen. However, the assumption in the spec is that malicious JS will happen, since plenty of countermeasures aim to reduce the impact of such an attack. > Regarding the demonstration in the video, I don't think it would compromise > my current implementation. > > The current draft says this in §6.4.2.1 <http://6.4.2.1/>: > * The application MUST register the Service Worker before running any code > interacting with the user. > > This adds an important constraint: an attacker would not only need to > compromise any part of the application, but should also make sure the very > first thing it does (registering the service worker) is also compromised, > which is much harder. > > Step by step, the code I saw would: > - open an iframe > - redirect to the authorization server > - get redirected to the registered redirect_uri (which is an additional > important constraint here) > - register the service worker to run immediately > ... which would stop the attack here, the main application not even seeing > the auth code and not being able to call the /token endpoint No, because running a silent flow in an iframe typically uses a web message response. In essence, the callback is not the redirect URI, but a minimal JS page that sends the code to the main application context using the web messaging mechanism. The message will have the origin of the authorization server as a sender. > BFFs are not a proven better level of protection. Session riding in case of > XSS is still the same. > > One such claim is about BFFs being more secure because they are backed by > unstealable session cookies. This view on threats is not the position that this working group has taken before. For example, for DPoP, there’s a detailed threat model that aims to counter a variety of attacks, except for session riding, which is explicitly considered out of scope (https://danielfett.de/2020/05/04/dpop-attacker-model/ <https://danielfett.de/2020/05/04/dpop-attacker-model/>). I am not saying (nor have I ever said) that a BFF is the holy grail that solves everything. If malicious JS code runs, you/the user are still in major trouble. However, with a BFF, that trouble can be reduced from unfettered abuse of access/refresh tokens to session riding (aka online XSS from DPoP). The fact that a BFF uses cookies helps to obtain these properties, but it is not the foundation of the security benefits. The main benefit is that the OAuth client application is a backend web application instead of a frontend web application. > They also have debatable points: you either need some third party or custom > software (with their own threat to security) Why do you think a BFF is third-party or commercial? Yes, you can find commercial implementations, but you can just as well find open source implementations. That said, building a BFF is pretty straightforward, as it contains no business logic. It would involve these three building blocks: Use cookie-based session management (either server-side or client-side) to keep track of tokens Use an OAuth client library to obtain tokens from the authorization server Use a server-side proxy component to proxy API calls An organisation building internal enterprise apps can easily build one re-usable BFF lib, that just needs a configuration file with OAuth client parameters and endpoint-to-API mappings. > , and in the current state of knowledge, they rather give a false sense of > security. How is that? While I don’t necessarily agree with the wording in the spec, the message seems pretty accurate to me: In this architecture, tokens are never sent to the front-end and are never accessible by any JavaScript code, so it fully protects against XSS attackers stealing tokens. However, an XSS attacker may still be able to make authenticated requests to the BFF Proxy which will in turn make requests to the resource server including the user's legitimate token. While the attacker is unable to extract and use the access token elsewhere, they could still effectively make authenticated requests to the resource server. And to give you a commercial example, the statement below is taken from the BFF page of Duende IdentityServer (https://docs.duendesoftware.com/identityserver/v6/bff/overview/): In Duende.BFF, tokens are only accessible server-side and sessions are managed using encrypted and signed HTTP-only cookies. This greatly simplifies the threat model and reduces risk. While content injection attacks are still possible, the BFF limits the attacker’s ability to abuse APIs by constraining access through a well-defined interface to the backend which eliminates the possibility of arbitrary API calls.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
