Re: [OAUTH-WG] open redirect in rfc6749

[Hans Zandbelt]

+1, Antonio and John convinced me that this is not limited to a 
registration curation problem although that is where the problems starts 
as Phil points out (and as much as I'd like it to stay there).


There are and will be consumer OPs (like Google) that have no means to 
do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security 
consideration for OPs that have no policy in place to allow only trusted 
clients to register would be a good thing.


The advice for those OPs would be to not send errors back to untrusted 
clients or do it only after explicit user interaction.


Hans.

On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote:

I think a security considerations addendum makes sense.

regards,
Torsten.


 Ursprüngliche Nachricht 
Von: "Richer, Justin P."
Datum:15.09.2014 23:15 (GMT+01:00)
An: Antonio Sanso
Cc: oauth@ietf.org
Betreff: Re: [OAUTH-WG] open redirect in rfc6749

As we discussed before: This isn't really an open redirection in the
classical sense since nothing gets leaked and the URI is tied back to a
known (albeit malicious) client registration. And I thought the clear
solution was to have an AS not automatically redirect to an untrusted
client in error conditions, where "untrusted" is defined by the AS with
guidance. If anything this is a security considerations addendum.

-- Justin

On Sep 15, 2014, at 4:52 PM, Antonio Sanso  wrote:

 > The problem is that a malicious client can register a malicious
redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1
does the rest (as previously discussed)
 >
 > regards
 >
 > antonio
 >
 > On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:
 >
 >> If a server accepts a URL from a client to be used as a redirect
that the server doesn’t recognize or is not registered, that is an open
redirect.
 >>
 >> The specification does no allow open-redirects, it considers this a
mis-configuration.
 >>
 >> Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
 >>
 >> Phil
 >>
 >> @independentid
 >> www.independentid.com
 >> phil.h...@oracle.com
 >>
 >>
 >>
 >> On Sep 15, 2014, at 1:00 PM, John Bradley  wrote:
 >>
 >>> There may be a problem with semantics in this discussion.
 >>>
 >>> There is a redirect performed by athe authorization endpoint to a
fixed uri that is pre registered with the authorization server without
user prompting.
 >>>
 >>> That probably doesn't fit the strict definition of a open redirector.
 >>>
 >>> It may however create similar security issues in situations with
relatively open registration of clients.
 >>>
 >>> The largest issues are that the browser might leak information
across the redirect in the fragment or referrer.  That has been used in
attacks against Facebook in the past.
 >>>
 >>> This is no where near the end of the world,  however we need to
look at the security considerations and see if we can provide better
advice to implementors.  In some cases returning a error to the browser
may be best.
 >>>
 >>> I don't think we need to go so far as not returning any error to
the client under any circumstance.
 >>>
 >>> John B.
 >>>
 >>> Sent from my iPhone
 >>>
  On Sep 15, 2014, at 4:41 PM, Phil Hunt  wrote:
 
  Simply not true.
 
  Phil
 
  @independentid
  www.independentid.com
  phil.h...@oracle.com
 
 
 
 > On Sep 15, 2014, at 12:10 PM, Antonio Sanso  wrote:
 >
 > hi *,
 >
 > my understanding is that there is a rough consensus that if an
OAuth Provider follows rfc6749 verbatim will end up having an open
redirector.
 > My next question would be now, is there anything we can do to
raise some awareness about this issue?
 >
 > regards
 >
 > antonio
 >
 >> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt
 wrote:
 >>
 >> I am convinced about the issue in the use case Antonio provided
but I hope not to close the door on returning errors to known and
trusted clients. Not sure anymore if that's possible though because the
distinction can't be "registered"...
 >>
 >> Hans.
 >>
 >>> On 9/4/14, 3:01 PM, Antonio Sanso wrote:
 >>> hi Bill
  On Sep 4, 2014, at 2:52 PM, Bill Burke  wrote:
 
  FWIW, Antonio convinced me and I'm going to change this in our
IDM project.  Thanks Antonio.  What convinced me was that the user is
probably expecting a login screen.  Since there is this expectation, it
might make it a little easier for the attacker to convince the user that
a spoofed login screen is real.  I know this issue can only happen with
unrestricted registration, but, IMO, this proposed change doesn't really
have much of an effect on usability and is even backward compatible with
the current RFC.
 
  Wouldn't it better though to never do a redirect on an invalid
request and just display an error page?
 >>>
 >>> thanks for sharing your thoughts :). Display an error 400 is
