PKCE Chosen Challenge Attacks

[tlodderstedt]

Attacker chooses PKCE verifier and obtains code through leakage (referrer etc)

1. attacker impersonates legit client (works for public clients only)
2. attacker abuses legit client (e.g. payment initiation issue)

options:

• invalidate code after exchange attempt with wrong PKCE verifier (similar to RT rotation and replay detection)
• requires cooperation of "client under attack"
• requires AS to enforce PKCE challenge for every authorization request (!)

[tlodderstedt]

basiert auf FAPI-Analyse der Uni Stuttgart - wird beim OSW noch mal diskutiert werden

[danielfett]

This can also be used against a confidential client and when JAR/JARM are used. There is currently no good defense if attacker A3 is active...

[danielfett]

See also: https://plantuml.server.d3f.me/uml/dPBTIiCm5CUlpLCSTxL1otfTh52A5sEYfMLNJaP8ZsjiIKgI8VC9V0JlV4KVmQHBn-f0OJSv9-JyVpbVXfiMoLM-pEuWgwL6OGrjMnHRXAxTQKXtfePCLWWByOhCS2aWDOQo1jwuVM8jHs60sZ1hEQCkWg2emFHioenKCFd--lpmEbGJeFfuyH4hZGf8HvLby8vQP96Fhcb9oA21yDO-nw2D3I15FjoPGceGX1GCGKV1MdY_wtsDMhlydOsyR436eB3YodupTxK4ZcqmiH3e6eORnf9wsaMpm5UyuLN2ehLuogHiECO7wFCeHLVJPLpIjyEbLyONIM_2qAkTLFI0ToYPx52xxhiWafR35xvn5gBsC7K_36JhCZjzQwYnXzC5dZFpWDCoYtpUEwV9EdtIGuvbkM7z4ogaJKZnRMr0llI21mdbOOBNf49jbDox9Jammz4i-tLR5GkuHzh4CA2ZimtwEudpyVvUciSbJ4Sz-G40

[tlodderstedt]

The sequence diagram is very helpful! How is the code supposed to leak?

[danielfett]

See Attacker model A3: (A3) Attackers that can read, but not modify, the contents of the authorization response (i.e., the authorization response can leak to an attacker). Examples for such attacks include open redirector attacks, problems existing on mobile operating systems (where different apps can register themselves on the same URI), so-called mix-up attacks, where the client is tricked into sending credentials to a attacker-controlled AS, and the fact that URLs are often stored/logged by browsers (history), proxy servers, and operating systems.

[tlodderstedt]

Essentially you are saying client and do not fully implement the recommendations given in the BCP (redirect matching, AS binding, ...), right?

What options for detection do we have? just the failed attempt to exchange the code?

[danielfett]

Something like that, or a leak on a proxy or in a mobile OS.

Only good detection option I can come up with: The AS needs to decline Authz-Requests if they do not come from one of the clients URLs (by opportunistically checking Origin or Referer headers). This would, however, be a completely new concept. It would be similar to redirect URIs, including registering etc. Alternative: Token Binding in the browser or something with PostMessage communication.

[tlodderstedt]

I think refer headers are not a bad choice. Assuming the attacker does not control the victims device, they may at least function as a good hint that something is going wrong.