DPoP & resource leaks

[Joseph Heenan]

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.

[Joseph Heenan]

As per my point on the call today & further discussion:

1. This is not just replaying a request - DPoP only signs the URL, so potentially the attacker can make requests with different HTTP headers or a different body for POST/PUT requests.
2. The DPoP nonce by itself does not solve the replay issue, the nonce would need to be changed by the RS on every request - whereas DPoP allows nonces to remain valid for, say, minutes. (Cycling nonces this fast could be problematic, e.g. it would prevent pipelined http requests working properly.)
3. The attacker model may be too strong.

‌

[Daniel Fett]

I think we need to accept the risk and document the attack. This is trade-off inherent to DPoP, after all.

[Pieter Kasselman]

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.

[Pieter Kasselman]

@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.

[Joseph Heenan]

@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.]

[Pieter Kasselman]

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.

[Joseph Heenan]

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.

[Brian Campbell]

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 of jti 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.

‌

[Pieter Kasselman]

I think both jti and nonce would mitigate, so providing the guidance for implementors who are concerned with this attack seems prudent.

[Brian Campbell]

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 from iat or nonce and that dictates how long the jti needs to be retained. But trying to factor nonce into this any more than that is problematic.

‌

[Joseph Heenan]

PR here: https://bitbucket.org/openid/fapi/pull-requests/365

[Dave Tonge]

PR merged