Re: [OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13

[Daniel Fett <[e-mail]>]

Hi Guido,

thanks for the feedback! I incorporated most of it into the next version.

Some comments:


Am 22.11.19 um 18:00 schrieb Guido Schmitz:
> * Section 3.1, Third Paragraph, Section 4.7, and other places throughout
> the document: (Please excuse that the following might be a bit
> nitpicking.) The term CSRF might be misleading as we are not talking
> about "classical" CSRF, where a party is tricked into (implicitly)
> believing that a request was caused by its own origin (from a web
> browser), but was actually sent cross-origin. Here, we are talking about
> requests which (by protocol) are typically intended to be cross-origin.
> The point here is not that the request is cross-origin, but that it
> originates from an unintended (cross-)origin. Maybe you could mention
> that we are talking about an advanced kind of CSRF in the
> double-redirection context.
Good catch, I added a reference to RFC6819, where this kind of CSRF is
explained in more detail.
>
> * Section 3.1.2: What about SPAs? Either they use authorization code
> grant with the help of some server or use CORS to access the token
> endpoint. The token endpoint, however, then needs to support CORS. The
> obvious question is then, what is the CORS policy of the token endpoint?
> It is probably fine to allow all origins (if this policy only applies to
> the token ep itself and not other eps at the same origin) or do I miss
> something?
This policy should be fine. But this is a topic for the SPA BCP.
> * Section 4.1.3, "fix fragments": The source [fb_fragments] only says
> that Facebook adds the fragment #_=_ to some URLs. There is no
> explanation or reasoning in the source (as well as in this document) at
> all that this technique strips the fragment from redirects. (Mike Jones
> also commented on this.)
Thanks, I removed the reference completely and added some explanation
instead.
> * Section 4.2.4, Bullet Point "referrer header": Adding the
> rel="noreferrer" attribute to links does not protect against leakage via
> third-party content. Referrer Policy is the only effective
> countermeasure of the mentioned two as it can be used to completely
> suppress the Referer header or at least strip it to the origin. Should
> we give a concrete example for Referrer Policies? For example, the
> header "Referrer-Policy: no-referrer" in the response completely
> suppresses the Referer header in all requests originating from the
> resulting document.  Also, this measure is easier to implement than
> adding rel="noreferrer" to each link. (BTW, there is also an excess
> quotation mark in this paragraph.)
You're right, Referrer Policies are the way to go. I added your example.
> * Section 4.5.3, "Code-bound State": This requires that state is fresh
> for each flow. You should mention or even emphasize this.
>
> * Section 4.5.3, "Per-instance client id/secret": This essentially says
> that native apps or anything that might be able to obtain and store
> client id/secret (e.g., using dynamic registration) could do this. Web
> SPAs could do this as well (e.g., using Web Storage). The last sentence
> of this paragraph is somehow confusing.
I propose to remove these two points from the bullet point list
completely. They are more of an academic discussion for a problem that
is already solved by PKCE at this point. Any objections?
> * Section 4.5.3, Second Paragraph after bullet points, "Note on
> pre-warmed secrets": What is the context of this note? Does the attacker
> start a flow on some device, extract secrets, and then pass this device
> to the victim who then completes the OAuth flow? (Mike Jones also
> remarked that "pre-warmed secrets" is not explained)

That is essentially a pointer in the general direction of the PKCE
Chosen Challenge attack. I agree that it needs a better wording.

-Daniel