what Google does :)
 >>>
 >>> regards
 >>>
 >>> antonio
 >>

Re: [OAUTH-WG] open redirect in rfc6749

[Sergey Beryozkin]

Hi

I wonder, when we have a situation where any client, the malicious
clients, or good clients, all of them can easily register and provide
bad redirect URIs, intentionally or unintentionally, then does it imply
there's serious a weakness present somewhere else, in the
registration process for example ? Should the client registrations be
validated ?

Sergey


On 16/09/14 08:52, Hans Zandbelt wrote:

+1, Antonio and John convinced me that this is not limited to a
registration curation problem although that is where the problems starts
as Phil points out (and as much as I'd like it to stay there).

There are and will be consumer OPs (like Google) that have no means to
do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security
consideration for OPs that have no policy in place to allow only trusted
clients to register would be a good thing.

The advice for those OPs would be to not send errors back to untrusted
clients or do it only after explicit user interaction.

Hans.

On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote:

I think a security considerations addendum makes sense.

regards,
Torsten.


 Ursprüngliche Nachricht 
Von: "Richer, Justin P."
Datum:15.09.2014 23:15 (GMT+01:00)
An: Antonio Sanso
Cc: oauth@ietf.org
Betreff: Re: [OAUTH-WG] open redirect in rfc6749

As we discussed before: This isn't really an open redirection in the
classical sense since nothing gets leaked and the URI is tied back to a
known (albeit malicious) client registration. And I thought the clear
solution was to have an AS not automatically redirect to an untrusted
client in error conditions, where "untrusted" is defined by the AS with
guidance. If anything this is a security considerations addendum.

-- Justin

On Sep 15, 2014, at 4:52 PM, Antonio Sanso  wrote:

 > The problem is that a malicious client can register a malicious
redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1
does the rest (as previously discussed)
 >
 > regards
 >
 > antonio
 >
 > On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:
 >
 >> If a server accepts a URL from a client to be used as a redirect
that the server doesn’t recognize or is not registered, that is an open
redirect.
 >>
 >> The specification does no allow open-redirects, it considers this a
mis-configuration.
 >>
 >> Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
 >>
 >> Phil
 >>
 >> @independentid
 >> www.independentid.com
 >> phil.h...@oracle.com
 >>
 >>
 >>
 >> On Sep 15, 2014, at 1:00 PM, John Bradley  wrote:
 >>
 >>> There may be a problem with semantics in this discussion.
 >>>
 >>> There is a redirect performed by athe authorization endpoint to a
fixed uri that is pre registered with the authorization server without
user prompting.
 >>>
 >>> That probably doesn't fit the strict definition of a open
redirector.
 >>>
 >>> It may however create similar security issues in situations with
relatively open registration of clients.
 >>>
 >>> The largest issues are that the browser might leak information
across the redirect in the fragment or referrer.  That has been used in
attacks against Facebook in the past.
 >>>
 >>> This is no where near the end of the world,  however we need to
look at the security considerations and see if we can provide better
advice to implementors.  In some cases returning a error to the browser
may be best.
 >>>
 >>> I don't think we need to go so far as not returning any error to
the client under any circumstance.
 >>>
 >>> John B.
 >>>
 >>> Sent from my iPhone
 >>>
  On Sep 15, 2014, at 4:41 PM, Phil Hunt 
wrote:
 
  Simply not true.
 
  Phil
 
  @independentid
  www.independentid.com
  phil.h...@oracle.com
 
 
 
 > On Sep 15, 2014, at 12:10 PM, Antonio Sanso 
wrote:
 >
 > hi *,
 >
 > my understanding is that there is a rough consensus that if an
OAuth Provider follows rfc6749 verbatim will end up having an open
redirector.
 > My next question would be now, is there anything we can do to
raise some awareness about this issue?
 >
 > regards
 >
 > antonio
 >
 >> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt
 wrote:
 >>
 >> I am convinced about the issue in the use case Antonio provided
but I hope not to close the door on returning errors to known and
trusted clients. Not sure anymore if that's possible though because the
distinction can't be "registered"...
 >>
 >> Hans.
 >>
 >>> On 9/4/14, 3:01 PM, Antonio Sanso wrote:
 >>> hi Bill
  On Sep 4, 2014, at 2:52 PM, Bill Burke 
wrote:
 
  FWIW, Antonio convinced me and I'm going to change this in our
IDM project.  Thanks Antonio.  What convinced me was that the user is
probably expecting a login screen.  Since there is this expectation, it
might make it a little easier for the attacker to convince the user that
a spoofed login screen is real.  I know this issue can only happen with
unrestricted registration, but, IMO, this propos

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi Sergey

On Sep 16, 2014, at 10:44 AM, Sergey Beryozkin 
mailto:sberyoz...@gmail.com>> wrote:

Hi

I wonder, when we have a situation where any client, the malicious
clients, or good clients, all of them can easily register and provide
bad redirect URIs, intentionally or unintentionally, then does it imply
there's serious a weakness present somewhere else, in the
registration process for example ? Should the client registrations be
validated ?

as previously discussed is pretty fought to filter bad redirect uri specially 
for big OPs like Facebook/Google et al where all you need to have in order to 
create a new OAuth client is an email address (the registration process is 
self-service).

Justin proposed some mitigation though… (namely a client can gain ‘reputation’ 
with time)

regards

antonio


Sergey

On 16/09/14 08:52, Hans Zandbelt wrote:
+1, Antonio and John convinced me that this is not limited to a
registration curation problem although that is where the problems starts
as Phil points out (and as much as I'd like it to stay there).

There are and will be consumer OPs (like Google) that have no means to
do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security
consideration for OPs that have no policy in place to allow only trusted
clients to register would be a good thing.

The advice for those OPs would be to not send errors back to untrusted
clients or do it only after explicit user interaction.

Hans.

On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote:
I think a security considerations addendum makes sense.

regards,
Torsten.


 Ursprüngliche Nachricht 
Von: "Richer, Justin P."
Datum:15.09.2014 23:15 (GMT+01:00)
An: Antonio Sanso
Cc: oauth@ietf.org
Betreff: Re: [OAUTH-WG] open redirect in rfc6749

As we discussed before: This isn't really an open redirection in the
classical sense since nothing gets leaked and the URI is tied back to a
known (albeit malicious) client registration. And I thought the clear
solution was to have an AS not automatically redirect to an untrusted
client in error conditions, where "untrusted" is defined by the AS with
guidance. If anything this is a security considerations addendum.

-- Justin

On Sep 15, 2014, at 4:52 PM, Antonio Sanso 
mailto:asa...@adobe.com>> wrote:

> The problem is that a malicious client can register a malicious
redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1
does the rest (as previously discussed)
>
> regards
>
> antonio
>
> On Sep 15, 2014, at 10:43 PM, Phil Hunt 
> mailto:phil.h...@oracle.com>> wrote:
>
>> If a server accepts a URL from a client to be used as a redirect
that the server doesn’t recognize or is not registered, that is an open
redirect.
>>
>> The specification does no allow open-redirects, it considers this a
mis-configuration.
>>
>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>>
>>
>>
>> On Sep 15, 2014, at 1:00 PM, John Bradley 
>> mailto:ve7...@ve7jtb.com>> wrote:
>>
>>> There may be a problem with semantics in this discussion.
>>>
>>> There is a redirect performed by athe authorization endpoint to a
fixed uri that is pre registered with the authorization server without
user prompting.
>>>
>>> That probably doesn't fit the strict definition of a open
redirector.
>>>
>>> It may however create similar security issues in situations with
relatively open registration of clients.
>>>
>>> The largest issues are that the browser might leak information
across the redirect in the fragment or referrer.  That has been used in
attacks against Facebook in the past.
>>>
>>> This is no where near the end of the world,  however we need to
look at the security considerations and see if we can provide better
advice to implementors.  In some cases returning a error to the browser
may be best.
>>>
>>> I don't think we need to go so far as not returning any error to
the client under any circumstance.
>>>
>>> John B.
>>>
>>> Sent from my iPhone
>>>
 On Sep 15, 2014, at 4:41 PM, Phil Hunt 
 mailto:phil.h...@oracle.com>>
wrote:

 Simply not true.

 Phil

 @independentid
 www.independentid.com
 phil.h...@oracle.com



> On Sep 15, 2014, at 12:10 PM, Antonio Sanso 
> mailto:asa...@adobe.com>>
wrote:
>
> hi *,
>
> my understanding is that there is a rough consensus that if an
OAuth Provider follows rfc6749 verbatim will end up having an open
redirector.
> My next question would be now, is there anything we can do to
raise some awareness about this issue?
>
> regards
>
> antonio
>
>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt
mailto:hzandb...@pingidentity.com>> wrote:
>>
>> I am convinced about the issue in the use case Antonio provided
but I hope not to close the do

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

hi Phil.
On Sep 15, 2014, at 11:21 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:

So, let’s say you have a client that has “obtained” a client Id from a legit 
registered client.  How does the malicious client exploit the previously 
registered URL if the server only redirects to that URL?

These are the steps:

- the malicious client can registers a malicious url 
(attacker.com)
- the malicious client builds a malicious request to the AS 
(victim.com) that looks like 
http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

as per https://tools.ietf.org/html/rfc6749#section-4.1.2.1 the user is 
redirected to http://attacker.com (since the wrong parameter is the scope )

regards

antonio


Are you referring to the case Nat Sakimura previously raised where mobile app 
stores do not enforce custom URL registrations?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Sep 15, 2014, at 2:11 PM, Antonio Sanso  wrote:


On Sep 15, 2014, at 11:08 PM, Phil Hunt  wrote:

I’m not sure I understand why this is an OAuth protocol problem?

If you are starting with a false client with a false registration, everything 
down stream is likely invalid.

registration is not false. But the client can be a malicious one….



This seems like a registration curation (whitelisting) problem.

there is not way a whitelist can cover all the malicious uris..

regards

antonio


This is a bit like saying, how can I prove that the application on this 
jail-broken phone is legitimate?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Sep 15, 2014, at 1:52 PM, Antonio Sanso  wrote:

The problem is that a malicious client can register a malicious redirect uri 
and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as 
previously discussed)

regards

antonio

On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:

If a server accepts a URL from a client to be used as a redirect that the 
server doesn’t recognize or is not registered, that is an open redirect.

The specification does no allow open-redirects, it considers this a 
mis-configuration.

Take a look at sections 3.1.2.2 and 10.15 of RFC6749.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Sep 15, 2014, at 1:00 PM, John Bradley  wrote:

There may be a problem with semantics in this discussion.

There is a redirect performed by athe authorization endpoint to a fixed uri 
that is pre registered with the authorization server without user prompting.

That probably doesn't fit the strict definition of a open redirector.

It may however create similar security issues in situations with relatively 
open registration of clients.

The largest issues are that the browser might leak information across the 
redirect in the fragment or referrer.  That has been used in attacks against 
Facebook in the past.

This is no where near the end of the world,  however we need to look at the 
security considerations and see if we can provide better advice to 
implementors.  In some cases returning a error to the browser may be best.

I don't think we need to go so far as not returning any error to the client 
under any circumstance.

John B.

Sent from my iPhone

On Sep 15, 2014, at 4:41 PM, Phil Hunt  wrote:

Simply not true.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Sep 15, 2014, at 12:10 PM, Antonio Sanso  wrote:

hi *,

my understanding is that there is a rough consensus that if an OAuth Provider 
follows rfc6749 verbatim will end up having an open redirector.
My next question would be now, is there anything we can do to raise some 
awareness about this issue?

regards

antonio

On Sep 4, 2014, at 3:15 PM, Hans Zandbelt  wrote:

I am convinced about the issue in the use case Antonio provided but I hope not 
to close the door on returning errors to known and trusted clients. Not sure 
anymore if that's possible though because the distinction can't be 
"registered"...

Hans.

On 9/4/14, 3:01 PM, Antonio Sanso wrote:
hi Bill
On Sep 4, 2014, at 2:52 PM, Bill Burke  wrote:

FWIW, Antonio convinced me and I'm going to change this in our IDM project.  
Thanks Antonio.  What convinced me was that the user is probably expecting a 
login screen.  Since there is this expectation, it might make it a little 
easier for the attacker to convince the user that a spoofed login screen is 
real.  I know this issue can only happen with unrestricted registration, but, 
IMO, this proposed change doesn't really have much of an effect on usability 
and is even backward compatible with the current RFC.

Wouldn't it better though to never do a redirect on an invalid request and just 
display an error page?

thanks for sharing your thoughts :). Display an error 400 is what Google does :)

