Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Is this malicious piece of software external a native application either past of a native client or external to the browser? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 6:51 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal browser and perform an authorization flow with the resource owner for one particular scope. Using the same browser instance and based on the cookies obtained in the first run, it could silently perform additional authorization flows for other scopes. 4) internal browser (non-interactive authentication methods) - There are authentication methods available w/o the need for user-interaction, for examples SIM card authentication or certificate-based authentication. The attacker could utilize an internal, invisible browser instance in combination with such an authentication method in order to perform
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal browser and perform an authorization flow with the resource owner for one particular scope. Using the same browser instance and based on the cookies obtained in the first run, it could silently perform additional authorization flows for other scopes. 4) internal browser (non-interactive authentication methods) - There are authentication methods available w/o the need for user-interaction, for examples SIM card authentication or certificate-based authentication. The attacker could utilize an internal, invisible browser instance in combination with such an authentication method in order to perform the authorization process. I'm not sure whether the scenarios described above can be classified as CSRF. I'm having a hard time following all these scenarios. But the important part is that OAuth assumes the 'user-agent' is a compliant and secure web browser. If the user-agent does not enforce cookie boundaries, XSS, CORS policy, etc. there isn't much we can do. In other words, if the user installs a poorly design native application which has its own user-agent
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
It is a native app and it is external wrt the browser. regards, Torsten. On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote: Is this malicious piece of software external a native application either past of a native client or external to the browser? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 6:51 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal browser and perform an authorization flow with the resource owner for one particular scope. Using the same browser instance and based on the cookies obtained in the first run, it could silently perform additional authorization flows for other scopes. 4) internal browser (non-interactive authentication methods) - There are authentication methods available w/o the need for user-interaction, for examples SIM card authentication or certificate-based authentication. The attacker could utilize an internal
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I suggest we address this particular scenario in the thread model document. EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 7:26 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) It is a native app and it is external wrt the browser. regards, Torsten. On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote: Is this malicious piece of software external a native application either past of a native client or external to the browser? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 6:51 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Sorry for the late response. -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Sunday, August 21, 2011 10:59 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, This is still just a CSRF attack. I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit. I don't see any reason to include this new text based on this threat analysis. However, this doesn't mean this discussion wasn't useful. We did identify the need to explicitly discuss CSRF attacks on the authorization endpoint. We need to explicitly separate the two target of CSRF attacks (client, server) because while the solution is the same, the implementation is very different (due to the use of redirections in one). I agree, we should explicitely document these two variants of CSRF (client, authz server). But I suspect it's not only CSRF we are talking about in this thread - at least not textbook CSRF. Let me explain my thoughts: As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Hi Eran, This is still just a CSRF attack. I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit. I don't see any reason to include this new text based on this threat analysis. However, this doesn't mean this discussion wasn't useful. We did identify the need to explicitly discuss CSRF attacks on the authorization endpoint. We need to explicitly separate the two target of CSRF attacks (client, server) because while the solution is the same, the implementation is very different (due to the use of redirections in one). I agree, we should explicitely document these two variants of CSRF (client, authz server). But I suspect it's not only CSRF we are talking about in this thread - at least not textbook CSRF. Let me explain my thoughts: As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal browser and perform an authorization flow with the resource owner for one particular scope. Using the same browser instance and based on the cookies obtained in the first run, it could silently perform additional authorization flows for other scopes. 4) internal browser (non-interactive authentication methods) - There are authentication methods available w/o the need for user-interaction, for examples SIM card authentication or certificate-based authentication. The attacker could utilize an internal, invisible browser instance in combination with such an authentication method in order to perform the authorization process. I'm not sure whether the scenarios described above can be classified as CSRF. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically presses the right buttons. This obviously only works if the client can predict the form structure and expected input values. Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment? The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions. I'm keeping this proposed text out until we resolve this questions. See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? regards, Torsten. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined 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 programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Here are two very simple examples. They are very naive ones, but get the point across and I would not be suprised if they could be found in the wild: Say a client has its authorization endpoint at (1) http://www.domain.com/auth.php A client requests access to protected resources by redirecting the user-agent to: (2) http://www.domain.com/auth.php?response_type=codeclient_id=1234; redirect_uri=SOMEURIscope=SOMESCOPE One possible design choice for the developer, if a bad one, is to have the 'Allow' button point to: (3) http://www.domain.com/auth.php?[..previous query params..]allow=1 In this case, a malicious client who knows the structure of this auth flow, can simply skip (2) and redirect the user-agent to (3) in order to gain access to the protected resources. Another possible design choice for the developer (again, a very bad one) would be to issue some kind of session cookie after (2) in order to keep a state. Then, the 'Allow' button could possibly point to: (4) http://www.domain.com/allow.php without any parameters (since the state is maintained by a cookie). Here, an attacker could launch a request to (2) just to issue the state cookie, and immediately redirect the user-agent to (4) in order to gain access to the protected resources. These are two very naive scenarios which can be averted using a nonce for example (+ better design choices, for that matter). In non-user-agent based clients, a client might also be able to actually scrape the contents of the authorization HTML page, and simulate the click programmatically. In this case a nonce would be useless, but a CAPTCHA or a PIN code/password would solve the problem. -- Niv On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav e...@hueniverse.com wrote: I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. I'm keeping this proposed text out until we resolve this questions. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined 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 programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony,Barry) and all agree with it. Maybe my e-mail was lost, but I was and still am among those who have agreed with the text, as I am sure many others have What is also important is that no one has objected. I see neither the reason nor the right of an editor to remove the text. Igor On 8/18/2011 3:51 AM, Lodderstedt, Torsten wrote: I've read the thread leading to this, and the proposed text and I do not understand the attack. Can youprovide a step-by-step scenario of how an attacker gains access? I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically presses the right buttons. This obviously only works if the client can predict the form structure and expected input values. Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow.This is especially true in the case of using OAuth for login which has to be practically transparent (oneclick). I would hate to recommend a solution that no one is going to take seriously. This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment? The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions. I'm keeping this proposed text out until we resolve this questions. See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? regards, Torsten. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined 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 programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ 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 ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
Thanks. You have a typo in #1 (the authorization endpoint belongs to the authorization server, not client). This is a textbook CSRF attack on the authorization endpoint. The right solution is for the authorization server to set or maintain a session cookie (or other same-origin-protected state in the browser) in #1 as well as some hidden CSRF token in the Accept form and not allow CORS calls to that endpoint. I don't see how the measures proposed in the new section are relevant here. EHL -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 5:49 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Here are two very simple examples. They are very naive ones, but get the point across and I would not be suprised if they could be found in the wild: Say a client has its authorization endpoint at (1) http://www.domain.com/auth.php A client requests access to protected resources by redirecting the user-agent to: (2) http://www.domain.com/auth.php?response_type=codeclient_id=1234; redirect_uri=SOMEURIscope=SOMESCOPE One possible design choice for the developer, if a bad one, is to have the 'Allow' button point to: (3) http://www.domain.com/auth.php?[..previous query params..]allow=1 In this case, a malicious client who knows the structure of this auth flow, can simply skip (2) and redirect the user-agent to (3) in order to gain access to the protected resources. Another possible design choice for the developer (again, a very bad one) would be to issue some kind of session cookie after (2) in order to keep a state. Then, the 'Allow' button could possibly point to: (4) http://www.domain.com/allow.php without any parameters (since the state is maintained by a cookie). Here, an attacker could launch a request to (2) just to issue the state cookie, and immediately redirect the user-agent to (4) in order to gain access to the protected resources. These are two very naive scenarios which can be averted using a nonce for example (+ better design choices, for that matter). In non-user-agent based clients, a client might also be able to actually scrape the contents of the authorization HTML page, and simulate the click programmatically. In this case a nonce would be useless, but a CAPTCHA or a PIN code/password would solve the problem. -- Niv On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav e...@hueniverse.com wrote: I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. I'm keeping this proposed text out until we resolve this questions. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined 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 programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Hey Torsten, -Original Message- From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, August 18, 2011 12:52 AM To: Eran Hammer-Lahav; Torsten Lodderstedt; oauth@ietf.org Subject: AW: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically presses the right buttons. This obviously only works if the client can predict the form structure and expected input values. That's not an attack but a description of capabilities. The attack example provided by Niv is a *classic* CSRF attack on the authorization endpoint. Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment? I don't understand the attack and how the proposed solution address it. I'm really happy for everyone else who got it, but I need more information to process it. The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. True. But it was central in the list discussion and was promoted as strong defense to whatever this attack is. I think that CAPCHA is an impractical recommendation in general for the authorization endpoint. Can you point to any real world example of a large provider forcing CAPCHA on every login? That's what this amounts to. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions. The text hints at a very dangerous attack vector of scripts doing 'really bad things'. But it doesn't show why this attack requires any kind of automation at all. If I am targeting just a small number of people, I can automate this by sending a message to a human who will break the CAPCHA and quickly return the link to approve access. The other measures either have the same properties, are just there to annoy the attacker, or provide some kind of after the fact notice (when it is clearly too late to prevent damage). I'm keeping this proposed text out until we resolve this questions. See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? no one (except you) is an interesting statement... :-) This is not a process issue. New text has been proposed with the support of a few working group members. The working group has been largely silent about it (and the review you referenced above was done off list). I have read the new text and did not understand it, therefore, could not edit the text as I have done with every other proposed language. No new draft will be published until we resolve all open issues, which is exactly what I have stated above. To make it clearer: I am keeping this proposed text out of *my* working draft for -21 until the working group discusses the text further and addresses the issues I have raised about the text as a working group member (technical issues) and as an editor (clarity issues). As for IETF process, all it takes is one objection to block text from being *automatically* added to the specification. I have not implied anywhere that I have made any decision (or have the authority to) with regard to this text, only that I'm holding it back until the issues are resolved. And IETF process does not require full agreement to solve issues which is the role of the chairs to resolve. In this case, we're nowhere near needing help from the chairs - just the assistance of the text authors to do their job and explain it. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) (thanks for the typo correction) Yes, the example I provided is a very lightweight one which does take the form of CSRF, but it is only the simplest example of a family of automated authorization flow attacks. Indeed, a nonce (or hidden token, both serve the same purpose in this case) would be enough here. Great. So we need to add explicit text about preventing CSRF attacks at the authorization endpoint. If the client is not user-agent based, a full-fledged forgery of the whole process is possible, one in which CORS and sandboxes have no meaning. In a native client, unless some kind of human test is performed, the whole flow could be spoofed. Can you provide another example with the same level of detail as you provided below? A CAPTCHA and/or password entry are not bullet-proof, but they provide a steep obstacle for the attacker. CAPTCHA and password entry are two completely difference measures and are rarely interchangeable. CAPTCHA does nothing more than increase the likelihood that the entity on the other side is a human. Any attack prevented by CAPTCHA must be one in which automation and speed are crucial. I still don't understand what it *solves*. Another option would be, for example, to email the resource owner an OTP, with the following message The application [...] requests access to [...]. Please use the number to allow it access etc... (similar to Google's and Facebook's two-step sign-in). Two-factor authentication is good, but completely impractical for most web authorization scenario. You need to remember that the authorization page is used for both the initial grant, but also for delegated login (by far a more frequent use). An access token can be issued almost automatically if the client has been previously authorized. The first attack described in my previous message takes the form of CSRF, while the above one may be bypassed by an attacker with the help of some sort of clickjacking or similar. Eventually this threat description is for a family of attacks which mimic the behavior of the resource owner in order to gain access to protected resources, and some possible countermeasures. I don't understand this family of attacks. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I'd like to ask the chairs to open an issue for this. http://trac.tools.ietf.org/wg/oauth/trac/ticket/24 I didn't realize how hyper sensitive this working group has become that every proposal being questioned needs a ticket to prove to people that they are not being dismissed. It's OK: tickets are cheap, and I don't mind... and if it helps people to know that discussions that aren't quickly resolved are being tracked, then that's what the issue tracker is there for. It makes sure things don't get forgotten, and reminds people what to look more closely at in the next doc rev. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Yes, the example I provided is a very lightweight one which does take the form of CSRF, but it is only the simplest example of a family of automated authorization flow attacks. Indeed, a nonce (or hidden token, both serve the same purpose in this case) would be enough here. Great. So we need to add explicit text about preventing CSRF attacks at the authorization endpoint. General comment, not for this issue alone (and not specifically to the folks conversing here): There are a great many things we can say about threats and attacks, which is why we have the threats document by Torsten, et al. I'm generally in favour of putting more security considerations into the base document to describe threats that implementors need to be concerned about, and well-crafted text that the editors can drop in is a good thing. That said, the reason we decided to put highlights into the base doc's Security Considerations section, and then refer to the larger document for more details and a more complete threat analysis is that we wanted to strike a balance, keep the base doc for protocol details, and leave the threat descriptions in the base doc as general threat *classes*. As we debate the various attack descriptions and mitigations that we might like to add, please keep that balance in mind, and think carefully about whether the details of *this specific* attack should go into this document, or whether we just need to cover the general class of threats here and put the details of this attack into draft-ietf-oauth-v2-threatmodel. Otherwise, we might eventually merge the entire threat analysis document into the base, one paragraph at a time. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, to finally receive an access token/authorization code in the redirection. CAPTCHA and password entry are two completely difference measures and are rarely interchangeable. CAPTCHA does nothing more than increase the likelihood that the entity on the other side is a human. Any attack prevented by CAPTCHA must be one in which automation and speed are crucial. I still don't understand what it *solves*. CAPTCHAs are used for human testing and passwords for identity testing, but in this case they both serve the same purpose of decreasing the likelihood that the flow is automated. Two-factor authentication is good, but completely impractical for most web authorization scenario. You need to remember that the authorization page is used for both the initial grant, but also for delegated login (by far a more frequent use). An access token can be issued almost automatically if the client has been previously authorized. You're right, sometimes there's a trade-off between better security and user experience. I think it should eventually be up to the implementer to choose what is right for their applications' security requirements. I think it is in the scope of the specification to bring this issue up for developers to consider. I don't understand this family of attacks. I don't know how to put it any differently than I already have; simply a class of attacks (the three scenarios described in this thread are examples thereof) in which a malicious client takes the role of both the client and the resource owner. -- Niv ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. EHL [1] http://www.ibras.dk/montypython/episode34.htm ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. and launch it using the same HTTP framework/WebKit, simulating the Allow button. This is still just a CSRF attack. In order to automate the approval action, they attacker has to get the user-agent (embedded or not) to make a cross site request which will include some session state (cookies or otherwise). If the authorization page is CSRF protected, they attacker will not be able to construct such a link. The nature of the client does not matter. In either case, the client has to gain access somehow to the authorization server state stored in the browser. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
This is, in my opinion, another style of CSRF. I the attacker present your browser (user agent) with a link, and your browser presents a credential automatically to the token endpoint, which automatically issues a token to be given back to me? That's a classic CSRF, how to fix it is interesting. I'm of the opinion that the user *should* be pesented with some UI at that point so they can make an informed choice about issuing a credential. Not everyone agrees with me though (mostly business folks that want to avoid user interaction because it's too scary and somehow informing the user what they are doign is a bad thing). -bill From: Niv Steingarten nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 12:11 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request and launch it using the same HTTP framework/WebKit, simulating the Allow button. [1] http://www.ibras.dk/montypython/episode34.htm +1 for more Monty Python references. -- Niv ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
We know how to fix CSRF attacks on form submission which this is. The UI questions about more about legitimate client interaction and how informed a user should be. EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, August 18, 2011 12:27 PM To: Niv Steingarten; Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) This is, in my opinion, another style of CSRF. I the attacker present your browser (user agent) with a link, and your browser presents a credential automatically to the token endpoint, which automatically issues a token to be given back to me? That's a classic CSRF, how to fix it is interesting. I'm of the opinion that the user *should* be pesented with some UI at that point so they can make an informed choice about issuing a credential. Not everyone agrees with me though (mostly business folks that want to avoid user interaction because it's too scary and somehow informing the user what they are doign is a bad thing). -bill From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Thursday, August 18, 2011 12:11 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request and launch it using the same HTTP framework/WebKit, simulating the Allow button. [1] http://www.ibras.dk/montypython/episode34.htm +1 for more Monty Python references. -- Niv ___ OAuth mailing list OAuth@ietf.orgmailto: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] Draft 20 last call comment (Resource Owner Impersonation)
On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. But since both requests (the one requesting the auth endpoint and the one simulating the allow) are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. and launch it using the same HTTP framework/WebKit, simulating the Allow button. This is still just a CSRF attack. I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). -- Niv ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. You only said that about the first request. But since both requests (the one requesting the auth endpoint and the one simulating the allow) are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. That's not exactly right. This entire attack is based on: 1. The presence of some session cookie or other user-agent state to bypass active authentication, and 2. The ability of the malicious client to make CSS calls using #1. Everything else is a red herring because the ability to automate this attack and make it more powerful is completely beside the point. If you deploy an effective CSRF protection, everything else is a non-issue. This is why the client type does not matter when it comes to not using CORS. The authorization server MUST NOT allow CSS calls on the authorization endpoint because that's the actual attack you described - using local state (session cookie) to make a CSS call. If the client makes direct calls to the authorization endpoint, it cannot impersonate the resource owner. and launch it using the same HTTP framework/WebKit, simulating the Allow button. This is still just a CSRF attack. I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit. I don't see any reason to include this new text based on this threat analysis. However, this doesn't mean
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. You only said that about the first request. But since both requests (the one requesting the auth endpoint and the one simulating the allow) are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. That's not exactly right. This entire attack is based on: 1. The presence of some session cookie or other user-agent state to bypass active authentication, and 2. The ability of the malicious client to make CSS calls using #1. Everything else is a red herring because the ability to automate this attack and make it more powerful is completely beside the point. If you deploy an effective CSRF protection, everything else is a non-issue. This is why the client type does not matter when
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I proposed text that I think is more complete in a previous message... From: Niv Steingarten nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 4:33 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. You only said that about the first request. But since both requests (the one requesting the auth endpoint and the one simulating the allow) are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. That's not exactly right. This entire attack is based on: 1. The presence of some session cookie or other user-agent state to bypass active
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills wmi...@yahoo-inc.com wrote: I proposed text that I think is more complete in a previous message... From: Niv Steingarten nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 4:33 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. You only said
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
While I agree in principal, I think there are real world use cases that make this more complicated. If, for example, a user has previously approved access to a particular endpoint then we might be willing to re-issue credentials without user interaction. I don't know how we capture this in the right way in the spec. From: Niv Steingarten nivst...@gmail.com To: William J. Mills wmi...@yahoo-inc.com Cc: Eran Hammer-Lahav e...@hueniverse.com; oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 6:06 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills wmi...@yahoo-inc.com wrote: I proposed text that I think is more complete in a previous message... From: Niv Steingarten nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 4:33 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
To reiterate Berry's earlier point, we are not going to cover everything in the v2 spec. We need to agree on new language for the CSRF section, and add the potential attacks on both endpoints. But beyond that, it will probably be best to add it to the threat model document - but I will leave that up to the editors of that document. EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, August 18, 2011 9:21 PM To: Niv Steingarten Cc: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) While I agree in principal, I think there are real world use cases that make this more complicated. If, for example, a user has previously approved access to a particular endpoint then we might be willing to re-issue credentials without user interaction. I don't know how we capture this in the right way in the spec. From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com To: William J. Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com Cc: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com; oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Thursday, August 18, 2011 6:06 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com wrote: I proposed text that I think is more complete in a previous message... From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Thursday, August 18, 2011 4:33 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. I'm keeping this proposed text out until we resolve this questions. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined 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 programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ 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
[OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined 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 programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
