Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Jul 2011 12:02:02 -0700

This needs to be reworked to reflect reality. The state value must be shared with the resource owner's browser and authorization server, so it is not really a secret known only to the client…

EHL

From: Mark Mcgloin <[email-masked]<mailto:[email-masked]>>
Date: Wed, 1 Jun 2011 11:28:33 -0700
To: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions

Hi Torsten

It was implicit that the state parameter would be secret and not guessable
but that it probably worth spelling out, as you and Breno state. Here is a
modified version

CSRF
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has
authenticated. CSRF attacks on OAuth approvals can allow an attacker to
obtain authorization to OAuth Protected Resources without the consent of
the User.
The state parameter should be used to mitigate against CSRF attacks,
particularly for login CSRF attacks. It is strongly RECOMMENDED that the
client sends the state parameter with authorization requests to the
authorization server. The state parameter MUST be non-guessable and MUST be
a secret only accessible to the client. The authorization server will send
it in the response when redirecting the user to back to the client which
MUST then validate the state parameter matches on the response.

Regards
Mark

Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote on 01/06/2011 09:11:31:

From:

Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>

To:

Mark Mcgloin/Ireland/IBM@IBMIE

Cc:

[email-masked]<mailto:[email-masked]>

Date:

01/06/2011 09:11

Subject:

Re: [OAUTH-WG] Draft 16 Security Considerations additions

Hi Mark,

Am 31.05.2011 22:58, schrieb Mark Mcgloin:
> Eran
>
> Here are some additional sections to add to the next draft under
security
> considerations
>
> CSRF
> Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
> requests are transmitted from a user that the website trusts or has
> authenticated. CSRF attacks on OAuth approvals can allow an attacker to
> obtain authorization to OAuth Protected Resources without the consent
of
> the User.
> The state parameter should be used to mitigate against CSRF attacks,
> particularly for login CSRF attacks. It is strongly RECOMMENDED that
the
> client sends the state parameter with authorization requests to the
> authorization server. The authorization server will send it in the
response
> when redirecting the user to back to the client which SHOULD then
validate
> the state parameter matches on the response.

As far as I understand, the goal of the countermeasure is to bind the
authz flow to a certain user agent (instance). So client must verify
that the state parameter (or any other URL parameter?) matches some data
found in the user agent itself before further processing the authz code.

Breno explained it as follows:
-----
- Client or user-agent generates a secret.
- The secret is stored in a location accessible only by the client or
the user agent (i.e., protected by same-origin policy). E.g.: DOM
variable (protected by javascript or other DOM-binding language's
enforcement of SOP), HTTP cookie, HTML5 client-side storage, etc.
- The secret is attached to the state before a request is issued by the
client
- When the response is received, before accepting the token or code, the
client consults the user agent state and rejects the response altogether
if the state does not match the user agent's stored value.
----

I would suggest to incorporate this into the decription:

It is strongly RECOMMENDED that the client sends the state parameter
with authorization requests to the authorization server. _The state
parameter MUST refer to a secret value retained at the user agent._
The authorization server will send the _state parameter_ in the
response when redirecting the user to back to the client which
_MUST_ then validate the state parameter_'s value against the secret
value in the user agent_.

regards,
Torsten.

> Clickjacking
> Clickjacking is the process of tricking users into revealing
confidential
> information or taking control of their computer while clicking on
seemingly
> innocuous web pages. In more detail, a malicious site loads the target
site
> in a transparent iframe overlaid on top of a set of dummy buttons which
are
> carefully constructed to be placed directly under important buttons on
the
> target site. When a user clicks a visible button, they are actually
> clicking a button (such as an "Authorize" button) on the hidden page.
> To prevent clickjacking (and phishing attacks), native applications
SHOULD
> use external browsers instead of embedding browsers in an iFrame when
> requesting end-user authorization. For newer browsers, avoidance of
iFrames
> can be enforced server side by using the X-FRAME-OPTION header. This
header
> can have two values, deny and sameorigin, which will block any framing
or
> framing by sites with a different origin, respectively. For older
browsers,
> javascript framebusting techniques can be used but may not be effective
in
> all browsers.
>
>
> Regards
> Mark
>
> _______________________________________________
> OAuth mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Mark Mcgloin <[email-masked]>
Date: Wed, 6 Jul 2011 16:56:03 +0100

