Thanks Justin for bringing this to our attention. Right now, I don't think that this is a big problem and I wasn't able to come up with a way to improve the attack. I hope that it doesn't come back to haunt us when somebody does a more in-depth analysis...
That said, the lack of binding to the access token makes it easier to precompute proofs if somebody has a limited code execution opportunity in the client. We have this paragraph in the spec: Malicious XSS code executed in the context of the browser-based client application is also in a position to create DPoP proofs with timestamp values in the future and exfiltrate them in conjunction with a token. These stolen artifacts can later be used together independent of the client application to access protected resources. The impact of such precomputed DPoP proofs can be limited somewhat by a browser-based client generating and using a new DPoP key for each new authorization code grant. The recommendation could be to use a fresh key pair for each token request. -Daniel Am 20.11.20 um 20:26 schrieb Justin Richer: > While working on an implementation of DPoP recently, I realized that the > value of the access token itself is not covered by the DPoP signature at all. > What I’m wondering is whether or not this constitutes an attack surface that > we care about here. Here’s how it works: > > > Let’s say that a client creates a DPoP key and uses that key to request two > tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is > malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s > token value, T2, through some means. Normally DPoP wouldn’t let Alice create > a new request using T2 since Alice doesn’t have the client’s key. However, if > Alice gets the client to create a request for her using T1, she can copy the > signature from that request onto a new request using T2. Since the signature > doesn’t cover the token value and the key is the same, the RS should accept > both requests, right? > > An important aspect is that the parts needed to make this attack work are a > little weird: you’d need access to a valid signed request from the client > with T1 as well as access to a valid T2 attached to the same key in order to > make this substitution. However, this is effectively the same attack area > that bearer tokens have in a lot of ways, since it doesn’t require the > attacker gaining access to the singing key to generate or modify a signature, > nor does it require the attacker to generate or modify an access token > (merely obtain one). > > > I’d like to understand if this is an actual attack against DPoP. If it isn’t, > how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? > I didn’t see a mention of it there. If it’s not, should we discuss it there? > > > The old OAuth PoP draft mitigates this attack by putting the access token > itself inside the signature body instead of a second header. Another option > would be to include a hash of the token value (such as OIDC’s “at_hash” > method used in ID Tokens) in the DPoP payload. With either of these > approaches, Alice having access to T1, T2, and a signed message for T1 does > not allow her to use T2 effectively. > > — Justin > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
