Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 12 Aug 2011 16:56:26 +0200

Hi all,

I think the impersonation issue as raised by Niv on the list should be 
covered by the core spec. It directly aims at the trustworthiness of the 
user consent, which in my opinion is one of the core principles of 
OAuth. I therefore suggest to add a description to section 10.

Please find below the text Niv and I prepared. In comparison to  Niv's 
original proposal, it covers resource owner impersonation for all client 
categories.

regards,
Torsten.

proposed text:

10.<to be determined> Resource Owner Impersonation

When a client requests access to protected resources, the
authorization flow normally involves the resource owner's explicit
response to the access request, either granting or denying access to
the protected resources.

A malicious client can exploit knowledge of the structure of this
flow in order to gain authorization without the resource owner's
consent, by transmitting the necessary requests programmatically,
and simulating the flow against the authorization server. An 
suthorization
server will be vulnerable to this threat, if it uses non-interactive
authentication mechanisms or split the authorization flow across 
multiple
pages.

It is RECOMMENDED that the authorization server takes measures to
ensure that the authorization flow cannot be simulated.
Attacks performed by scripts running within a trusted user-agent can
be detected by verifying the source of the request using HTTP referrer
headers. In order to prevent such an attack, the authorization server 
may
force a user interaction based on non-predictable input values as part 
of
the user consent approval.

The authorization server could combine password authentication and user
consent in a single form, make use of CAPTCHAs or one-time secrets.

Alternatively, the authorization server could notify the resource owner 
of
any approval by appropriate means, e.g. text message or e-Mail.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 12 Aug 2011 13:40:34 -0400

> original proposal, it covers resource owner impersonation for all client

This makes sense to me, and I like the proposed text.

Barry, as participant

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 17 Aug 2011 22:58:23 -0700

I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access?

Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously.

I'm keeping this proposed text out until we resolve this questions.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Friday, August 12, 2011 7:56 AM
> To: [email-masked]
> Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> Hi all,
> 
> I think the impersonation issue as raised by Niv on the list should be covered
> by the core spec. It directly aims at the trustworthiness of the user consent,
> which in my opinion is one of the core principles of OAuth. I therefore
> suggest to add a description to section 10.
> 
> Please find below the text Niv and I prepared. In comparison to  Niv's original
> proposal, it covers resource owner impersonation for all client categories.
> 
> regards,
> Torsten.
> 
> proposed text:
> 
> When a client requests access to protected resources, the authorization flow
> normally involves the resource owner's explicit response to the access
> request, either granting or denying access to the protected resources.
> 
> A malicious client can exploit knowledge of the structure of this flow in order
> to gain authorization without the resource owner's consent, by transmitting
> the necessary requests programmatically, and simulating the flow against the
> authorization server. An suthorization server will be vulnerable to this threat,
> if it uses non-interactive authentication mechanisms or split the authorization
> flow across multiple pages.
> 
> It is RECOMMENDED that the authorization server takes measures to ensure
> that the authorization flow cannot be simulated.
> Attacks performed by scripts running within a trusted user-agent can be
> detected by verifying the source of the request using HTTP referrer headers.
> In order to prevent such an attack, the authorization server may force a user
> interaction based on non-predictable input values as part of the user consent
> approval.
> 
> Alternatively, the authorization server could notify the resource owner of
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 18 Aug 2011 09:51:45 +0200

>I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you >provide a step-by-step scenario of how an attacker gains access?

I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically "presses" the right buttons. This obviously only works if the client can predict the form structure and expected input values.

>Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. >This is especially true in the case of using OAuth for login which has to be practically transparent (one >click). I would hate to recommend a solution that no one is going to take seriously.

This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment?

The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions.

>I'm keeping this proposed text out until we resolve this questions.

See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? 

regards,
Torsten.

EHL

---

From: Niv Steingarten <[email-masked]>
Date: Thu, 18 Aug 2011 15:48:37 +0300

Here are two very simple examples. They are very naive ones, but get the
point across and I would not be suprised if they could be found in the
wild:

Say a client has its authorization endpoint at

  (1) http://www.domain.com/auth.php
	
A client requests access to protected resources by redirecting the
user-agent to:

  (2) http://www.domain.com/auth.php?response_type=code&client_id=1234&
      redirect_uri=SOMEURI&scope=SOMESCOPE

One possible design choice for the developer, if a bad one, is to have
the 'Allow' button point to:

  (3) http://www.domain.com/auth.php?[..previous query params..]&allow=1

In this case, a malicious client who knows the structure of this auth
flow, can simply skip (2) and redirect the user-agent to (3) in order
to gain access to the protected resources.

Another possible design choice for the developer (again, a very bad
one) would be to issue some kind of session cookie after (2) in order
to keep a state. Then, the 'Allow' button could possibly point to:

  (4) http://www.domain.com/allow.php

