hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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 the victim.com<http://victim.com>
<http://victim.com>
provider.
I register redirect uri 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>.
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
