I read through this doc and would like to share a bit of feedback in
hopes that it helps:
* There is no mention of Content Security Policy (CSP). This is a very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
doc.
- No mention of frame breaking scripts for non-CSP aware user agents
- No mention of X-Frame-Options
* There's no mention of HSTS which all OAuth servers and web-based
client should implement (or the reverse proxies in front of them
should)
* The examples only use 302 and don't mention that 303 is safer[1]
- Despite what it says in section 1.7 of RFC 6749, many people
think that a 302 is mandated by OAuth. It would be good to recommend a
303 and use examples with other status codes.
* 3.3.1 refers to client.com in the example. This is a real domain.
Suggest client.example.com instead. Same issue in 3.1.2 where
client.evil.com is used
* 3.1.3 (proposed countermeasures) - native clients that use a web
server with a dynamic port should use dynamic client registration and
dynamic client management rather than allowing wildcards on the port
matching of the OAuth server.
* 3.8.1 says "Therefore this draft recommends that every invalid
authorization request MUST NOT automatically redirect the user agent
to the client's redirect URI" -- This is gonna break a lot of stuff
including other specs! I don't think that's warranted, and I am not
looking forward to the fallout this could cause.
Anyway, my $0.02. Hope it helps.
[1] https://arxiv.org/pdf/1601.01229v2.pdf
On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <jos...@authlete.com> wrote:
> Hi Torsten,
>
> As we briefly spoke about earlier, "3.8.1. Authorization Server as Open
> Redirector" could I think be made more explicit.
>
> Currently it explicitly mentions the invalid_request and invalid_scope
> errors must not redirect back to the client's registered redirect uri.
>
> https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more
> potential errors that appear to fall into the same category. I understand to
> block the attack fully we need 'must not redirect's for all the kinds of
> error that could cause an automatic redirect back to the client's registered
> redirect uri without any user interaction - 'unauthorized_client' and
> 'unsupported_response_type' seem to fall into that category. 'server_error'
> also seems dodgy (I would wager that on some servers that are known ways to
> provoke server errors), and I would have doubts about
> 'temporarily_unavailable' too.
>
> Thanks
>
> Joseph
>
>
> _______________________________________________
> 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