regards

antonio


On 9/4/2014 3:50 AM, Antonio Sanso wrote:
Hi Hans,

I really fa

Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso]

Hi John,

agree that there are at two different things (as you pointed out below) where 
we could spend some word and provide some advice.

To summarize:

- one is the 'open redirect’ issue (net of semantic :), pointed by me,  where 
nothing is leaked 
- one is the leakage, pointed by John

Those two scenarios are different and might deserve to be discussed 
independently… :)


On Sep 15, 2014, at 11:56 PM, John Bradley  wrote:

> Something might get leaked by the browser, the fragment may be leaked by the 
> browser if the redirect URI doesn't contain a fragment in some browsers.
> 
> A simple security consideration might be to add a fragment to the 
> redirect_uri in the error case.
> 
> The other way that information may leak is via the referrer.   If there is 
> only one redirect by the AS the URI that was sent to the AS including all the 
> parameters would still be available to the target.
> A simple fix is to redirect to a intermediate page before redirecting to the 
> registered client, this clears the referrer.
> 
> It is true that nothing is leaked in the redirect_uri itself but there are 
> side channels in the browser that need to be considered.
> 
> The fixes are quite simple implementation issues and don't break anything.
> 
> Yes if the client is trusted then this is probably unnecessary but wouldn't 
> hurt anything.
> 
> John B.
> 
> PS for OAuth this would really only be exploitable if exact redirect_uri 
> matching is not happening.   
> 
> As I am a inherently bad person, I could hypothetically use this to attack a 
> AS that is doing domain level pattern matching of redirect URI and has a 
> public client in the same domain as the AS.
> 
> I should also note that domains using pattern matching are also vulnerable if 
> they allow other sorts of user hosted content like blog posts that pull in 
> images and leak the referrer.

