If you plan on adding these web layer security suggestions into the OAuth standard I can think of 100-200 more requirements to add. I thought “do web security right” was an implied recommendation?
-- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Mar 20, 2018, at 5:37 AM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > +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 (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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
