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