without any parameters (since the state is maintained by a cookie).

Here, an attacker could launch a request to (2) just to issue the state
cookie, and immediately redirect the user-agent to (4) in order to gain
access to the protected resources.

These are two very naive scenarios which can be averted using a nonce
for example (+ better design choices, for that matter).

In non-user-agent based clients, a client might also be able to actually
scrape the contents of the authorization HTML page, and simulate the
click programmatically. In this case a nonce would be useless, but a
CAPTCHA or a PIN code/password would solve the problem.

-- Niv

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 18 Aug 2011 11:49:28 -0400

>This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony,>Barry) and all agree with it.

Maybe my e-mail was lost, but I was and still am among those who have agreed with the text, as I am sure many others have

What is also important is that no one has objected.

I see neither the reason nor the right of an editor to remove the text.

Igor

On 8/18/2011 3:51 AM, Lodderstedt, Torsten wrote:
>> I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you>provide a step-by-step scenario of how an attacker gains access?
>> Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow.>This is especially true in the case of using OAuth for login which has to be practically transparent (one>click). I would hate to recommend a solution that no one is going to take seriously.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 09:23:52 -0700

Thanks. You have a typo in #1 (the authorization endpoint belongs to the authorization server, not client).

This is a textbook CSRF attack on the authorization endpoint.

The right solution is for the authorization server to set or maintain a session cookie (or other same-origin-protected state in the browser) in #1 as well as some hidden CSRF token in the Accept form and not allow CORS calls to that endpoint. I don't see how the measures proposed in the new section are relevant here.

EHL

> From: Niv Steingarten [mailto:[email-masked]]
> Sent: Thursday, August 18, 2011 5:49 AM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; [email-masked]
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> A client requests access to protected resources by redirecting the user-agent
> to:
> 
>   (2)
> http://www.domain.com/auth.php?response_type=code&client_id=1234&
> One possible design choice for the developer, if a bad one, is to have the
> 'Allow' button point to:
> 
> In this case, a malicious client who knows the structure of this auth flow, can
> simply skip (2) and redirect the user-agent to (3) in order to gain access to the
> protected resources.
> 
> one) would be to issue some kind of session cookie after (2) in order to keep
> a state. Then, the 'Allow' button could possibly point to:
> 
> Here, an attacker could launch a request to (2) just to issue the state cookie,
> and immediately redirect the user-agent to (4) in order to gain access to the
> protected resources.
> 
> These are two very naive scenarios which can be averted using a nonce for
> example (+ better design choices, for that matter).
> 
> In non-user-agent based clients, a client might also be able to actually scrape
> the contents of the authorization HTML page, and simulate the click
> programmatically. In this case a nonce would be useless, but a CAPTCHA or a
> PIN code/password would solve the problem.
> 
> -- Niv
> 
> 
> 
> > I've read the thread leading to this, and the proposed text and I do not
> understand the attack. Can you provide a step-by-step scenario of how an
> attacker gains access?
> >
> > Also, it is unlikely that any major provider is going to require CAPCHA as
> part of the authorization flow. This is especially true in the case of using
> OAuth for login which has to be practically transparent (one click). I would
> hate to recommend a solution that no one is going to take seriously.
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Torsten Lodderstedt
> >> I think the impersonation issue as raised by Niv on the list should
> >> be covered by the core spec. It directly aims at the trustworthiness
> >> of the user consent, which in my opinion is one of the core
> >> principles of OAuth. I therefore suggest to add a description to section 10.
> >>
> >> Please find below the text Niv and I prepared. In comparison to
> >> Niv's original proposal, it covers resource owner impersonation for all
> client categories.
> >>
> >> regards,
> >> Torsten.
> >>
> >> proposed text:
> >>
> >> response to the access request, either granting or denying access to the
> protected resources.
> >>
> >> consent, by transmitting the necessary requests programmatically, and
> >> simulating the flow against the authorization server. An
> >> suthorization server will be vulnerable to this threat, if it uses
> >> non-interactive authentication mechanisms or split the authorization flow
> across multiple pages.
> >>
> headers.
> >> In order to prevent such an attack, the authorization server may
> >> force a user interaction based on non-predictable input values as
> >> part of the user consent approval.
> >>
> >> The authorization server could combine password authentication and
> >> user consent in a single form, make use of CAPTCHAs or one-time secrets.
> >>
> >> Alternatively, the authorization server could notify the resource
> >> owner of any approval by appropriate means, e.g. text message or e-Mail.
> >>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 09:54:31 -0700

Hey Torsten,

