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 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 incoming requests is a good
practice on redirects to prevent leakage of information across the redirect.
The other concern is using the redirect as part of a phishing attack to make
the target site look more legitimate.
That is a more complicated problem unless you validate every client by looking
at them to make sure they are not bad in some way.
John B.
On Sep 4, 2014, at 2:09 PM, Hans Zandbelt <hzandb...@pingidentity.com> wrote:
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 all the time (standards-based or not) which deserves extra
caution whereas Google (and the spec) also provides *restricted* client
registration the deviation or caution is not needed
Hans.
On 9/4/14, 1:44 PM, Antonio Sanso wrote:
hi Hans
On Sep 4, 2014, at 10:58 AM, Hans Zandbelt
<hzandb...@pingidentity.com> 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 security consideration is a good idea for other
deployments; there's not much more that can be done.
But Google also provides explicit registration for API clients (which
is where my mind was):
https://developers.google.com/accounts/docs/OAuth2 (step 1)
and they would not need to deviate from the spec for that, nor would
the spec need to change
I do really struggle to understand your point here :) (at least the
"nor would the spec need to change part" :)).
Probably I need to explain myself better.
Since Google is “safe” (due the “deviation” from the spec) I would
take Google as example here (I could point out open redirector in the
wild to proof my point but I will not do…)
Let’s start from scratch…
If Google would have something like
http://www.google.com?goto=attacker.com this is without any doubt an
open redirector… see also OWASP 10 [0].
Now if Google would have implemented the spec rfc6749 verbatim
something like
https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
would have redirect to http://attacker.com.
So why this is not an open redirect ? :)
Now maybe we are saying the same thing but I felt like better explain
my point :)
regards
antonio
[0]
https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards
Hans.
On 9/4/14, 9: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
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
_______________________________________________
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
