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 <ve7...@ve7jtb.com> 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. <jric...@mitre.org> 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 <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 <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 <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 <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 <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 <hzandb...@pingidentity.com> 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 <bbu...@redhat.com> 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 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 <hzandb...@pingidentity.com> wrote:
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 other form would involve some
form of admin/user approval at registration time, overcoming the concern at
authorization time: there's no auto-redirect flow possible for unknown clients.
Hans.
On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
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 type. It's also reasonable that a client, even
dynamically registered, would be considered "trusted" if enough time has
passed and enough users have used it without things blowing up.
-- Justin
On Sep 4, 2014, at 1:26 AM, Antonio Sanso <asa...@adobe.com
<mailto:asa...@adobe.com>> wrote:
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 the redirect
happens.
If one of the parameter (with the exclusion of the client id and
redirect uri that are handled differently as for spec) is wrong though
the redirect happens without the consent screen being shown..
WDYT?
regards
antonio
On Sep 3, 2014, at 7:54 PM, Antonio Sanso <asa...@adobe.com
<mailto:asa...@adobe.com>> wrote:
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
if Google is by choice “violating” the spec right? (I assume to avoid
open redirect…)
But other implementers do follow the spec hence they have this open
redirector… and this is not nice IMHO...
On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <hzandb...@pingidentity.com
<mailto:hzandb...@pingidentity.com>> wrote:
On 9/3/14, 7:14 PM, Antonio Sanso wrote:
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
<hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>> 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 dynreg spec (and the
concept is not even part of the core spec), but unless you want
everything to be open (which typically would not be the case), then
it would involve approval somewhere in the process before the client
is registered. Without dynamic client registration that approval is
admin based or resource owner based, depending on use case.
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
well AFAIK the resource owner doesn’t register clients…
roles can collapse in use cases especially when using dynamic client
registration
and the negative case is returning an error to that same URL.
the difference is the consent screen… in the positive case you need
to approve an app.. for the error case no approval is needed,,,
I fail to see the open redirect.
why?
because the client and thus the fixed URL are explicitly approved at
some point
Hans.
Hans.
On 9/3/14, 6:56 PM, Antonio Sanso wrote:
On Sep 3, 2014, at 6:51 PM, Hans Zandbelt
<hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>
<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?
as specified below in the positive case (namely when the correct
scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).
Hans.
On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com>
<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 client
controls the redirect_uri it is registering.
I think that if anything it may be the registration step that
needs
the security consideration.
(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time….
IMHO the best approach is the one taken from Google, namely
returning
400 with the cause of the error..
*400.* That’s an error.
*Error: invalid_scope*
Some requested scopes were invalid. {invalid=[l]}
said that I hope you all agree this is an issue in the spec so
far….
regards
antonio
John B.
On Sep 3, 2014, at 12:10 PM, Bill Burke <bbu...@redhat.com
<mailto:bbu...@redhat.com>
<mailto:bbu...@redhat.com>
<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.
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 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 resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.
If the resource owner denies the access request or if the
request
fails for reasons other than a missing or invalid
redirection URI,
the authorization server informs the client by adding the
following
parameters to the query component of the redirection URI
using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tools.ietf.org/html/rfc6749#appendix-B>:
Now let’s assume this.
I am registering a new client to thevictim.com
<http://thevictim.com/>
<http://victim.com/><http://victim.com <http://victim.com/>
<http://victim.com/>>
<http://victim.com <http://victim.com/> <http://victim.com/>>
provider.
I register redirect uriattacker.com <http://uriattacker.com/>
<http://attacker.com/><http://attacker.com
<http://attacker.com/> <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>
<http://attacker.com/>>.
According to [0] if I pass e.g. the wrong scope I am redirected
back to
attacker.com <http://attacker.com/>
<http://attacker.com/><http://attacker.com
<http://attacker.com/>
<http://attacker.com/>> <http://attacker.com
<http://attacker.com/> <http://attacker.com/>>.
Namely I prepare a url that is in this form:
http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
and this is works as an open redirector.
Of course in the positive case if all the parameters are
fine this
doesn’t apply since the resource owner MUST approve the app
via the
consent screen (at least once).
A solution would be to return error 400 rather than redirect
to the
redirect URI (as some provider e.g. Google do)
WDYT?
regards
antonio
[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com <http://bill.burkecentral.com/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
<mailto:OAuth@ietf.org><mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>
<mailto:hzandb...@pingidentity.com>| Ping
Identity
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com> |
Ping Identity
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>| Ping
Identity
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
