DPoP & resource leaks
As per FAPI2 security analysis & Daniel’s presentation to the WG today:
We need to decide whether to mitigate this attack, weaken the attacker model, or simply document it and the possible mitigations.
Comments (15)
-
reporter -
reporter - edited description
-
I think we need to accept the risk and document the attack. This is trade-off inherent to DPoP, after all.
-
The risk can be mitigated by DPoP. If we leave the decision to mitigate this risk to the system owner, the text should highlight the risk, explain that the server supplied nonce in DPoP mitigates against this risk, provided that a new nonce is used every time the access token is presented. DPoP includes a form of nonce “pre-fetching” that cuts down on roundtrips (a new nonce is included in the HTTP 200 response - see section 8.1 of DPoP for details: draft-ietf-oauth-dpop-10). Although this “pre-fetching” does reduce the number of roundtrips, nonces may also have a limited lifespan to reduce complexity of keeping track of nonces on the AS, which depending on usage patterns, may result in additional roundtrips (part of the self-correcting nature of the nonce mechanism as described in section 8 draft-ietf-oauth-dpop-10, The system owners should decide how long nonces should live for and balance that against the risk they are mitigating.
-
@Joseph Heenan can you think of practical examples an attacker might come up with by using different HTTP headers or a different body for a POST/PUT request? Including a practical example may be informative for the system owner making decisions about risk trade-offs.
-
reporter @pieter One example would be an access token authorised to make payments from a bank account. If the payment amount and destination account are part of the POST body to the “make a payment” endpoint, then the attacker that obtains a genuine payment request can replay the dpop proof/access token to the same endpoint, allowing the attacker to potentially transfer the user’s funds to the attacker’s bank account.
[I’m not aware of ecosystems were this attack would actually be practical today as I believe most OpenBanking payment APIs require an explicit consent from the user for, at a minimum, each unique destination account, and they also require a signed request to the resource endpoint. But hopefully it serves as an example. And makes clear we should mention httpsig as a mitigation for that part.]
-
Thanks @Joseph Heenan - the example is usefull to demonstrate the problme but we should probably pick something that is not already mitigated in other ways to prevent readers from dismissing the threat (or perhaps the point of th example is that it is more theoretical and is mitigated elsewhere?).
Requiring/recommending htmlsig on top of dpop feels like a lot of complexity (one more key, one more signature). DPoP does allow for additional fields to be included in the DPoP proof (see section 4.2 draft-ietf-oauth-dpop-10), although adding that would add another bit of complexity on its own.
-
reporter I think another example would be helpful, but I may need a bit of help to come up with the best example. I can see one where the attacker is able to replace the contents of a file on a shared dropbox/sharepoint/onedrive/gdrive/etc folder the user has recently written to, but I’m not sure that quite gets the potential impact across.
-
If I understand the attack/attacker model correctly (which isn’t assured), I believe that strict
jti
tracking and rejection of previously seen proofs would mitigate this (see sections 4.2 and 11.1). Use ofjti
to prevent multiple uses of the same DPoP proof has been de-emphasized somewhat in recent drafts (-08 I think) due largely to performance/scalability concerns. So it’s effectively optional but is still something at the resource's disposal to mitigate this. There are trade-offs so probably documenting/describing it along with attack is likely preferable to requiring it. But I think that could be sufficient.
-
I think both jti and nonce would mitigate, so providing the guidance for implementors who are concerned with this attack seems prudent.
-
As Joseph pointed out, nonce by itself does not solve the issue. Tracking
jti
to prevent multiple uses addresses it. The time window that a DPoP proof JWT would be accepted is determined fromiat
ornonce
and that dictates how long thejti
needs to be retained. But trying to factornonce
into this any more than that is problematic.
-
reporter -
reporter -
assigned issue to
-
assigned issue to
-
- changed status to resolved
PR merged
-
- changed component to FAPI2: Security Profile
- Log in to comment
As per my point on the call today & further discussion: