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 <e...@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-boun...@ietf.org [mailto:oauth-boun...@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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