> From: Lodderstedt, Torsten [mailto:[email-masked]]
> Sent: Thursday, August 18, 2011 12:52 AM
> To: Eran Hammer-Lahav; Torsten Lodderstedt; [email-masked]
> Subject: AW: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> understand the attack. Can you >provide a step-by-step scenario of how an
> attacker gains access?
> 
> I'm honestly surprised you do not understand the attack. The client simply
> uses screen scraping on the authorization flow and programmatically
> "presses" the right buttons. This obviously only works if the client can predict
> the form structure and expected input values.

That's not an attack but a description of capabilities. The attack example provided by Niv is a *classic* CSRF attack on the authorization endpoint.

> >Also, it is unlikely that any major provider is going to require CAPCHA as part
> of the authorization flow. >This is especially true in the case of using OAuth
> for login which has to be practically transparent (one >click). I would hate to
> recommend a solution that no one is going to take seriously.
> 
> This text has been proposed by 2 WG members (Niv and me), and reviewed
> by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of
> your strong assessment?

I don't understand the attack and how the proposed solution address it. I'm really happy for everyone else who got it, but I need more information to process it.

> The text proposes three classes of countermeasures (detect source, prevent
> using unpredictable input, inform resource owner and give her a chance to
> revoke). CAPTCHAs are one out of three examples given for unpredictable
> input. So I don't understand why your objection focuses on it.

True. But it was central in the list discussion and was promoted as strong defense to whatever this attack is. I think that CAPCHA is an impractical recommendation in general for the authorization endpoint. Can you point to any real world example of a large provider forcing CAPCHA on every login? That's what this amounts to.

> The selection
> of the appropriate countermeasure is the task of the service provider and it
> will most likely depend this on its capabilities, cost, user experience, and
> risk/impact associated with abuse. CAPTCHAs (and even one time
> passwords) might not be the choice for the average internet service. This will
> be completely different if OAuth is used to process payment transactions.

The text hints at a very dangerous attack vector of scripts doing 'really bad things'. But it doesn't show why this attack requires any kind of automation at all. If I am targeting just a small number of people, I can "automate" this by sending a message to a human who will break the CAPCHA and quickly return the link to approve access. The other measures either have the same properties, are just there to annoy the attacker, or provide some kind of after the fact notice (when it is clearly too late to prevent damage).

> See above - I probably misunderstand the IETF process, but several people
> agreed with it and no one (except you) objected. Why do you hold it back?

"no one (except you)" is an interesting statement... :-)

This is not a process issue. New text has been proposed with the support of a few working group members. The working group has been largely silent about it (and the review you referenced above was done off list). I have read the new text and did not understand it, therefore, could not edit the text as I have done with every other proposed language.

No new draft will be published until we resolve all open issues, which is exactly what I have stated above. To make it clearer:

I am keeping this proposed text out of *my* working draft for -21 until the working group discusses the text further and addresses the issues I have raised about the text as a working group member (technical issues) and as an editor (clarity issues).

As for IETF process, all it takes is one objection to block text from being *automatically* added to the specification. I have not implied anywhere that I have made any decision (or have the authority to) with regard to this text, only that I'm holding it back until the issues are resolved. And IETF process does not require full agreement to solve issues which is the role of the chairs to resolve. In this case, we're nowhere near needing help from the chairs - just the assistance of the text authors to do their job and explain it.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 09:58:11 -0700

> Of Igor Faynberg
> Sent: Thursday, August 18, 2011 8:49 AM
> To: [email-masked]
> by 3 others (Phil, Tony,>Barry) and all agree with it.
> 
> Maybe my e-mail was lost, but I was and still am among those who have
> agreed with the text, as I am sure many others have

Fantastic! Now explain it to me.

> I see neither the reason nor the right of an editor to remove the text.

Nothing was *removed* - it wasn't even rejected. It is simply held back to allow additional discussion and it is clearly within the role of editor.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 10:01:04 -0700

I'd like to ask the chairs to open an issue for this.

I didn't realize how hyper sensitive this working group has become that every proposal being questioned needs a ticket to prove to people that they are not being dismissed. But since this is clearly the case, let's be pedantic and open an issue.

EHL

> Of Eran Hammer-Lahav
> Sent: Wednesday, August 17, 2011 10:58 PM
> To: Torsten Lodderstedt; [email-masked]
> of the authorization flow. This is especially true in the case of using OAuth for
> login which has to be practically transparent (one click). I would hate to
> > covered by the core spec. It directly aims at the trustworthiness of
> > the user consent, which in my opinion is one of the core principles of
> > A malicious client can exploit knowledge of the structure of this flow
> > in order to gain authorization without the resource owner's consent,
> > by transmitting the necessary requests programmatically, and
> > simulating the flow against the authorization server. An suthorization
> > authentication mechanisms or split the authorization flow across multiple
> pages.
> >
> > In order to prevent such an attack, the authorization server may force
> > a user interaction based on non-predictable input values as part of

---

From: Niv Steingarten <[email-masked]>
Date: Thu, 18 Aug 2011 20:15:30 +0300

