Subject: [OAUTH-WG] Device Flow - Session Fixation?

From: Allen Tom <[email-masked]>
Date: Thu, 01 Apr 2010 19:54:05 -0700

Longtime fans of Oauth will remember the Session Fixation security issue we
had last year.

The Device Flow specified in the OAuth2 draft seems to have the same issue.

To illustrate:

Imagine that a Photos Hosting Service supports OAuth2, and supports the
Device Flow for Internet enabled picture frames. These devices have screens,
but no browser, and no keyboard.

An Attacker sets up his picture frame, and is instructed to use a browser on
a separate device to authorize the picture frame. However, rather than
entering oauth_verification_url on his own browser he instead socially
engineers a victim to do it. (this is essentially the same thing as
phishing)

The Attacker IMs  or emails the victim the link to the Auth url  depending
on how the Auth Flow is implemented, the attacker might even be able to
construct the auth url with the oauth_user_code appended as a query
parameter. If the victim is persuaded to click the link and approve the auth
request, the Attacker will then have access to the victim¹s photos.

Again, this is social engineering, and the victim has to be persuaded to
click on an untrusted link and to click ³approve² on a strange auth screen.
That being said, this sort of thing happens pretty often.

In Oauth 1.0a and in WRAP, this attack is not possible. In both WRAP and in
Oauth 1.0a, the victim¹s browser is issued a verification code which somehow
must be passed back to the attacker in order for the attacker to access the
victim¹s private data. While the Web Server and Web Client flows both have
the verification_code to prevent the session fixation attack, the Device
Flow does not.

Is this a problem?

Allen

---

From: Eric Sachs <[email-masked]>
Date: Thu, 1 Apr 2010 20:05:07 -0700

Here is the note I sent a few weeks ago where we also noted the potential
session fixation attack.  However as we noted, we are still willing to start
with this profile and later work on where the user has to enter a code into
the device.

---------- Forwarded message ----------
From: Eric Sachs <[email-masked]>
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profile
To: Brent Goldman <[email-masked]>
Cc: "OAuth WG ([email-masked])" <[email-masked]>

Google has a similar requirement to move these types of devices to
OAuth/WRAP and away from our older "ClientLogin" protocol where the user is
prompted for their username/password.  The proposed profile looks fine, but
we are a few weeks from being able to do specific work on it, so we may have
more feedback at that time.

If the device can accept some user input, then there are some security
advantages to requiring the user to get the code from their computer and
then enter it into the device.  In particular, it makes it easier to protect
against a DOS attack targeted at the service-provider to request a large #
of codes.  That method also reduces the risk of a phishing/session-fixation
type attack.  However we agree that some profile is needed for devices with
no user input.  We also expect it will be easier to get these device vendors
to use a common industry technique, so we are fine with prioritizing our
support for this profile.  Longer term the community could define a profile
where the code is displayed on the computer.

On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman <[email-masked]> wrote:

