Hi Niv,
thank you for posting this to the list. I think you are right with your
threat description. One question: shouldn't the browser already prevent
the request to the authorization endpoint because of the same origin
policy (or CORS restrictions)?
Apart from that, a similar attack can be performed by a native
applicication (using an embedded browser). This kind of attack could not
be prevented using HTTP features but by enforcing a real user
interaction (password input, CAPTCHA).
regards,
Torsten.
Am 25.07.2011 18:27, schrieb Niv Steingarten:
Forwarded as per Eran's request.
A couple of corrections to my original email:
1. By AJAX, I mean, AJAX like techniques (if the user agent does not
enforce same origin policy).
2. When saying POST to '/authorize_callback' -- it may well be GET, if
the authorization server mishandles the request.
Thank you,
Niv
---------- Forwarded message ----------
From: *Eran Hammer-Lahav* <[email protected]
<mailto:[email protected]>>
Date: Tue, Jul 26, 2011 at 01:21
Subject: RE: Several typos in -20 and a possible security consideration
To: Niv Steingarten <[email protected] <mailto:[email protected]>>
Please forward this message to the oauth list at [email protected]
<mailto:[email protected]>.
Thanks,
EHL
*From:*Niv Steingarten [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Monday, July 25, 2011 2:52 PM
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Several typos in -20 and a possible security consideration
Hello,
I've noticed a couple of typos in -20:
Section 6 (page 41): Under 'The authorization server MUST', the second
bullet should end with the word "and", and the third bullet should end
with a full-stop.
Section 10.2 (first paragraph): "...keep is client credentials
confidential" should be "...keep *its* client credentials confidential".
Regarding the security consideration --
I might be missing something, but I saw there are references to
clickjacking and to client impersonation, but I haven't seen any
reference to possible resource owner impersonation.
For example, in the implicit grant flow, a malicious client could send
a request to the authorization endpoint via, say, AJAX, and receive
the markup of the page asking the resource owner to authorize the
client (assuming the resource owner is signed in and no resource owner
authentication is required). Then, in a poorly designed authorization
endpoint, the 'Allow' button might be the submission button of a form
whose target is '/authorize_callback' on the authz server. Then, it
may possible for the malicious client to simply POST to
'/authorize_callback' and authorize itself without any resource owner
intervention or knowledge that the process has even taken place. This,
of course, can be mitigated in most modern browsers if the
authorization server verifies the source of the request using the HTTP
referrer header.
Thanks for your time and for the fantastic work on OAuth,
--
*Niv Steingarten*
T:+972-54-5828088
E: [email protected] <mailto:[email protected]>
W:http://nivstein.com
--
*Niv Steingarten*
*
*
T:+972-54-5828088
E: [email protected] <mailto:[email protected]>
W:http://nivstein.com
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