if somebody is curios about some real world attack this is one I performed to 
Facebook that does exactly what John describes here 
http://intothesymmetry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html

regards

antonio

> 
> So we do probably need to provide some advice.
> 
> John B.
> 
> On Sep 15, 2014, at 6:15 PM, Richer, Justin P.  wrote:
> 
>> As we discussed before: This isn't really an open redirection in the 
>> classical sense since nothing gets leaked and the URI is tied back to a 
>> known (albeit malicious) client registration. And I thought the clear 
>> solution was to have an AS not automatically redirect to an untrusted client 
>> in error conditions, where "untrusted" is defined by the AS with guidance. 
>> If anything this is a security considerations addendum.
>> 
>> -- Justin
>> 
>> On Sep 15, 2014, at 4:52 PM, Antonio Sanso  wrote:
>> 
>>> The problem is that a malicious client can register a malicious redirect 
>>> uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest 
>>> (as previously discussed)
>>> 
>>> regards
>>> 
>>> antonio
>>> 
>>> On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:
>>> 
 If a server accepts a URL from a client to be used as a redirect that the 
 server doesn’t recognize or is not registered, that is an open redirect.
 
 The specification does no allow open-redirects, it considers this a 
 mis-configuration.
 
 Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
 
 Phil
 
 @independentid
 www.independentid.com
 phil.h...@oracle.com
 
 
 
 On Sep 15, 2014, at 1:00 PM, John Bradley  wrote:
 