> Over the past couple days, Luke Shepard, David Recordon, and I have been
> brainstorming an OAuth profile for standardizing the flow that devices such
> as game consoles and entertainment centers use to hook up with services such
> as Netflix and iTunes. The basic flow is that a device can gain
> authorization by directing the user to visit a URL on their computer and to
> enter a verification code copied from the device's screen.
>
> A draft spec is attached to this email. Any thoughts or feedback?
>
> Note: this is one of the many profiles going into the OAuth 2.0 draft that
> David is writing (http://daveman692.livejournal.com/349384.html).
>
> -Brent
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Brent Goldman <[email-masked]>
Date: Thu, 1 Apr 2010 21:06:26 -0700

Isn't there a similar attack for the reverse protocol? The attacker would socially engineer the user to give them the post-auth verification code displayed on the computer. This gives the attacker access to everything.

We could make this more strict by having both a device code and verification code. That is, have the user enter the device code into the computer, which would produce a verification code that needs to be entered back into the device. But this is susceptible to the same attack: after visiting the link sent by the attacker, and clicking "approve on a strange auth screen", the user would have to send the verification code back to the attacker. This is slightly better in that for an attack to be successful, the user has to communicate with the attacker twice instead of once.

I can't really think of a good way to eliminate the attack entirely, though.

-Brent

On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote:

Here is the note I sent a few weeks ago where we also noted the potential session fixation attack.  However as we noted, we are still willing to start with this profile and later work on where the user has to enter a code into the device.

---------- Forwarded message ----------
From: Eric Sachs <[email-masked]<mailto:[email-masked]>>
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profile
To: Brent Goldman <[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>

Google has a similar requirement to move these types of devices to OAuth/WRAP and away from our older "ClientLogin" protocol where the user is prompted for their username/password.  The proposed profile looks fine, but we are a few weeks from being able to do specific work on it, so we may have more feedback at that time.

If the device can accept some user input, then there are some security advantages to requiring the user to get the code from their computer and then enter it into the device.  In particular, it makes it easier to protect against a DOS attack targeted at the service-provider to request a large # of codes.  That method also reduces the risk of a phishing/session-fixation type attack.  However we agree that some profile is needed for devices with no user input.  We also expect it will be easier to get these device vendors to use a common industry technique, so we are fine with prioritizing our support for this profile.  Longer term the community could define a profile where the code is displayed on the computer.

On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman <[email-masked]<mailto:[email-masked]>> wrote:
Over the past couple days, Luke Shepard, David Recordon, and I have been brainstorming an OAuth profile for standardizing the flow that devices such as game consoles and entertainment centers use to hook up with services such as Netflix and iTunes. The basic flow is that a device can gain authorization by directing the user to visit a URL on their computer and to enter a verification code copied from the device's screen.

Note: this is one of the many profiles going into the OAuth 2.0 draft that David is writing (http://daveman692.livejournal.com/349384.html).

-Brent

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

<ATT00001..txt>

---

From: Allen Tom <[email-masked]>
Date: Thu, 01 Apr 2010 21:18:11 -0700

Perhaps the best (usable) solution would be:

1. The approval screen must clearly indicate to the user that they should
only be seeing that screen if they are trying to provision a device. The
user should not have clicked on a link to get to the screen
2. The Auth server should also check for the presence of an HTTP Referrer.
There should not be a referrer, since the user should not have clicked on
anything to have landed on the screen
3. The Auth server must not enable ³auto approval² for the device flow.
Meaning that the user must click through the approval screen, even if the
user had previously authorized the same client_id previously

Allen

On 4/1/10 9:06 PM, "Brent Goldman" <[email-masked]> wrote:

> Isn't there a similar attack for the reverse protocol? The attacker would
> socially engineer the user to give them the post-auth verification code
> displayed on the computer. This gives the attacker access to everything.
> 
> We could make this more strict by having both a device code and verification
> code. That is, have the user enter the device code into the computer, which
> would produce a verification code that needs to be entered back into the
> device. But this is susceptible to the same attack: after visiting the link
> sent by the attacker, and clicking "approve on a strange auth screen", the
> user would have to send the verification code back to the attacker. This is
> slightly better in that for an attack to be successful, the user has to
> communicate with the attacker twice instead of once.
> 
>> Google has a similar requirement to move these types of devices to OAuth/WRAP
>> and away from our older "ClientLogin" protocol where the user is prompted for
>> their username/password.  The proposed profile looks fine, but we are a few
>> weeks from being able to do specific work on it, so we may have more feedback
>> at that time.
>> 
>> advantages to requiring the user to get the code from their computer and then
>> enter it into the device.  In particular, it makes it easier to protect
>> against a DOS attack targeted at the service-provider to request a large # of
>> codes.  That method also reduces the risk of a phishing/session-fixation type
>> attack.  However we agree that some profile is needed for devices with no
>> user input.  We also expect it will be easier to get these device vendors to
>> use a common industry technique, so we are fine with prioritizing our support
>> for this profile.  Longer term the community could define a profile where the
>> code is displayed on the computer.
>>

---

From: Brent Goldman <[email-masked]>
Date: Thu, 1 Apr 2010 21:46:13 -0700

Those 3 sound great. Add in clickjacking protection and I think we're set.

-Brent

On Apr 1, 2010, at 9:18 PM, Allen Tom wrote:

 1.  The approval screen must clearly indicate to the user that they should only be seeing that screen if they are trying to provision a device. The user should not have clicked on a link to get to the screen
 2.  The Auth server should also check for the presence of an HTTP Referrer. There should not be a referrer, since the user should not have clicked on anything to have landed on the screen
 3.  The Auth server must not enable “auto approval” for the device flow. Meaning that the user must click through the approval screen, even if the user had previously authorized the same client_id previously

Allen

On 4/1/10 9:06 PM, "Brent Goldman" <[email-masked]<x-msg://37/[email-masked]>> wrote:

-Brent

---------- Forwarded message ----------
From: Eric Sachs <[email-masked]<x-msg://37/[email-masked]>>
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profile
To: Brent Goldman <[email-masked]<x-msg://37/[email-masked]>>
Cc: "OAuth WG ([email-masked])<x-msg://37/[email-masked])>" <[email-masked]<x-msg://37/[email-masked]>>

On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman <[email-masked]<x-msg://37/[email-masked]>> wrote:
Over the past couple days, Luke Shepard, David Recordon, and I have been brainstorming an OAuth profile for standardizing the flow that devices such as game consoles and entertainment centers use to hook up with services such as Netflix and iTunes. The basic flow is that a device can gain authorization by directing the user to visit a URL on their computer and to enter a verification code copied from the device's screen.

-Brent

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

<ATT00001..txt>

---

From: Brian Eaton <[email-masked]>
Date: Fri, 2 Apr 2010 08:53:46 -0700

On Thu, Apr 1, 2010 at 9:18 PM, Allen Tom <[email-masked]> wrote:
> The Auth server should also check for the presence of an HTTP Referrer.

I don't think this one is going to work in practice.  Manufacturers
may not point users directly at the OAuth approval page.  They are
going to end up pointing users to something shorter, e.g.
"http://google.samsung.com".  That web site will then redirect the
user to the right approval page.

Otherwise we end up needing to tell users to manually type-in long,
complex urls like
https://www.google.com/accounts/OAuthAuthorize?client_id=1238979.

Cheers,
Brian

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 2 Apr 2010 10:20:25 -0700

> user to the right approval page.

Then maybe the approval page can white list known referrers?

With the device flow the user normally has to go to a page and then
type in a code at that page. If the approval page accepts only HTTP POST
and also prevents cross site posting then session fixation is not that
easy anymore. Now the attacker has to convince the user to follow
a link *and* type a code at that page.

Marius

---

From: Brent Goldman <[email-masked]>
Date: Fri, 2 Apr 2010 16:51:52 -0700

Even if the auth server is using redirects for user simplicity, it can still comply with the referer-checking requirement by having the simple URL (http://google.samsung.com) pass its referer as a GET param to the actual complex URL (https://www.google.com/accounts/OAuthAuthorize?client_id=1238979). The actual server should first verify that the simple URL which redirected to id (the proxy referer) is trusted, and if so, additionally check the original referer from the GET param. Otherwise, the authorization should fail.

Should this be added to the spec, or is this just an implementation detail?

-Brent

---

From: Brent Goldman <[email-masked]>
Date: Fri, 2 Apr 2010 16:52:37 -0700

+1 to accepting only HTTP POST and preventing cross-site posting.