Hi Neil and Filip, Thank you so much for the quick revert.
Neil, in the last statement you mentioned "I would say in this case the onus falls on the client to validate the state value before blindly copying it into the Location header." since the state can contain anything in it. Yes, I do agree that the client should be the one validating the state. I already informed them of the same. But when i found that another client is vulnerable to open redirection due to this, I realised that instead of multiple clients validating the state value, wouldn't it be better if the Authorization server does this? One fix from google and all the vulnerable clients would already be free from this vulnerability. Filip, in terms of implementing it securely, since authorization server is the one explicitly mentioning it to use for redirection, shouldn't authorization server also have measures to sanitize the issue? My only point of asking this is i believe the authorization server should have also validated the state but they haven't. Regards, Chaitanya Reddy On Mon, Jul 1, 2024 at 6:33 PM Chaitanya Reddy < nchaitreddyutilit...@gmail.com> wrote: > Hi Neil and Filip, > > Thank you so much for the quick revert. > > Neil, in the last statement you mentioned "I would say in this case the > onus falls on the client to validate the state value before blindly copying > it into the Location header." since the state can contain anything in it. > Yes, I do agree that the client should be the one validating the state. I > already informed them of the same. > But when i found that another client is vulnerable to open redirection due > to this, I realised that instead of multiple clients validating the state > value, wouldn't it be better if the Authorization server does this? One fix > from google and all the vulnerable clients would already be free from this > vulnerability. > > Filip, in terms of implementing it securely, since authorization server is > the one explicitly mentioning it to use for redirection, shouldn't > authorization server also have measures to sanitize the issue? > My only point of asking this is i believe the authorization server should > have also validated the state but they haven't. > > Regards, > Chaitanya Reddy > > On Mon, Jul 1, 2024 at 6:09 PM Neil Madden <neil.e.mad...@gmail.com> > wrote: > >> Section 3.1.2.2 of RFC 6749 says: >> >> >> The authorization server SHOULD require the client to provide the >> complete redirection URI (*the client MAY use the "state" request >> parameter to achieve per-request customization*) >> >> >> So I’d say it is allowed to use the state parameter to hold a URI to >> redirect to after the flow completes. But note also the requirement in >> section 10.14: >> >> >> The authorization server and client MUST sanitize (and validate when >> possible) any value received -- in particular, the value of the >> "state" and "redirect_uri" parameters. >> >> >> Given that there is almost no restriction on what “state” can contain, I >> would say in this case the onus falls on the client to validate the state >> value before blindly copying it into the Location header. It sounds like >> those clients have an open redirect vulnerability and need to implement >> some kind of allow-list of acceptable URIs. >> >> — Neil >> >> On 1 Jul 2024, at 05:50, Chaitanya Reddy <nchaitreddyutilit...@gmail.com> >> wrote: >> >> Hi Team, >> >> Hope you are doing well! >> >> I am writing this mail regarding the discussion of usage of *state* >> parameter in the OAuth implementation. >> >> As per the RFC 6749, "*An opaque value is used by the client to maintain >> state between the request and callback. And it should be used to prevent >> cross-site request forgery*". Since it's an opaque value, OAuth >> implementors usually don't sanitize the value. >> >> One of the OAuth 2.0 implementors (Google) have defined state as "*You >> can use this parameter for several purposes, such as directing the user to >> the correct resource in your application, sending nonces, and mitigating >> cross-site request forgery*" >> >> The issue arries here due to the fact that Google allows the use of state >> parameter for directing the users to the correct resource. Since the value >> in RFC is defined as *opaque, *they are not sanitizing the value for any >> possible malicious values. I have observed two instances where clients >> using Google's OAuth service directly use the state parameter value in >> *Location >> header *to redirect the users hence resulting in header injection >> attacks. >> >> As per my understanding, this issue arises due to the fact that: >> 1. Google allows state parameter to be used for purpose not defined in >> RFC. >> 2. Google is not sanitizing the state paramater on their end. >> 3. Client is also not sanitizing the state paramater and directly using >> it in the *Location* header. >> >> I have raised this issue to google via google VRP but after weeks of >> communication over the ticket, the engineer feels like they are not in >> disagreement with the spec and have requested me to discuss it further with >> your team and hence i am reaching out to you. >> >> Please let me know your thoughts about this. >> >> Regards, >> Chaitanya Reddy >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> >> >>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