> There may be a problem with semantics in this discussion. 
> 
> There is a redirect performed by athe authorization endpoint to a fixed 
> uri that is pre registered with the authorization server without user 
> prompting. 
> 
> That probably doesn't fit the strict definition of a open redirector. 
> 
> It may however create similar security issues in situations with 
> relatively open registration of clients. 
> 
> The largest issues are that the browser might leak information across the 
> redirect in the fragment or referrer.  That has been used in attacks 
> against Facebook in the past. 
> 
> This is no where near the end of the world,  however we need to look at 
> the security considerations and see if we can provide better advice to 
> implementors.  In some cases returning a error to the browser may be 
> best.  
> 
> I don't think we need to go so far as not returning any error to the 
> client under any circumstance. 
> 
> John B. 
> 
> Sent from my iPhone
> 
>> On Sep 15, 2014, at 4:41 PM, Phil Hunt  wrote:
>> 
>> Simply not true.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>> 
>> 
>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso  wrote:
>>> 
>>> hi *,
>>> 
>>> my understanding is that there is a rough

Re: [OAUTH-WG] open redirect in rfc6749

[Sergey Beryozkin]

Hi Antonio
On 16/09/14 09:52, Antonio Sanso wrote:

hi Sergey

On Sep 16, 2014, at 10:44 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:


