+1 to what Travis said about 3.8.1 The text in 3.8 about Open Redirection is new in this most recent -05 version of the draft so this is really the first time it's been reviewed. I believe 3.8.1 goes too far in saying "this draft recommends that every invalid authorization request MUST NOT automatically redirect the user agent to the client's redirect URI."
I understand that text was informed by https://tools.ietf.org/html/ draft-ietf-oauth-closing-redirectors-00 but it takes one of the potential mitigation discussed there in section 3 <https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#section-2.3> (the one which happens to contradict RFC 6749) and elevates it to a "MUST". I don't think something that drastic is warranted. I think there are other mitigations - like strict redirect_uri matching, referrer-policy headers, and appending a dummy fragment on error redirects - that can protect against the more serious redirection issues without -security-topics trying to introduce normative breaking changes to the behavior from the original OAuth 2.0 Authorization Framework. Perhaps there are some error cases not mentioned in RFC 6749 where returning an HTTP error code to the browser would be better or more appropriate than redirecting back to the OAuth client (my opinion on this has gone in circles and I'm honestly not sure anymore). But saying that authorization requests never automatically redirect back to the client's redirect URI is excessive. On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer <travis.spen...@curity.io> wrote: > 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 > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.*
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
