- edited description
OAuth Profile should mandate RFC7636 (PKCE) for code flow
There is going to be a demonstration of Browser TLS intercept at Blackhat today. (WPAD Attack).
There is a news article as well: New attack bypasses HTTPS protection on Macs, Windows, and Linux
We knew of the possibility but not it has become the reality.
Given the situation, mandating RFC7636 for all the Clients (including confidential clients) for code flow seems prudent.
Comments (14)
-
reporter -
reporter - changed status to open
Now it is mandated.
We should make note of the relationship between PKCE and WPAD somewhere (not in the spec itself.)
-
reporter - changed component to Part 1: RO Security
-
reporter PKCE or Hybrid Flow is mandated in Part 1. This is to avoid the
code
injection attack. The explanation of the attack is as follows.Environment
- RFC6749 code grant with a confidential client (e.g. web server client)
- The victim's front channel communication is somehow compromised (e.g., through WPAD attack, server log, etc.)
- The client is implementing RFC6749 properly with XSRF protection etc.
Attack Scenario
- The victim and the attacker are using the same web client.
- The attacker gets the victim's
code
somehow, e.g., WPAD attack. - The attacker inserts the
code
into the session he started. - The client sends the
code
with its client secret to the token endpoint. - The token endpoint verifies the client secret and that the code was issued to the client.
- The token endpoint sends the access token back to the client.
- The client accesses the victim's protected resource successfully and returns it to the attacker. SUCCESS.
Mitigation
Use PKCE with S256. By doing so, the above scenario changes to:
- The victim and the attacker are using the same web client.
- The attacker gets the victim's
code
somehow, e.g., WPAD attack. - The attacker inserts the
code
into the session he started. - The client sends the
code
with its client secret and the code verifier to the token endpoint. - The token endpoint verifies the client secret and that the code was issued to the client. 5a. The token endpoint verifies the code verifier matches the one tied to the code. This fails.
- The token endpoint sends the error back to the client.
- The attack FAILED.
-
Kudo san at Authlete asked me about this ticket and how it was resolved in part 1.
I looked and can't figure out how it was resolved - part 1 does not seem to require PKCE for confidential clients, it doesn't require hybrid flow, and I can't spot any other mitigation in part1. Did we lose the fix in one of the other edits?
-
- edited description
- changed status to open
Reopening to make sure we've addressed/do address it.
-
This was discussed on today's call - it was felt that we should mitigate against this attack by requiring PKCE for confidential clients in part 1, but this should be done in such a way that it doesn't mean it's required in part 2.
-
I've created a pull request here: https://bitbucket.org/openid/fapi/pull-requests/56/require-pkce-for-confidential-clients
One point I wasn't 100% sure on - should part2 public clients use PKCE or not?
-
reporter - changed status to closed
Require PKCE for part 1 confidential clients
This should mitigate some potential attacks against the code flow in confidential clients as discussed in
#11. PKCE is already required for public clients.Update part 2 so that confidential clients don't inherit this requirement, as part2 confidential clients should already be immune to the potential attacks due to the use of hybrid flow / signed request objects / token binding.
I think we did previously require PKCE for confidential clients and this was accidentally removed as part of commit 8d420fd67b79a1b72c29fac4ea38e6db2b0ff61d
closes
#11→ <<cset 125197d3171c>>
-
reporter - changed component to Part 1: Baseline
-
reporter - changed component to FAPI 1 - Part 1: Baseline
-
reporter - changed component to FAPI 1 – Part 1: Baseline
-
reporter - changed component to FAPI 1 – Baseline
-
reporter - changed component to FAPI 1: Baseline
- Log in to comment