(thanks for the typo correction)

Yes, the example I provided is a very lightweight one which does take
the form of CSRF, but it is only the simplest example of a family of
automated authorization flow attacks. Indeed, a nonce (or hidden
token, both serve the same purpose in this case) would be enough here.

If the client is not user-agent based, a full-fledged forgery of the
whole process is possible, one in which CORS and sandboxes have no
meaning. In a native client, unless some kind of human test is
performed, the whole flow could be spoofed. A CAPTCHA and/or password
entry are not bullet-proof, but they provide a steep obstacle for the
attacker. Another option would be, for example, to email the resource
owner an OTP, with the following message "The application [...]
requests access to [...]. Please use the number XXXX to allow it
access etc..." (similar to Google's and Facebook's two-step sign-in).

The first attack described in my previous message takes the form of
CSRF, while the above one may be bypassed by an attacker with the help
of some sort of clickjacking or similar. Eventually this threat
description is for a family of attacks which mimic the behavior of the
resource owner in order to gain access to protected resources, and
some possible countermeasures.

-- Niv

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 10:31:39 -0700

> Sent: Thursday, August 18, 2011 10:16 AM
> To: Eran Hammer-Lahav
> Yes, the example I provided is a very lightweight one which does take the
> form of CSRF, but it is only the simplest example of a family of automated
> authorization flow attacks. Indeed, a nonce (or hidden token, both serve the
> same purpose in this case) would be enough here.

Great. So we need to add explicit text about preventing CSRF attacks at the authorization endpoint.

> If the client is not user-agent based, a full-fledged forgery of the whole
> process is possible, one in which CORS and sandboxes have no meaning. In a
> native client, unless some kind of human test is performed, the whole flow
> could be spoofed.

Can you provide another example with the same level of detail as you provided below?

> A CAPTCHA and/or password entry are not bullet-proof,
> but they provide a steep obstacle for the attacker.

CAPTCHA and password entry are two completely difference measures and are rarely interchangeable. CAPTCHA does nothing more than increase the likelihood that the entity on the other side is a human. Any attack prevented by CAPTCHA must be one in which automation and speed are crucial. I still don't understand what it *solves*.

> Another option would be,
> for example, to email the resource owner an OTP, with the following
> message "The application [...] requests access to [...]. Please use the number
> XXXX to allow it access etc..." (similar to Google's and Facebook's two-step
> sign-in).

Two-factor authentication is good, but completely impractical for most web authorization scenario. You need to remember that the authorization page is used for both the initial grant, but also for delegated login (by far a more frequent use). An access token can be issued almost automatically if the client has been previously authorized.

> The first attack described in my previous message takes the form of CSRF,
> while the above one may be bypassed by an attacker with the help of some
> sort of clickjacking or similar. Eventually this threat description is for a family
> of attacks which mimic the behavior of the resource owner in order to gain
> access to protected resources, and some possible countermeasures.

I don't understand this "family of attacks".

EHL

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Aug 2011 13:33:45 -0400

> I'd like to ask the chairs to open an issue for this.

http://trac.tools.ietf.org/wg/oauth/trac/ticket/24

> I didn't realize how hyper sensitive this working group has become that every
> proposal being questioned needs a ticket to prove to people that they are not
> being dismissed.

It's OK: tickets are cheap, and I don't mind... and if it helps people
to know that discussions that aren't quickly resolved are being
tracked, then that's what the issue tracker is there for.  It makes
sure things don't get forgotten, and reminds people what to look more
closely at in the next doc rev.

Barry, as chair

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Aug 2011 13:48:13 -0400

> Great. So we need to add explicit text about preventing CSRF attacks at the

General comment, not for this issue alone (and not specifically to the
folks conversing here):

There are a great many things we can say about threats and attacks,
which is why we have the threats document by Torsten, et al.  I'm
generally in favour of putting more security considerations into the
base document to describe threats that implementors need to be
concerned about, and well-crafted text that the editors can drop in is
a good thing.

That said, the reason we decided to put "highlights" into the base
doc's Security Considerations section, and then refer to the larger
document for more details and a more complete threat analysis is that
we wanted to strike a balance, keep the base doc for protocol details,
and leave the threat descriptions in the base doc as general threat
*classes*.

As we debate the various attack descriptions and mitigations that we
might like to add, please keep that balance in mind, and think
carefully about whether the details of *this specific* attack should
go into this document, or whether we just need to cover the general
class of threats here and put the details of this attack into
draft-ietf-oauth-v2-threatmodel.

Otherwise, we might eventually merge the entire threat analysis
document into the base, one paragraph at a time.

Barry, as chair

---

From: Niv Steingarten <[email-masked]>
Date: Thu, 18 Aug 2011 21:08:09 +0300

> Can you provide another example with the same level of detail as you provided below?

