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

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