Hi

I wonder, when we have a situation where any client, the malicious
clients, or good clients, all of them can easily register and provide
bad redirect URIs, intentionally or unintentionally, then does it imply
there's serious a weakness present somewhere else, in the
registration process for example ? Should the client registrations be
validated ?


as previously discussed is pretty fought to filter bad redirect uri
specially for big OPs like Facebook/Google et al where all you need to
have in order to create a new OAuth client is an email address (the
registration process is self-service).

Right, looks like it is weak all right if all what is needed for a 3rd 
party registration to succeed is to register an email address :-)


That said, the end user should be cautious, right ? I recall playing 
with the Salesforce account and it is up to the user to either add or 
not add a given client registration to the account.

Justin proposed some mitigation though… (namely a client can gain
‘reputation’ with time)

Sure, I guess it is a good advice on its own...
Cheers, Sergey



regards

antonio



Sergey


On 16/09/14 08:52, Hans Zandbelt wrote:

+1, Antonio and John convinced me that this is not limited to a
registration curation problem although that is where the problems starts
as Phil points out (and as much as I'd like it to stay there).

There are and will be consumer OPs (like Google) that have no means to
do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security
consideration for OPs that have no policy in place to allow only trusted
clients to register would be a good thing.

The advice for those OPs would be to not send errors back to untrusted
clients or do it only after explicit user interaction.

Hans.

On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote:

I think a security considerations addendum makes sense.

regards,
Torsten.


 Ursprüngliche Nachricht 
Von: "Richer, Justin P."
Datum:15.09.2014 23:15 (GMT+01:00)
An: Antonio Sanso
Cc: oauth@ietf.org 
Betreff: Re: [OAUTH-WG] open redirect in rfc6749

As we discussed before: This isn't really an open redirection in the
classical sense since nothing gets leaked and the URI is tied back to a
known (albeit malicious) client registration. And I thought the clear
solution was to have an AS not automatically redirect to an untrusted
client in error conditions, where "untrusted" is defined by the AS with
guidance. If anything this is a security considerations addendum.

-- Justin

On Sep 15, 2014, at 4:52 PM, Antonio Sanso mailto:asa...@adobe.com>> wrote:

> The problem is that a malicious client can register a malicious
redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1
does the rest (as previously discussed)
>
> regards
>
> antonio
>
> On Sep 15, 2014, at 10:43 PM, Phil Hunt mailto:phil.h...@oracle.com>> wrote:
>
>> If a server accepts a URL from a client to be used as a redirect
that the server doesn’t recognize or is not registered, that is an open
redirect.
>>
>> The specification does no allow open-redirects, it considers this a
mis-configuration.
>>
>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com 
>> phil.h...@oracle.com 
>>
>>
>>
>> On Sep 15, 2014, at 1:00 PM, John Bradley mailto:ve7...@ve7jtb.com>> wrote:
>>
>>> There may be a problem with semantics in this discussion.
>>>
>>> There is a redirect performed by athe authorization endpoint to a
fixed uri that is pre registered with the authorization server without
user prompting.
>>>
>>> That probably doesn't fit the strict definition of a open
redirector.
>>>
>>> It may however create similar security issues in situations with
relatively open registration of clients.
>>>
>>> The largest issues are that the browser might leak information
across the redirect in the fragment or referrer.  That has been used in
attacks against Facebook in the past.
>>>
>>> This is no where near the end of the world,  however we need to
look at the security considerations and see if we can provide better
advice to implementors.  In some cases returning a error to the browser
may be best.
>>>
>>> I don't think we need to go so far as not returning any error to
the client under any circumstance.
>>>
>>> John B.
>>>
>>> Sent from my iPhone
>>>
 On Sep 15, 2014, at 4:41 PM, Phil Hunt mailto:phil.h...@oracle.com>>
wrote:

 Simply not true.

 Phil

 @independentid
 www.independentid.com 
 phil.h...@oracle.com 



> On Sep 15, 2014, at 12:10 PM, Antonio Sanso mailto:asa...@adobe.com>>
wrote:
>
> hi *,
>
> my understanding is that there is a rough consensus that 

Re: [OAUTH-WG] open redirect in rfc6749

[Bill Burke]

I'll reiterate what convinced me if it helps.

The danger was a matter of expectations.  In Antonio's scenario, the 
user is more likely to be expecting a login screen and thus more likely 
to be fooled by a login-screen spoof.  Antonio's suggested changes don't 
break any compatibility either, it just requires the AS to display an 
error page on *any* parameter error instead of redirecting back. 
Something the spec already requires for a bad client id.


On 9/16/2014 5:08 AM, Antonio Sanso wrote:

Hi John,

agree that there are at two different things (as you pointed out below) where 
we could spend some word and provide some advice.

To summarize:

- one is the 'open redirect’ issue (net of semantic :), pointed by me,  where 
nothing is leaked
- one is the leakage, pointed by John

Those two scenarios are different and might deserve to be discussed 
independently… :)




