On 9/3/14, 7:14 PM, Antonio Sanso wrote:
On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <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>> 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>> 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>> 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://victim.com/><http://victim.com <http://victim.com/>>
<http://victim.com <http://victim.com/>>
provider.
I register redirect uriattacker.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/>>.
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
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 <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
_______________________________________________
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 <mailto: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