The malicious client sends a request to the authorization endpoint
with the appropriate parameters, and in return receives the markup of
the web-page which should be displayed to the user in order to get
consent. In addition, since the request is launched not via a
sandboxed user-agent, the client also has access to any 'Set-Cookie'
HTTP headers.

Instead of displaying the page to the user, the client extracts the
web-form data (including the hidden nonce/token) which would be
submitted when 'Allow' is clicked. It then forges the appropriate POST
request with the cookies, form data and referrer, and dispatches it,
to finally receive an access token/authorization code in the
redirection.

> CAPTCHA and password entry are two completely difference measures and are rarely interchangeable. CAPTCHA does nothing more than increase the likelihood that the entity on the other side is a human…

CAPTCHAs are used for human testing and passwords for identity
testing, but in this case they both serve the same purpose of
decreasing the likelihood that the flow is automated.

> Two-factor authentication is good, but completely impractical for most web authorization scenario. You need to remember that the authorization page is used for both the initial grant, but also for…

You're right, sometimes there's a trade-off between better security
and user experience. I think it should eventually be up to the
implementer to choose what is right for their applications' security
requirements. I think it is in the scope of the specification to bring
this issue up for developers to consider.

> I don't understand this "family of attacks".

I don't know how to put it any differently than I already have; simply
a class of attacks (the three scenarios described in this thread are
examples thereof) in which a malicious client takes the role of both
the client and the resource owner.

-- Niv

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 11:17:46 -0700

> Sent: Thursday, August 18, 2011 11:08 AM
> To: Eran Hammer-Lahav
> The malicious client sends a request to the authorization endpoint with the
> appropriate parameters, and in return receives the markup of the web-page
> which should be displayed to the user in order to get consent. In addition,
> since the request is launched not via a sandboxed user-agent, the client also
> has access to any 'Set-Cookie'
> HTTP headers.
> 
> Instead of displaying the page to the user, the client extracts the web-form
> data (including the hidden nonce/token) which would be submitted when
> 'Allow' is clicked. It then forges the appropriate POST request with the
> cookies, form data and referrer, and dispatches it,

SCENE MISSING [1]

> to finally receive an access token/authorization code in the redirection.

You skipped the best part!

What do you mean by "dispatches it"? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal "fixes" the first half, but not what kind of attack is happening in the second half.

EHL

[1] http://www.ibras.dk/montypython/episode34.htm

---

From: Niv Steingarten <[email-masked]>
Date: Thu, 18 Aug 2011 22:11:59 +0300

> What do you mean by "dispatches it"? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal "fixes" the first half, but not what kind of atta…

I might have accidentally skipped the part where the user is already
logged in at the authorization endpoint, so no log-in is required but
rather just allowing/denying access (correction: the first request is
sent using an HTTP framework/WebKit, so no access to cookies). Once it
extracts the data from the web-form, the client has all the
information it needs in order to create an HTTP request and launch it
using the same HTTP framework/WebKit, simulating the "Allow" button.

> [1] http://www.ibras.dk/montypython/episode34.htm

+1 for more Monty Python references.

-- Niv

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 12:19:48 -0700

> Sent: Thursday, August 18, 2011 12:12 PM
> To: Eran Hammer-Lahav
> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
> >> <[email-masked]>
> >> wrote:
> >> >
> >> >
> >> > Can you provide another example with the same level of detail as
> >> > you
> >> provided below?
> >>
> >> submitted when 'Allow' is clicked. It then forges the appropriate
> >> POST request with the cookies, form data and referrer, and dispatches
> >> it,
> >
> > SCENE MISSING [1]
> >
> > What do you mean by "dispatches it"? How is the resource owner tricked
> or abused to grant authorization unknowingly? I understand how your
> proposal "fixes" the first half, but not what kind of attack is happening in the
> second half.
> >
> 
> I might have accidentally skipped the part where the user is already logged in
> at the authorization endpoint, so no log-in is required but rather just
> allowing/denying access (correction: the first request is sent using an HTTP
> framework/WebKit, so no access to cookies). Once it extracts the data from
> the web-form, the client has all the information it needs in order to create an
> HTTP request 

No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call.

> and launch it using the same HTTP framework/WebKit,
> simulating the "Allow" button.

This is still just a CSRF attack.

In order to automate the approval action, they attacker has to get the user-agent (embedded or not) to make a cross site request which will include some session state (cookies or otherwise). If the authorization page is CSRF protected, they attacker will not be able to construct such a link.

The nature of the client does not matter. In either case, the client has to gain access somehow to the authorization server state stored in the browser.

EHL

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 18 Aug 2011 12:26:46 -0700 (PDT)