On Sep 15, 2014, at 11:56 PM, John Bradley  wrote:


Something might get leaked by the browser, the fragment may be leaked by the 
browser if the redirect URI doesn't contain a fragment in some browsers.

A simple security consideration might be to add a fragment to the redirect_uri 
in the error case.

The other way that information may leak is via the referrer.   If there is only 
one redirect by the AS the URI that was sent to the AS including all the 
parameters would still be available to the target.
A simple fix is to redirect to a intermediate page before redirecting to the 
registered client, this clears the referrer.

It is true that nothing is leaked in the redirect_uri itself but there are side 
channels in the browser that need to be considered.

The fixes are quite simple implementation issues and don't break anything.

Yes if the client is trusted then this is probably unnecessary but wouldn't 
hurt anything.

John B.

PS for OAuth this would really only be exploitable if exact redirect_uri 
matching is not happening.

As I am a inherently bad person, I could hypothetically use this to attack a AS 
that is doing domain level pattern matching of redirect URI and has a public 
client in the same domain as the AS.

I should also note that domains using pattern matching are also vulnerable if 
they allow other sorts of user hosted content like blog posts that pull in 
images and leak the referrer.


if somebody is curios about some real world attack this is one I performed to 
Facebook that does exactly what John describes here 
http://intothesymmetry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html

regards

antonio



So we do probably need to provide some advice.

John B.

On Sep 15, 2014, at 6:15 PM, Richer, Justin P.  wrote:


