> On 6 Nov 2020, at 22:02, Brian Campbell <bcampb...@pingidentity.com> wrote: > > > > >> On Tue, May 5, 2020 at 2:52 PM Brian Campbell <bcampb...@pingidentity.com> >> wrote: >> >>> >>> 9.1: >>> This would be a good place to mention BREACH as an example of how a DPoP >>> proof (and AT) might leak, despite only being sent over a direct HTTPS >>> channel. Note though that adding a random jti is an effective defence >>> against this even if the server doesn’t check it. >> >> Thanks for that note as a good reason to keep jti even if the requirements >> on checking it are relaxed. > > In trying to add some text that makes such mention I realized (again) that I > don't have a very good understanding of BREACH. With a bit of reading of the > overview and paper at http://breachattack.com/ it seems that BREACH is > applicable to attacking compression for leaking sensitive information in HTTP > responses. Whereas a DPoP proof is only defined to be sent in an HTTP > request. And ATs are only in a response once and then used in requests. > Perhaps it's a limitation of my own imagination or intellect but I don't see > how BREACH is relevant here. If you can explain it to me "for dummies" style > or better yet propose some text, we can certainly look at adding it. Short of > that though, I'm not equipped to write anything legitimate about it and will > just omit any such mention. >
BREACH was primarily attacking web browser clients, which do indeed usually only allow compression in responses. But OAuth is used for other API clients and compression of requests, although by no means widespread, is sometimes used. For example [1] where it’s recommended that clients use compression for both requests and responses, and a Google search shows various other cases. So in these cases a BREACH-like attack could be used to recover a bearer token in those requests. However, on reflection it’s not a hugely likely attack vector for a number of reasons: 1. HTTP compression only compresses the request entity, not the headers or request URI. So this would only be a risk when sending the access token in the body as in [2]. And it’s not a risk for a DPoP proof as that’s always in a header. 2. In order for the attack to work the attacker needs to be able to influence some part of the requests, which is generally a bit harder than influencing responses from a server. The most likely vector IMO would be XSS, in which case there are likely to be more direct ways to steal the token. I wouldn’t want to say that this is never a risk, but it perhaps doesn’t rise to the level that it’s worth spelling out. [1]: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest_compression.htm [2]: https://tools.ietf.org/html/rfc6750#section-2.2 — Neil -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
