> I think the correct defence is to validate the URL
I agree. The URL can be whitelisted, signed, encrypted, ... > > Can we please add an explicit prohibition of this practice in > > draft-ietf-oauth-security-topics? > However, we should be careful how we prohibit it... You could argue that it's already there. Section 4.7.1 says: If "state" is used for carrying application state, and integrity of its contents is a concern, clients MUST protect "state" against tampering and swapping. This can be achieved by binding the contents of state to the browser session and/or signed/encrypted state values [I-D.bradley-oauth-jwt-encoded-state]. Implementations, like the ones you're seeing, where "state" stores a URL and is used without validation do not comply with the above paragraph. I do agree that the above paragraph is somewhat hidden in the CSRF section. Perhaps a new subsection could be added to section 4 where attacks on the "state" parameter are discussed (and where countermeasures like signing the state are repeated)? Regards, Pieter ________________________________ From: OAuth <[email protected]> on behalf of Neil Madden <[email protected]> Sent: Tuesday, April 21, 2020 23:35 To: George Fletcher Cc: Mike Jones; [email protected] Subject: Re: [OAUTH-WG] Caution about open redirectors using the state parameter I think the correct defence is to validate the URL (eg check against a whitelist) at the point you are going to redirect to it after the OAuth flow completes, rather than before you begin the OAuth flow. But this feels like generic web app security advice rather than anything specific to OAuth - always validate URLs before performing a redirect. Neil On 21 Apr 2020, at 20:28, George Fletcher <[email protected]> wrote: ? +1 However, we should be careful how we prohibit it... because if the state value is actually signed, having the URL there isn't a problem as the attacker can not manipulate the value without breaking the signature. On 4/20/20 5:28 PM, Mike Jones wrote: I've seen several circumstances where "clever" clients implement an open redirector by encoding a URL to redirect to in the state parameter value. Attackers can then utilize this open redirector by choosing a state value. Can we please add an explicit prohibition of this practice in draft-ietf-oauth-security-topics? Thanks, -- Mike _______________________________________________ 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