As we discussed before: This isn't really an open redirection in the classical sense 
since nothing gets leaked and the URI is tied back to a known (albeit malicious) client 
registration. And I thought the clear solution was to have an AS not automatically 
redirect to an untrusted client in error conditions, where "untrusted" is 
defined by the AS with guidance. If anything this is a security considerations addendum.

-- Justin

On Sep 15, 2014, at 4:52 PM, Antonio Sanso  wrote:


The problem is that a malicious client can register a malicious redirect uri 
and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as 
previously discussed)

regards

antonio

On Sep 15, 2014, at 10:43 PM, Phil Hunt  wrote:


If a server accepts a URL from a client to be used as a redirect that the 
server doesn’t recognize or is not registered, that is an open redirect.

The specification does no allow open-redirects, it considers this a 
mis-configuration.

Take a look at sections 3.1.2.2 and 10.15 of RFC6749.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Sep 15, 2014, at 1:00 PM, John Bradley  wrote:


There may be a problem with semantics in this discussion.

There is a redirect performed by athe authorization endpoint to a fixed uri 
that is pre registered with the authorization server without user prompting.

That probably doesn't fit the strict definition of a open redirector.

It may however create similar security issues in situations with relatively 
open registration of clients.

The largest issues are that the browser might leak information across the 
redirect in the fragment or referrer.  That has been used in attacks against 
Facebook in the past.

This is no where near the end of the world,  however we need to look at the 
security considerations and see if we can provide better advice to 
implementors.  In some cases returning a error to the browser may be best.

I don't think we need to go so far as not returning any error to the client 
under any circumstance.

John B.

Sent from my iPhone


On Sep 15, 2014, at 4:41 PM, Phil Hunt  wrote:

Simply not true.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com




On Sep 15, 2014, at 12:10 PM, Antonio Sanso  wrote:

hi *,

my understanding is that there is a rough consensus that if an OAuth

Re: [OAUTH-WG] [jose] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token)

[Richard Barnes]

I will re-iterate here my strong preference that an "unsecured" or
"plaintext" JWS object be syntactically distinct from a real JWS object.
E.g. by having two dot-separated components instead of three.

Beyond that, seems like just shuffling deck chairs.

On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell 
wrote:

> cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.
>
> I agree that "plaintext” is not the most intuitive wording choice and that
> "unsecured" might better convey what's going on with the "none" JWS
> algorithm.
>
> Mike mentioned that, if this change is made in JWT, there are parallel
> changes in JWS. But note that there are also such changes in JWA (more than
> in JWS actually).
>
> On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones 
> wrote:
>
>>  -Original Message-
>> From: Warren Kumari [mailto:war...@kumari.net]
>> Sent: Monday, September 01, 2014 3:40 PM
>> To: sec...@ietf.org; draft-ietf-oauth-json-web-token@tools.ietf.org
>> Subject: Review of: draft-ietf-oauth-json-web-token
>>
>> I'm a little confused by something in the Terminology section (Section 2):
>>
>> Plaintext JWT
>>
>> A JWT whose Claims are not integrity protected or encrypted.
>>
>> The term plaintext to me means something like "is readable without
>> decrypting / much decoding" (something like, if you cat the file to a
>> terminal, you will see the information). Integrity protecting a string
>> doesn't make it not easily readable. If this document / JOSE uses
>> "plaintext" differently (and a quick skim didn't find anything about
>>
>> this) it might be good to clarify. Section 6 *does* discuss plaintext
>> JWTs, but doesn't really clarify the (IMO) unusual meaning of the term
>> "plaintext" here.
>>
>>
>>
>> I’ve discussed this with the other document editors and we agree with you
>> that “plaintext” is not the most intuitive wording choice in this context.
>> Possible alternative terms are “Unsecured JWT” or “Unsigned JWT”.  I think
>> that “Unsecured JWT” is probably the preferred term, since JWTs that are
>> JWEs are also unsigned, but they are secured.  Working group – are you OK
>> with this possible terminology change?  (Note that the parallel change
>> “Plaintext JWS” -> “Unsecured JWS” would also be made in the JWS spec.)
>>
>>
>>
>
> ___
> jose mailing list
> j...@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth