<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>You may just refer to <a href="https://tools.ietf.org/html/draft-ietf-oauth-security-topics-01">https://tools.ietf.org/html/draft-ietf-oauth-security-topics-01</a>, in particular section 3.1</div><div><br>Am 26.08.2017 um 10:14 schrieb Nat Sakimura <<a href="mailto:nat@sakimura.org">nat@sakimura.org</a>>:<br><br></div><blockquote type="cite"><div><span>Thanks, Torsten.</span><br><span></span><br><span>Right. So an attack scenario I guess is a privilege escalation using code injection.</span><br><span></span><br><span>Environment</span><br><span>-------------</span><br><span>- RFC6749 code grant with a confidential client (e.g. web server client)</span><br><span>- The victim's front channel communication is somehow compromised (e.g., through WPAD attack, server log, etc.)</span><br><span>- The client is implementing RFC6749 properly with XSRF protection etc.</span><br><span></span><br><span>Attack Scenario</span><br><span>-----------------</span><br><span>1. The victim and the attacker are using the same web client.</span><br><span>2. The attacker gets the victim's `code` somehow, e.g., WPAD attack.</span><br><span>3. The attacker inserts the `code` into the session he started.</span><br><span>4. The client sends the `code` with its client secret to the token endpoint.</span><br><span>5. The token endpoint verifies the client secret and that the code was issued to the client.</span><br><span>6. The token endpoint sends the access token back to the client.</span><br><span>7. The client accesses the victim's protected resource successfully and returns it to the attacker. SUCCESS.</span><br><span></span><br><span></span><br><span>Mitigation</span><br><span>-----------</span><br><span>Use PKCE with S256. By doing so, the above scenario changes to:</span><br><span></span><br><span>1. The victim and the attacker are using the same web client.</span><br><span>2. The attacker gets the victim's `code` somehow, e.g., WPAD attack.</span><br><span>3. The attacker inserts the `code` into the session he started.</span><br><span>4. The client sends the `code` with its client secret and the code verifier to the token endpoint.</span><br><span>5. The token endpoint verifies the client secret and that the code was issued to the client.</span><br><span>5a. The token endpoint verifies the code verifier matches the one tied to the code. This fails.</span><br><span>6. The token endpoint sends the error back to the client.</span><br><span>7. The attack FAILED.</span><br><span></span><br><span>I will add the above explanation to the ticket #11. The ticket itself was saying that we should document it, which we did not :-(</span><br><span></span><br><span></span><br><span>For Read&Write, we are mandating hybrid flow. However, for the Read only, we are not.</span><br><span>Thus, for the Read Only (Part 1), we should still mandate the use of PKCE.</span><br><span></span><br><span>That's why it is saying</span><br><span></span><br><span>* shall support [RFC7636] or the mechanisms defined in Financial API - Part 2;</span><br><span></span><br><span></span><br><span>---</span><br><span>Nat Sakimura</span><br><span>Research Fellow, Nomura Research Institute</span><br><span>Chairman of the Board, OpenID Foundation</span><br><span></span><br><span>On 2017-08-25 18:15, Torsten Lodderstedt wrote:</span><br><blockquote type="cite"><span>Hi Nat,</span><br></blockquote><blockquote type="cite"><span>just guessing - the new OAuth security BCP recommends use of PKCE for</span><br></blockquote><blockquote type="cite"><span>detecting/preventing code injection attacks. That might be the reason</span><br></blockquote><blockquote type="cite"><span>for adding the requirement to the FAPI profile.</span><br></blockquote><blockquote type="cite"><span>I know the hybrid flow („code id_token“) is an alternative</span><br></blockquote><blockquote type="cite"><span>countermeasure in the OIDC space. So my question is: will FAPI allow</span><br></blockquote><blockquote type="cite"><span>use of pure authz code flow? Then recommending PKCE for code injection</span><br></blockquote><blockquote type="cite"><span>makes a lot of sense.</span><br></blockquote><blockquote type="cite"><span>best regards,</span><br></blockquote><blockquote type="cite"><span>Torsten.</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Am 24.08.2017 um 19:43 schrieb Nat Sakimura via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net">openid-specs-fapi@lists.openid.net</a>>:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hi.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Current text reads like it is requiring PKCE support even for the confidential client.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Do you remember the reason for it? Or is it just an editorial error?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>John may have mentioned a potential attack that PKCE could help but I do not quite remember the details....</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>If it is an error, then we should fix it for the final.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Best,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>--</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Nat Sakimura</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Research Fellow, Nomura Research Institute</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Chairman of the Board, OpenID Foundation</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Openid-specs-fapi mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.openid.net</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a></span><br></blockquote></blockquote></div></blockquote></body></html>