This is, in my opinion, another style of CSRF.  I the attacker present your browser (user agent) with a link, and your browser presents a credential automatically to the token endpoint, which automatically issues a token to be given back to me?  That's a classic CSRF, how to fix it is interesting.  I'm of the opinion that the user *should* be pesented with some UI at that point so they can make an informed choice about issuing a credential.  Not everyone agrees with me though (mostly business folks that want to avoid user interaction because it's too scary .... and somehow informing the user what they are doign is a bad thing).

-bill

________________________________
From: Niv Steingarten <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Thursday, August 18, 2011 12:11 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

-- Niv

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 12:30:28 -0700

We know how to fix CSRF attacks on form submission which this is. The UI questions about more about legitimate client interaction and how informed a user should be.

EHL

From: William J. Mills [mailto:[email-masked]]
Sent: Thursday, August 18, 2011 12:27 PM
To: Niv Steingarten; Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

-bill

________________________________
From: Niv Steingarten <[email-masked]<mailto:[email-masked]>>
To: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 18, 2011 12:11 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
>> From: Niv Steingarten [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: Torsten Lodderstedt; [email-masked]<mailto:[email-masked]>
>> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
>> wrote:
>> >
>> >
>> >> From: Niv Steingarten [mailto:[email-masked]<mailto:[email-masked]>]
>> >> Cc: Torsten Lodderstedt; [email-masked]<mailto:[email-masked]>

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

---

From: Niv Steingarten <[email-masked]>
Date: Thu, 18 Aug 2011 23:04:07 +0300

> No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call.

That's what I said -- "no access to cookies". But since both requests
(the one requesting the auth endpoint and the one simulating the
"allow") are sent from the same user-agent, the cookies are handled by
the user-agent itself. The client just POSTs the request with the
appropriate parameters to the action endpoint of the form.

> This is still just a CSRF attack.

I think you may be right. I still believe this particular style of
attack on the authorization server is worth mentioning, be it in its
own separate section or under the existing CSRF section (as you
suggested).

-- Niv

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 14:13:35 -0700

> Sent: Thursday, August 18, 2011 1:04 PM
> To: Eran Hammer-Lahav
> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
> >> <[email-masked]>
> >> wrote:
> >> >
> >> >
> >> >> with the appropriate parameters, and in return receives the markup
> >> >> of the web-page which should be displayed to the user in order to
> >> >> get consent. In addition, since the request is launched not via a
> >> >> Instead of displaying the page to the user, the client extracts
> >> >> the web-form data (including the hidden nonce/token) which would
> >> >> be submitted when 'Allow' is clicked. It then forges the
> >> >> appropriate POST request with the cookies, form data and referrer,
> >> >> and dispatches it,
> >> >
> >> > SCENE MISSING [1]
> >> >
> >> proposal "fixes" the first half, but not what kind of attack is
> >> happening in the second half.
> >> >
> >>
> >> sent using an HTTP framework/WebKit, so no access to cookies). Once
> >> it extracts the data from the web-form, the client has all the
> >> information it needs in order to create an HTTP request
> >
> That's what I said -- "no access to cookies".

You only said that about the first request.

> But since both requests (the one
> requesting the auth endpoint and the one simulating the
> "allow") are sent from the same user-agent, the cookies are handled by the
> user-agent itself. The client just POSTs the request with the appropriate
> parameters to the action endpoint of the form.

That's not exactly right.

This entire attack is based on:

1. The presence of some session cookie or other user-agent state to bypass active authentication, and
2. The ability of the malicious client to make CSS calls using #1.

Everything else is a red herring because the ability to automate this attack and make it more powerful is completely beside the point. If you deploy an effective CSRF protection, everything else is a non-issue.

This is why the client type does not matter when it comes to not using CORS. The authorization server MUST NOT allow CSS calls on the authorization endpoint because that's the actual attack you described - using local state (session cookie) to make a CSS call. If the client makes direct calls to the authorization endpoint, it cannot impersonate the resource owner.

> >> and launch it using the same HTTP framework/WebKit, simulating the
> >> "Allow" button.
> >
> I think you may be right. I still believe this particular style of attack on the
> authorization server is worth mentioning, be it in its own separate section or
> under the existing CSRF section (as you suggested).

This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit.

I don't see any reason to include this new text based on this threat analysis.

However, this doesn't mean this discussion wasn't useful. We did identify the need to explicitly discuss CSRF attacks on the authorization endpoint. We need to explicitly separate the two target of CSRF attacks (client, server) because while the solution is the same, the implementation is very different (due to the use of redirections in one).

EHL

---

From: Niv Steingarten <[email-masked]>
Date: Fri, 19 Aug 2011 02:33:12 +0300

How about add something like this as the second paragraph in 10.12:

   The authorization server SHOULD employ measures to prevent CSRF
   attacks on the authorization endpoint. A non-guessable token SHOULD
   be included in requests and form submissions within the authorization
   server's internal authorization flow. This token MUST NOT be
   accessible by the client. In addition, the authorization server may
   make use of HTTP referrer headers in order to verify the origin of
   requests made during the authorization flow.

In addition, I think that:

   The "state" request parameter SHOULD be used to mitigate against CSRF
   attacks, ...

should be changed to:

   The "state" request parameter SHOULD be used to mitigate against CSRF
   attacks against the client's redirection URI, ...

so that the fact that the 'state' parameter protects against CSRF
attacks on the *client*, as opposed to CSRF on the *authorization
server*, is made explicit.

-- Niv

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 18 Aug 2011 16:46:55 -0700 (PDT)

I proposed text that I think is more complete in a previous message...

Sent: Thursday, August 18, 2011 4:33 PM

should be changed to:

-- Niv

---

From: Niv Steingarten <[email-masked]>
Date: Fri, 19 Aug 2011 04:06:38 +0300

I suppose you're talking about this:
http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html

It is indeed more complete w.r.t. CSRF attacks on the client's
redirection URI, but it does not address CSRF attacks on the
authorization server.

I believe something along the lines of the text I proposed could be
combined in whichever text is eventually decided upon.

-- Niv

On Fri, Aug 19, 2011 at 02:46, William J. Mills <[email-masked]> wrote:
>>> > No - the attacker does not have access to the session cookie. It still
>>> > needs
>>> to find a way to make a CSS call.
>>> >
>>>
>>> the
>> Everything else is a red herring because the ability to automate this
>> attack and make it more powerful is completely beside the point. If you
>> deploy an effective CSRF protection, everything else is a non-issue.
>>
>> This is why the client type does not matter when it comes to not using
>> CORS. The authorization server MUST NOT allow CSS calls on the authorization
>> endpoint because that's the actual attack you described - using local state
>> (session cookie) to make a CSS call. If the client makes direct calls to the
>> authorization endpoint, it cannot impersonate the resource owner.
>>
>> This is not a style of attack but techniques to enhance other exploits, in
>> this case, CSRF. If you lack CSRF protection, then yes, lack of resource
>> owner forced interaction will make it easier to execute. But that's just a
>> tiny speed bump considering the actual exploit.
>>
>> However, this doesn't mean this discussion wasn't useful. We did identify
>> the need to explicitly discuss CSRF attacks on the authorization endpoint.
>> We need to explicitly separate the two target of CSRF attacks (client,
>> server) because while the solution is the same, the implementation is very
>> different (due to the use of redirections in one).
>>
>> EHL
>>
>>
>>
>>
>>
>>

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 18 Aug 2011 21:21:19 -0700 (PDT)

While I agree in principal, I think there are real world use cases that make this more complicated.  If, for example, a user has previously approved access to a particular endpoint then we might be willing to re-issue credentials without user interaction.  I don't know how we capture this in the right way in the spec.

________________________________
From: Niv Steingarten <[email-masked]>
To: William J. Mills <[email-masked]>
Cc: Eran Hammer-Lahav <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Thursday, August 18, 2011 6:06 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

-- Niv

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 22:05:16 -0700

To reiterate Berry's earlier point, we are not going to cover everything in the v2 spec. We need to agree on new language for the CSRF section, and add the potential attacks on both endpoints. But beyond that, it will probably be best to add it to the threat model document - but I will leave that up to the editors of that document.

EHL

From: William J. Mills [mailto:[email-masked]]
Sent: Thursday, August 18, 2011 9:21 PM
To: Niv Steingarten
Cc: Eran Hammer-Lahav; [email-masked]
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

________________________________
From: Niv Steingarten <[email-masked]<mailto:[email-masked]>>
To: William J. Mills <[email-masked]<mailto:[email-masked]>>
Cc: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 18, 2011 6:06 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

-- Niv

On Fri, Aug 19, 2011 at 02:46, William J. Mills <[email-masked]<mailto:[email-masked]>> wrote:
> On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
> wrote:
>>
>>
>>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>> >
>>> >
>>> >> <[email-masked]<mailto:[email-masked]>>
>>> >> wrote:
>>> >> >
>>> >> >
>>> >> >> <[email-masked]<mailto:[email-masked]>>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 21 Aug 2011 19:59:12 +0200

Hi Eran,
> However, this doesn't mean this discussion wasn't useful. We did identify the need to explicitly discuss CSRF attacks on the authorization endpoint. We need to explicitly separate the two target of…

I agree, we should explicitely document these two variants of CSRF 
(client, authz server). But I suspect it's not only CSRF we are talking 
about in this thread - at least not textbook CSRF. Let me explain my 
thoughts:

As far as I understood, in a textbook CSRF attack the attacker would 
create his own requests in order to abuse a user's session. This can be 
prevented by utilizing standard CSRF coutermeasures (page token, nounce, 
signature as parameter on every request URL), which bind URLs to a 
certain session.

But why should the attacker create requests et all? All he needs is 
already provided by the authorization server themselves. The malicious 
client can download the HTML pages comprising the authorization flow 
from the authz server and use the embedded URLs to issue the requests 
which normaly would have been issued by the resource owner herself 
(using the use agent indeed). It's more or less the push on a "I agree" 
button we are talking about. The authorization server may add a page 
token to the respective form URL. But it does not matter since the 
client just uses the authz server manufactured URL to post the form.

So let's assume the attacker has to programmatically handle HTML forms 
the authorization server delivers to the user agent. As you correctly 
pointed out, the pre-requisite for such an attack to succeed is that the 
resource owner must be authenticated somehow, e.g. based on a session 
cookie. Which also means, we are talking about clients running on the 
victim's device, within the user agent or as native app.

I see the following possible scenarios:

1) external system browser - The app could utilize an existing session 
within the system browser on the victim's device. It could then remote 
control a browser window, e.g. using low-level operating system messages 
("send mouse click") or component techniques such as ActiveX. There are 
tools available to create macros which automatically control and obtain 
data from such applications. So this should be feasible.