Reworded to modify the text around secret and some additional info on
redirect-uri (with some input from Shane Weaden) and adding state in
dynamic redirect-uri (with input from Torsten)

CSRF
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has
authenticated. CSRF attacks on OAuth approvals can allow an attacker to
obtain authorization to OAuth Protected Resources without the consent of
the User.
The state parameter should be used to mitigate against CSRF attacks,
particularly for login CSRF attacks. CSRF attacks against a client's
redirect URI allow an attacker to inject their own authorization code (or
access token for implicit grant flow). This may result in the client using
an access token associated with the attackers account rather than the
victims. Depending on the nature of the client and the protected resources,
this can have undesirable and damaging effects.
It is strongly RECOMMENDED that the client sends the state parameter with
authorization requests to the authorization server. The state parameter
MUST be non-guessable and the client MUST be capable of keeping it in a
location accessible only by the client or the user agent (i.e., protected
by same-origin policy). e.g.: DOM variable (protected by _javascript_ or
other DOM-binding language's enforcement of SOP), HTTP cookie, HTML5
client-side storage, etc. The authorization server will send it in the
response when redirecting the user to back to the client which MUST then
validate the state parameter matches on the response. Use of the state
parameter by a client protects against this style of attack as the attacker
cannot know the state parameter associated with the victims browser session
at the client.
While sending the state parameter is the preferred mechanism for linking
the client to the authorization requests and callbacks, a state parameter
(s) embedded into the redirect uri could be used for the same purpose. A
prerequisite is that the authorization server's uri validation policy must
allow for dynamic uri query parts.

Clickjacking
Clickjacking is the process of tricking users into revealing confidential
information or taking control of their computer while clicking on seemingly
innocuous web pages. In more detail, a malicious site loads the target site
in a transparent iframe overlaid on top of a set of dummy buttons which are
carefully constructed to be placed directly under important buttons on the
target site. When a user clicks a visible button, they are actually
clicking a button (such as an "Authorize" button) on the hidden page.
To prevent clickjacking (and phishing attacks), native applications SHOULD
use external browsers instead of embedding browsers in an iFrame when
requesting end-user authorization. For newer browsers, avoidance of iFrames
can be enforced server side by using the X-FRAME-OPTION header. This header
can have two values, deny and sameorigin, which will block any framing or
framing by sites with a different origin, respectively. For older browsers,
javascript framebusting techniques can be used but may not be effective in
all browsers.

Regards

Eran Hammer-Lahav <[email-masked]> wrote on 04/07/2011 20:02:02:

> From:
>
> Eran Hammer-Lahav <[email-masked]>
>
> To:
>
> Mark Mcgloin/Ireland/IBM@IBMIE, Torsten Lodderstedt
<[email-masked]>
>
> Cc:
>
> "[email-masked]" <[email-masked]>
>
> Date:
>
> 04/07/2011 20:01
>
> Subject:
>
> This needs to be reworked to reflect reality. The state value must
> be shared with the resource owner's browser and authorization
> server, so it is not really a secret known only to the client…
>
> EHL
>
> From: Mark Mcgloin <[email-masked]>
> To: Torsten Lodderstedt <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Torsten Lodderstedt <[email-masked]> wrote on 01/06/2011
09:11:31:
>
> From:
>
> Torsten Lodderstedt <[email-masked]>
>
> To:
>
> [email-masked]
> > [email-masked]
> [email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Jul 2011 23:26:22 -0700

" using a DOM variable (protected by JavaScript or other DOM-binding language's enforcement of SOP)"

This is not clear without a reference or more details description.

EHL

> -----Original Message-----
> From: Mark Mcgloin [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2011 8:56 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; Torsten Lodderstedt
> particularly for login CSRF attacks. CSRF attacks against a client's redirect URI
> allow an attacker to inject their own authorization code (or access token for
> implicit grant flow). This may result in the client using an access token
> associated with the attackers account rather than the victims. Depending on
> the nature of the client and the protected resources, this can have
> undesirable and damaging effects.
> location accessible only by the client or the user agent (i.e., protected by
> same-origin policy). e.g.: DOM variable (protected by _javascript_ or other
> DOM-binding language's enforcement of SOP), HTTP cookie, HTML5 client-
> side storage, etc. The authorization server will send it in the response when
> redirecting the user to back to the client which MUST then validate the state
> parameter matches on the response. Use of the state parameter by a client
> protects against this style of attack as the attacker cannot know the state
> parameter associated with the victims browser session at the client.
> prerequisite is that the authorization server's uri validation policy must allow
> for dynamic uri query parts.
> 
> 
> Clickjacking
> innocuous web pages. In more detail, a malicious site loads the target site in a
> transparent iframe overlaid on top of a set of dummy buttons which are
> target site. When a user clicks a visible button, they are actually clicking a
> button (such as an "Authorize" button) on the hidden page.
> iFrames can be enforced server side by using the X-FRAME-OPTION header.
> This header can have two values, deny and sameorigin, which will block any
> framing or framing by sites with a different origin, respectively. For older
> browsers, javascript framebusting techniques can be used but may not be
> effective in all browsers.
> 
> Regards
> 
> > This needs to be reworked to reflect reality. The state value must be
> > shared with the resource owner's browser and authorization server, so
> > it is not really a secret known only to the client…
> >
> > EHL
> >
> > but that it probably worth spelling out, as you and Breno state. Here
> > is
> a
> > modified version
> >
> > CSRF
> > authenticated. CSRF attacks on OAuth approvals can allow an attacker
> > to obtain authorization to OAuth Protected Resources without the
> > consent of the User.
> > the client sends the state parameter with authorization requests to
> > the authorization server. The state parameter MUST be non-guessable
> > and MUST
> be
> > it in the response when redirecting the user to back to the client
> > which MUST then validate the state parameter matches on the response.
> >
> > Regards
> > Mark
> >
> > > authenticated. CSRF attacks on OAuth approvals can allow an attacker
> > > to obtain authorization to OAuth Protected Resources without the
> > > consent
> > of
> > > the User.
> > that the state parameter (or any other URL parameter?) matches some
> > data found in the user agent itself before further processing the authz
> code.
> >
> > - The secret is attached to the state before a request is issued by
> > the client
> > - When the response is received, before accepting the token or code,
> > the client consults the user agent state and rejects the response
> > altogether if the state does not match the user agent's stored value.
> > ----
> >
> > response when redirecting the user to back to the client which _MUST_
> > then validate the state parameter_'s value against the secret value in
> > the user agent_.
> >
> > regards,
> > Torsten.
> >
> > > Clickjacking
> > > use external browsers instead of embedding browsers in an iFrame
> > > when requesting end-user authorization. For newer browsers,
> > > avoidance of
> > iFrames

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Jul 2011 23:35:37 -0700

Can this be reworked to discuss the authorization endpoint specifically? The use of 'target' site is confusing. This section needs to be much more specific to the authorization process.

EHL

---

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

On Thu, Jul 7, 2011 at 11:35 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> Can this be reworked to discuss the authorization endpoint specifically?
> The use of 'target' site is confusing. This section needs to be much more
> specific to the authorization process.
>

Just chiming in to say that I am happy this language is being added. The
currently proposed text is good starting point, and I agree with Eran's last
recommendation.

> site in a
> clicking a

-- 
Breno de Medeiros