Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter

[Eran Hammer-Lahav <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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-mail]> 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: [e-mail] [mailto:[e-mail]] 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 <[e-mail]>
> >> wrote:
> >> >
> >> >
> >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav
> >> > <[e-mail]>
> >> > wrote:
> >> >>
> >> >>
> >> >> > -----Original Message-----
> >> >> > From: [e-mail] [mailto:[e-mail]] 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
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >> >
> >> >
> >> >
> >> > --
> >> > Breno de Medeiros
> >> >
> >> >
> >