Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
I think this threat is similar to clickjacking (http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-10.13). Could we incorporate it into this section (w/o delaying the spec's release process)? regards, Torsten. Am 26.07.2011 19:29, schrieb Niv Steingarten: Would it be possible to consider adding this to the list of security considerations? Of course, the spec cannot cover all possible security threats, but this appears to be a realistic one which could easily be exploited if overlooked by developers (evident in the lack of scraping defense mechanisms in many applications). Is it too late to make such an amendment to the draft? Thank you, Niv On Tue, Jul 26, 2011 at 02:40, Niv Steingartennivst...@gmail.com wrote: Yes, I believe the vast majority of user-agents would block this kind of request if it originated from a JavaScript XMLHttpRequest or such. However, there are still scenarios in which a user-agent based client could manipulate this vulnerability. For example, the client could launch the GET request to the authorization server via animg HTML tag, taking the form of a CSRF. Since it's a blind attack, the client would likely not receive the contents of the web-page. However, this request is still necessary from the client since it has the side-effect of creating an access token (or other temporary token) on the authorization server. Since it is highly likely that a malicious client has a priori knowledge of the structure of the authorization page and form, it does not need the response in order to advance to the next step, and can simply send the fake request to 'Allow' itself to access the resource owner's resources. I believe this attack could be made very hard by either including a CAPTCHA, as you suggested, or including some kind of token or nonce in the submission of the form (which would still not prevent the attack if the authorization server doesn't enforce same origin policy). Niv On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt tors...@lodderstedt.net wrote: 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-Lahave...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingartennivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org. Thanks, EHL From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Monday, July 25, 2011 2:52 PM To: draft-ietf-oauth...@tools.ietf.org 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: nivst...@gmail.com W: http://nivstein.com
Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
I think it is intuitively similar to clickjacking, but the actual exploit methods and countermeasures are different (iframes vs. request spoofing, external browsers vs. nonce). It actually bears similarities to CSRF, only from the authorization server's point of view. I've taken the liberty to come up with a text (a mere proposal, of course, as I am no expert in writing technical specifications; feedback would be greatly appreciated.) I think it may be serious enough to justify its own section, but it may be possible to incorporate it into existing sections, as Torsten proposed, with some editing. - 10.X. Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests via the user-agent, and simulating the flow against the authorization server. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be easily simulated using a trusted user-agent. For example, the authorization server may use the HTTP referrer header to verify the source of requests associated with the authorization flow, or make use of a non-guessable nonce which is transmitted in the hypertext and is not accessible by the client. - The text above deals with the case of trusted user-agents (thus covering user-agent-based clients), as I don't know if anything can be done if a native client goes as far as using its own untrusted user-agent. Thank you, Niv On Fri, Jul 29, 2011 at 16:32, Torsten Lodderstedt tors...@lodderstedt.net wrote: I think this threat is similar to clickjacking (http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-10.13). Could we incorporate it into this section (w/o delaying the spec's release process)? regards, Torsten. Am 26.07.2011 19:29, schrieb Niv Steingarten: Would it be possible to consider adding this to the list of security considerations? Of course, the spec cannot cover all possible security threats, but this appears to be a realistic one which could easily be exploited if overlooked by developers (evident in the lack of scraping defense mechanisms in many applications). Is it too late to make such an amendment to the draft? Thank you, Niv On Tue, Jul 26, 2011 at 02:40, Niv Steingartennivst...@gmail.com wrote: Yes, I believe the vast majority of user-agents would block this kind of request if it originated from a JavaScript XMLHttpRequest or such. However, there are still scenarios in which a user-agent based client could manipulate this vulnerability. For example, the client could launch the GET request to the authorization server via animg HTML tag, taking the form of a CSRF. Since it's a blind attack, the client would likely not receive the contents of the web-page. However, this request is still necessary from the client since it has the side-effect of creating an access token (or other temporary token) on the authorization server. Since it is highly likely that a malicious client has a priori knowledge of the structure of the authorization page and form, it does not need the response in order to advance to the next step, and can simply send the fake request to 'Allow' itself to access the resource owner's resources. I believe this attack could be made very hard by either including a CAPTCHA, as you suggested, or including some kind of token or nonce in the submission of the form (which would still not prevent the attack if the authorization server doesn't enforce same origin policy). Niv On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt tors...@lodderstedt.net wrote: 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-Lahave...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21
Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
Would it be possible to consider adding this to the list of security considerations? Of course, the spec cannot cover all possible security threats, but this appears to be a realistic one which could easily be exploited if overlooked by developers (evident in the lack of scraping defense mechanisms in many applications). Is it too late to make such an amendment to the draft? Thank you, Niv On Tue, Jul 26, 2011 at 02:40, Niv Steingarten nivst...@gmail.com wrote: Yes, I believe the vast majority of user-agents would block this kind of request if it originated from a JavaScript XMLHttpRequest or such. However, there are still scenarios in which a user-agent based client could manipulate this vulnerability. For example, the client could launch the GET request to the authorization server via an img HTML tag, taking the form of a CSRF. Since it's a blind attack, the client would likely not receive the contents of the web-page. However, this request is still necessary from the client since it has the side-effect of creating an access token (or other temporary token) on the authorization server. Since it is highly likely that a malicious client has a priori knowledge of the structure of the authorization page and form, it does not need the response in order to advance to the next step, and can simply send the fake request to 'Allow' itself to access the resource owner's resources. I believe this attack could be made very hard by either including a CAPTCHA, as you suggested, or including some kind of token or nonce in the submission of the form (which would still not prevent the attack if the authorization server doesn't enforce same origin policy). Niv On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt tors...@lodderstedt.net wrote: 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 e...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingarten nivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org. Thanks, EHL From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Monday, July 25, 2011 2:52 PM To: draft-ietf-oauth...@tools.ietf.org 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: nivst...@gmail.com W: http://nivstein.com -- Niv Steingarten T: +972-54-5828088 E: nivst...@gmail.com W: http://nivstein.com ___ OAuth mailing list OAuth@ietf.org
[OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
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 e...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingarten nivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org. ** ** Thanks, ** ** EHL ** ** *From:* Niv Steingarten [mailto:nivst...@gmail.com] *Sent:* Monday, July 25, 2011 2:52 PM *To:* draft-ietf-oauth...@tools.ietf.org *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: nivst...@gmail.com W: http://nivstein.com ** ** -- *Niv Steingarten* *** * T: +972-54-5828088 E: nivst...@gmail.com W: http://nivstein.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
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* e...@hueniverse.com mailto:e...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingarten nivst...@gmail.com mailto:nivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org mailto:oa...@ieft.org. Thanks, EHL *From:*Niv Steingarten [mailto:nivst...@gmail.com mailto:nivst...@gmail.com] *Sent:* Monday, July 25, 2011 2:52 PM *To:* draft-ietf-oauth...@tools.ietf.org mailto:draft-ietf-oauth...@tools.ietf.org *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: nivst...@gmail.com mailto:nivst...@gmail.com W:http://nivstein.com -- *Niv Steingarten* * * T:+972-54-5828088 E: nivst...@gmail.com mailto:nivst...@gmail.com W:http://nivstein.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
Yes, I believe the vast majority of user-agents would block this kind of request if it originated from a JavaScript XMLHttpRequest or such. However, there are still scenarios in which a user-agent based client could manipulate this vulnerability. For example, the client could launch the GET request to the authorization server via an img HTML tag, taking the form of a CSRF. Since it's a blind attack, the client would likely not receive the contents of the web-page. However, this request is still necessary from the client since it has the side-effect of creating an access token (or other temporary token) on the authorization server. Since it is highly likely that a malicious client has a priori knowledge of the structure of the authorization page and form, it does not need the response in order to advance to the next step, and can simply send the fake request to 'Allow' itself to access the resource owner's resources. I believe this attack could be made very hard by either including a CAPTCHA, as you suggested, or including some kind of token or nonce in the submission of the form (which would still not prevent the attack if the authorization server doesn't enforce same origin policy). Niv On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt tors...@lodderstedt.net wrote: 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 e...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingarten nivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org. Thanks, EHL From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Monday, July 25, 2011 2:52 PM To: draft-ietf-oauth...@tools.ietf.org 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: nivst...@gmail.com W: http://nivstein.com -- Niv Steingarten T: +972-54-5828088 E: nivst...@gmail.com W: http://nivstein.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
