Hi Guido, Am 08.10.20 um 14:17 schrieb Guido Schmitz: > We just had a discussion in Stuttgart on the possibility of > misconfigured endpoints, i.e., an honest client uses the wrong endpoints > for interacting with some honest AS. Such a setting might be the outcome > of a social engineering attack against the administrators of a client > (e.g., the attacker disguises as an AS support agent and convinces the > client admin that some endpoint needs to be changed). If some endpoint > is configured to a URL controlled by some adversary, critical data can > leak and the attacker can even tamper with the requests to this endpoint. > > Is this a realistic attack scenario? Does anybody have more insight or > data on this problem? (I think that such a scenario had been mentioned > at some OSW discussion.)
This scenario is also explicitly mentioned in FAPI 1.0: https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md#markdown-header-832-client-credential-and-authorization-code-phishing-at-token-endpoint > A potential mitigation against this problem could be the usage of AS > metadata discovery (RFC8414). In this case, the client only needs to set > the "issuer" to configure the endpoint URLs. A social engineering attack > to change the issuer might be less likely as a social engineering attack > to change some endpoint URLs (which a client admin might have less > understanding of). Further, using AS metadata discovery also reduces the I find it plausible that having the issuer as the single entry point makes misconfigurations less likely. One disadvantage could be that an attacker might use a bening-looking issuer URL to "hide" the fact that he uses an honest server's authorization endpoint but an attacker-controlled token endpoint. Such attacks, however, need to be caught by mix-up mitigations anyway (see https://danielfett.de/2020/05/04/mix-up-revisited/). A positive side-effect of a more widespread use of RFC8414 could be that it becomes easier to configure OAuth and new(ish) features such as PKCE and PAR could be enabled/relied-upon by clients more easily. > risk of misconfiguration at the client in general. Maybe it is a good > idea to add a recommendation for the usage of RFC8414 in the security > BCP. What do you think? Publishing RFC8414 metadata is (almost) mandatory already, since servers MUST declare their support of PKCE (but they can also use deployment-specific ways to accomplish this). I would support adding - that servers SHOULD publish RFC8414 metadata and - that clients SHOULD make use RFC8414 discovery. -Daniel -- https://danielfett.de
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