2) internal browser (cross-browser cookies) - If the authorization 
server uses cross-browser cookie techniques, such as flash cookies, the 
attacker could instantiate an internal (invisible) browser and try to 
utilize a session associated with such a cookie. I assume controlling 
such a browser instance will be even simpler then in (1).

3) internal browser (silent authz flow) - This is a scenario where the 
attacker is unable to abuse an existing session on the device. It could 
instead create an internal browser and perform an authorization flow 
with the resource owner for one particular scope. Using the same browser 
instance and based on the cookies obtained in the first run, it could 
silently perform additional authorization flows for other scopes.

4) internal browser (non-interactive authentication methods) - There are 
authentication methods available w/o the need for user-interaction, for 
examples SIM card authentication or certificate-based authentication. 
The attacker could utilize an internal, invisible browser instance in 
combination with such an authentication method in order to perform the 
authorization process.

I'm not sure whether the scenarios described above can be classified as 
CSRF.

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 28 Aug 2011 19:15:34 +0200

no comments?

Am 21.08.2011 19:59, schrieb Torsten Lodderstedt:
>>> attack on the
>> This is not a style of attack but techniques to enhance other 
>> exploits, in this case, CSRF. If you lack CSRF protection, then yes, 
>> lack of resource owner forced interaction will make it easier to 
>> execute. But that's just a tiny speed bump considering the actual 
>> exploit.
>>
>> However, this doesn't mean this discussion wasn't useful. We did 
>> identify the need to explicitly discuss CSRF attacks on the 
>> authorization endpoint. We need to explicitly separate the two target 
>> of CSRF attacks (client, server) because while the solution is the 
>> same, the implementation is very different (due to the use of 
>> redirections in one).
>
> (client, authz server). But I suspect it's not only CSRF we are 
> talking about in this thread - at least not textbook CSRF. Let me 
> explain my thoughts:
>
> create his own requests in order to abuse a user's session. This can 
> be prevented by utilizing standard CSRF coutermeasures (page token, 
> nounce, signature as parameter on every request URL), which bind URLs 
> to a certain session.
>
> (using the use agent indeed). It's more or less the push on a "I 
> agree" button we are talking about. The authorization server may add a 
> page token to the respective form URL. But it does not matter since 
> the client just uses the authz server manufactured URL to post the form.
>
> pointed out, the pre-requisite for such an attack to succeed is that 
> the resource owner must be authenticated somehow, e.g. based on a 
> session cookie. Which also means, we are talking about clients running 
> on the victim's device, within the user agent or as native app.
>
> control a browser window, e.g. using low-level operating system 
> messages ("send mouse click") or component techniques such as ActiveX. 
> There are tools available to create macros which automatically control 
> and obtain data from such applications. So this should be feasible.
>
> server uses cross-browser cookie techniques, such as flash cookies, 
> the attacker could instantiate an internal (invisible) browser and try 
> to utilize a session associated with such a cookie. I assume 
> controlling such a browser instance will be even simpler then in (1).
>
> attacker is unable to abuse an existing session on the device. It 
> could instead create an internal browser and perform an authorization 
> flow with the resource owner for one particular scope. Using the same 
> browser instance and based on the cookies obtained in the first run, 
> it could silently perform additional authorization flows for other 
> scopes.
>
> 4) internal browser (non-interactive authentication methods) - There 
> are authentication methods available w/o the need for 
> user-interaction, for examples SIM card authentication or 
> certificate-based authentication. The attacker could utilize an 
> internal, invisible browser instance in combination with such an 
> authentication method in order to perform the authorization process.
>
> I'm not sure whether the scenarios described above can be classified 
> as CSRF.
>
> regards,
> Torsten.