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

[Bob Van Zant <[e-mail]>]

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
>> >
>> >
>