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

It wasn't the length that I cared about very much. Other than I don't
want to have to accept someone's 1024 byte state value (it's a waste
of my resources).

Percent encoding doesn't help when the client un-percent encodes it
and puts it verbatim onto his website. An example: Perhaps the state
variable is supposed to be the resource owner's name. The attacker
creates a link to my API that is:

/oauth/authorize?client_id=xxx&response_type=code&state=percent_encoded(<script>badstuff</script>)

If the client simply puts "state" back onto some webpage, after
un-percent encoding it but without HTML encoding it, then we have a
vulnerability?

-Bob

On Fri, Jul 15, 2011 at 8:41 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I don't see the problem. The state value is percent-encoded both ways, so the only way to inject a bad value there is by including a value that has special meaning to the client. Putting a character limit on it will not do anything to prevent that.
>
> The server should reject requests with query parameters that are not properly percent-encoded.
>
> EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Bob Van Zant
>> Sent: Friday, July 15, 2011 8:35 AM
>> To: OAuth WG
>> Subject: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>>
>> Hi everyone,
>> I'm in the process of implementing OAuth and I'm a little concerned about
>> the "state" parameter that a client can send as part of the authorization
>> request. The spec says that the value is opaque and that I need to accept,
>> store, and reply with exactly what the client sent me. Can we impose some
>> restrictions on the type of data a client can send?
>>
>> The reason is that I don't necessarily trust the clients of my API to properly
>> deal with sanitizing data. If someone steals a client_id (not
>> hard) and puts something malicious into the state field I'll happily redirect the
>> resource owner to my client's site with malicious data in state. If the client
>> does not properly handle this malicious data (there's an established track
>> record here) then I've opened my customer (the resource owner) to an
>> attack.
>>
>> Did I miss something in the spec where it limits what this variable can be? If
>> not I'd like to propose that we limit this field to a set of characters that are
>> safe. [a-zA-Z0-9_-]{0,100}
>>
>> The authorization server would validate that the state field contains only
>> those characters and if not SHOULD show the resource owner an error
>> (consistent with section 4.1.2.1, paragraph 1 and others).
>>
>> Thank you for all of your hard work on this spec to date and thanks for your
>> consideration of my comments.
>>
>> -Bob
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>