Eric,
I'm confused. I didn't talk about an attacker impersonating Rob. At any rate,
inasmuch as we are back to square one, I would maintain that receipt of an
authorization code by the client alone is not sufficient for causing it to
issue an access token request to the authorization server. The client has to
have the right context and be in the right state for that to happen. I should
say that it is valid to address DDoS attacks. At issue is only the plausibility
of the chain reaction suggested.
Best regards,
Huilan
________________________________
From: [email protected] [mailto:[email protected]]
Sent: Friday, March 04, 2011 1:23 AM
To: Lu, Hui-Lan (Huilan)
Cc: [email protected]; Torsten Lodderstedt; [email protected]
Subject: Re: [OAUTH-WG] validate authorization code in draft 12
Hi Huilan,
The vulnerability being mentioned here is not that an attacker
impersonates Rob. Please refer to the original discussion below:
"The issue is that according to the current draft, someone who owns a
botnet can locate the redirect URIs of clients that listen on HTTP, and access
them with random authorization codes, and cause HTTPS connections to be made on
the Authorization Server (AS). There are a few things that the attacker can
achieve with this OAuth flow that he cannot easily achieve otherwise : ..."
The point 3. about the state parameter/CSRF defense is that they can
have the beneficial effect of making the above attack more difficult, but does
not prevent it.
Best regards,
Eric
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
