just sharing with you how this very “issue” has been lately used in a real life
attack:
http://andrisatteka.blogspot.ch/2014/09/how-microsoft-is-giving-your-data-to.html
regards
antonio
On Oct 9, 2014, at 3:34 PM, Antonio Sanso wrote:
> hi again *,
>
> apologies to bother you again with thi
hi again *,
apologies to bother you again with this :), just wasn’t really clear to me if
this is considered like ‘solved’ (namely the discussion is over, no action to
be taken) or we need still to discuss about this topic in order to reach some
sort of consensus :)
regards
antonio
On Sep
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
"Richer, Justin P."
Datum:15.09.2014 23:15 (GMT+01:00)
An: Antonio Sanso
Cc: oauth@ietf.org <mailto: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 leake
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 t
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?
T
sten 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<mailto:oauth@ietf.org>
Betreff: Re: [OAUTH-WG]
icher, 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
ction.
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:
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 discus
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
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?
Are you referring to the case Nat Sakimura previously raised where mobile app
stores do
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
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 on
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.
This seems like a registration curation (whitelisting) problem.
This is a bit like saying, how can I prove that the appl
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
Yes, but a redirect to a registered redirect_uri may still leak information in
the referrer or fragment.
That is the point Antonio is trying to make.
It is not a open redirect but might be used as part of an attack on someone.
John B.
Sent from my iPhone
> On Sep 15, 2014, at 5:43 PM, Phi
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
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 howe
On Sep 15, 2014, at 9:41 PM, Phil Hunt wrote:
hi Phil
> Simply not true.
why do you think so ?
regards
antonio
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote:
>
>> hi *,
>>
>> my understanding is tha
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.
> M
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,
The distinction can be made, and it's AS policy. Sometimes (like in our case)
the AS distinguishes between client registered by an administrator vs. an end
user vs. something dynamic (no user involved). And in the latter cases, the AS
can still figure out how long something's been registered and
hi Hans
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
> "regi
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 Bil
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
> eas
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 s
In a enterprise case likely there is some trusted relationship.
In the Web 2.0 API economy case there is a tension between providers wanting
the maximum number of users and validating the developer registering the client.
Often having a email someplace is sufficient to register a client. That is
exactly, but my point would be that the attacker needs to have an
relationship/account with the OP; this is where the approval is and I
agree with Antonio/you that that is tricky for consumer ASs and deserves
a warning
Hans.
On 9/4/14, 2:22 PM, John Bradley wrote:
Registration requiring a va
On Sep 4, 2014, at 2:22 PM, John Bradley wrote:
> Registration requiring a valid email address is not sufficient to stop a
> "bad" person from registering a client that appears to be perfectly
> legitimate but is later used as a redirect.
totally agree!
>
> So it is a bit slippery to differ
Registration requiring a valid email address is not sufficient to stop a "bad"
person from registering a client that appears to be perfectly legitimate but is
later used as a redirect.
So it is a bit slippery to differentiate good from bad.
In general clearing the referrer and fragment from inc
I registered via the Google Developers Console [0] :)
[0] https://console.developers.google.com/project
On Sep 4, 2014, at 2:09 PM, Hans Zandbelt
mailto:hzandb...@pingidentity.com>> wrote:
Maybe just to clarify my point: where did the client_id in the example that you
gave come from?
Hans.
O
Maybe just to clarify my point: where did the client_id in the example
that you gave come from?
Hans.
On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
yes, you are right about the unrestricted client use case; I just got
caught by the fact that you were talking about *unrestricted* client
registration
yes, you are right about the unrestricted client use case; I just got
caught by the fact that you were talking about *unrestricted* client
registration all the time (standards-based or not) which deserves extra
caution whereas Google (and the spec) also provides *restricted* client
registration
hi Hans
On Sep 4, 2014, at 10:58 AM, Hans Zandbelt wrote:
> Agreed, I see you point about the big providers using exactly the
> unrestricted flow for which the trust model (by definition) is out of scope
> of the spec. This may be the reason for the implemented behavior indeed and a
> securit
Agreed, I see you point about the big providers using exactly the
unrestricted flow for which the trust model (by definition) is out of
scope of the spec. This may be the reason for the implemented behavior
indeed and a security consideration is a good idea for other
deployments; there's not mu
Hi Hans,
I really fail to see how this can be addressed at registration time for cases
where registration is unrestricted (namely all the big Providers)
regards
antonio
On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote:
> Classifying like this must also mean that consent should not be stored u
Classifying like this must also mean that consent should not be stored
until the client is considered (admin) trusted, and admin policy would
interfere with user policy.
IMHO the security consideration would apply only to dynamically
registered clients where registration is unrestricted; any o
I think this advice isn't a bad idea, though it's of course up to the AS what
an "untrusted" client really is. In practice, this is something that was
registered by a non-sysadmin type person, either a dynamically registered
client or something available through self-service registration of some
I think that is probably reasonable advice.
Presenting a dialog to the user also has the beneficial side effect of removing
the original referrer from being seen by the party hosting the redirect_uri.
It is allowing dynamic parameters to be passed in the referrer that is the
largest security
hi again *,
after thinking a bit further IMHO an alternative for the untrusted clients can
also be to always present the consent screen (at least once) before any
redirect.
Namely all providers I have seen show the consent screen if all the request
parameters are correct and if the user accepts
thanks Phil for pointing the sections out but reading them I still think the
case I brought up is still a different one :)
On Sep 3, 2014, at 9:49 PM, Phil Hunt wrote:
> ooops,, that 6819 not 6810
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Sep 3, 2
hi Takahiko
On Sep 3, 2014, at 9:33 PM, Takahiko Kawasaki
mailto:daru...@gmail.com>> wrote:
I think the point is that the registered redirect URI is evil, meaning that the
person who registered the client application is evil. I don't think the spec
can take any countermeasure against this case
ooops,, that 6819 not 6810
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Sep 3, 2014, at 12:47 PM, Phil Hunt wrote:
> in RFC6810, see section 3.5 and 4.1.5.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Sep 3, 2014, at 12:36 P
in RFC6810, see section 3.5 and 4.1.5.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Sep 3, 2014, at 12:36 PM, Antonio Sanso wrote:
> hi Phil,
> can you point out the relative paragraph that covers this specific case in
> RFC6819?
> On Sep 3, 2014, at 9:23 PM, Phil Hunt
One improvement we made in dyn reg was the introduction of software statements.
This can be used to force all mobile clients claiming to be a particular client
to register the same redirect uri.
This closes the door on a large number of cases.
Phil
> On Sep 3, 2014, at 12:33, Takahiko Kawasa
hi Phil,
can you point out the relative paragraph that covers this specific case in
RFC6819?
On Sep 3, 2014, at 9:23 PM, Phil Hunt wrote:
> I do not believe this is a flaw specific to 6749. The flaw if any is within
> HTTP itself (RFC7230). Covert redirect is a well known problem. There are
>
I think the point is that the registered redirect URI is evil, meaning that
the person who registered the client application is evil. I don't think the
spec can take any countermeasure against this case.
If the registered redirect URI is evil, the issue happens even in the case
where the scope is
I do not believe this is a flaw specific to 6749. The flaw if any is within
HTTP itself (RFC7230). Covert redirect is a well known problem. There are
extensive recommendations that prevent this covered in 6749 and 6819.
There is no protocol fix that OAuth can make since it is a trait or feature
fine, you're talking security considerations about untrusted clients;
that's a different use case than the protocol flaw reason why Google
would not do rfc6749 as written
Hans.
On 9/3/14, 7:52 PM, John Bradley wrote:
I agree that the error case where there is no UI is the problem, as it can b
Well,
I do not know if this is only dynamic registration...
let’s talk about real use cases, namely e.g. Google , Facebook , etc.. is that
dynamic client registration? I do not know… :)
Said that what the other guys think? :)
Would this deserve some “spec adjustment” ? I mean there is a reason i
I agree that the error case where there is no UI is the problem, as it can be
used inside a Iframe.
However error responses are generally useful.
OAuth core is silent on how redirect_uri are registered and if they are
verified.
Dynamic registration should warn about OAuth errors to redire
On 9/3/14, 7:14 PM, Antonio Sanso wrote:
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote:
Is your concern clients that were registered using dynamic client registration?
yes
I think your issue is then with the trust model of dynamic client
registration; that is left out of scope of the d
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote:
> Is your concern clients that were registered using dynamic client
> registration?
yes
>
> Otherwise the positive case is returning a response to a valid URL that
> belongs to a client that was registered explicitly by the resource owner
we
Is your concern clients that were registered using dynamic client
registration?
Otherwise the positive case is returning a response to a valid URL that
belongs to a client that was registered explicitly by the resource owner
and the negative case is returning an error to that same URL.
I fai
On Sep 3, 2014, at 6:51 PM, Hans Zandbelt
mailto:hzandb...@pingidentity.com>> wrote:
Let me try and approach this from a different angle: why would you call it an
open redirect when an invalid scope is provided and call it correct protocol
behavior (hopefully) when a valid scope is provided?
Let me try and approach this from a different angle: why would you call
it an open redirect when an invalid scope is provided and call it
correct protocol behavior (hopefully) when a valid scope is provided?
Hans.
On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, J
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley
mailto:ve7...@ve7jtb.com>> wrote:
In the example the redirect_uri is vlid for the attacker.
The issue is that the AS may be allowing client registrations with arbitrary
redirect_uri.
In the spec it is unspecified how a AS validates that a clien
On Sep 3, 2014, at 6:10 PM, Bill Burke
mailto:bbu...@redhat.com>> wrote:
I don't understand. The redirect uri has to be valid in order for a redirect
to happen. The spec explicitly states this.
the redirect uri is indeed valid. The wrong parameter is the scope.
So if the attacker is the per
In the example the redirect_uri is vlid for the attacker.
The issue is that the AS may be allowing client registrations with arbitrary
redirect_uri.
In the spec it is unspecified how a AS validates that a client controls the
redirect_uri it is registering.
I think that if anything it may be th
I don't understand. The redirect uri has to be valid in order for a
redirect to happen. The spec explicitly states this.
On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,
IMHO providers that strictly follow rfc6749 are vulnerable to open redirect.
Let me explain, reading [0]
If the request f
hi *,
IMHO providers that strictly follow rfc6749 are vulnerable to open redirect.
Let me explain, reading [0]
If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resou
62 matches
Mail list logo
