[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
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(badstuff)
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 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
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
On Sun, Jul 17, 2011 at 2:49 AM, Eliot Lear wrote: > Bob, > > Just on this one point: > > On 7/15/11 5:35 PM, Bob Van Zant wrote: >> The spec says that the value is opaque and that >> I need to accept, store, and reply with exactly what the client sent >> me. > > Where does it actually require you to "store" the "state" contents > beyond the point where you issue your reply? Beyond the reply, you're right. I exaggerate a little. I sort of wish application developers would figure out their own way to manage state. Or, like I've asked for here, at least give me something in the spec that allows me to impose limits. > > One other point: if the redirection_uri can have fragments and can be > provided, why is state necessary? Just to be clear, section 3.1.2 says that the redirect URI: MAY include a query component which MUST be retained by the authorization server when adding additional query parameters, and MUST NOT include a fragment component. So the app developer could stick anything they want in the querystring and as the authorization server we have to hang on to that in addition to the state variable. -Bob ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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 wrote: > > > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav > wrote: >> >> >> > -Original Message- >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Breno de Medeiros > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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 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: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] 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 >> wrote: >> > >> > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav >> > >> > wrote: >> >> >> >> >> >> > -Original Message- >> >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > -- >> > Breno de Medeiros >> > >> > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
> 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? I'll give it a shot. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Extra "Authorization: Basic" lines in examples
The Authorization header in those examples is authorizing the client. In 4.1.3 the /token URI requires HTTP basic authorization to access. Section 2.4 talks about this more. -Bob On Mon, Jul 25, 2011 at 9:27 PM, Mike Jones wrote: > In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain > both the line “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” and > credentials in the post body. For instance, the example from 4.3.2 is: > > > > POST /token HTTP/1.1 > > Host: server.example.com > > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > Content-Type: application/x-www-form-urlencoded;charset=UTF-8 > > > > grant_type=password&username=johndoe&password=A3ddj3w > > > > I believe that the “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” line > should be deleted from all of these examples, as you either use Basic or > credentials in the post body, but not both. > > > > Thanks, > > -- Mike > > > > ___ > 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
[OAUTH-WG] Returning two tokens. Was: Re: Rechartering
I'm going to reiterate what has already been said. OAuth already supports what you're trying to do. Just request a token twice, the first time request it with a scope or scopes that allows these special operations. The second time request it with a scope or scopes that do not. In general I really like how simple OAuth 2 is. By working within the constraints of this simplicity we can keep the protocol simple and easy to use. -Bob On Tuesday, October 25, 2011, Dave Rochwerger wrote: > Hi Dan, > I think we are going down the wrong path here. > Basically, you've started with the premise of wanting plain HTTP scheme (in some circumstances), which has caused you to suggest both of, firstly, relaxing the only method of encryption in oauth2 and secondly, to further complicate the protocol by allowing multiple tokens to be returned. > OAuth2 (unlike version 1) has no signatures or other encryption - it relies solely on SSL. Therefore any relaxation of this requirement breaks security wide open (even in your specific short-term token case). > I think you're asking the wrong question. > We should not ask "to relax the SSL requirement", but rather - Why do you not want to use SSL? > With today's computer speeds, there is no reason not to use SSL. The plain HTTP scheme does not really provide a noticeable enough performance boost. On a side note, if the likes of Google's SPDY is anything to go by, the future might always be SSL only anyway. > Cheers, > Dave > > On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin wrote: > > You’re right, if tracking was all we needed then a single token would suffice. The reason for two tokens has more to do with the fact that we’d like to allow “protected” operations to be called over plain http. This opens up the possibility of an attacker intercepting the token for his own nefarious use. If the only thing that token gave him access to was relatively benign operations like image search, it would be an acceptable risk (especially if we have a relatively short lifespan for the token). > > > > In contrast, “confidential” operations would only be callable over https. By requiring a different token for them (and not allowing that token to be used for unprotected operations) we prevent it from being intercepted. This design intentionally mimics the way secure and non-secure http cookies work. > > > > Oauth today basically requires https for all bearer token implementations. I would like to see this relaxed somewhat. > > > > Dan > > > > From: Dave Rochwerger [mailto:da...@quizlet.com] > Sent: Tuesday, October 25, 2011 4:08 PM > To: Dan Taflin > > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering > > > > Is separating this out into 2 different tokens, really the best way to solve your use case? > > > > It sounds to me that you simply want to track/log the two types of accesses differently, which can be done entirely outside of the oauth2 process. > > Just bucket your operations into two piles internally and track appropriately (which you would have to do anyway with scopes). > > > > Scopes are the specific access that the end user grants to a 3rd party to access their protected resources. > > > > When an application, to use your example, asks for the scope "protected confidential", they are providing those two levels of access to the 3rd party application. If the user says "allow", then that application has all the access that those two scopes provides. > > > > Rather than getting applications to then further choose between two tokens to simply delineate two sets of operations seems like the wrong place to be doing this. > > i.e., why does the 3rd party application have to choose which token to use for each set of operations? - the user has already granted both. The resource server can do whatever tracking/logging it wants based on the actual operations requested - using the single token in this case. > > > > Regards, > > Dave > > > > On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin wrote: > > I would like to second Torsten's pitch for the ability to return multiple access tokens with a single authorization process. The use case for my company is to segment operatio ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
