I also agree that the burden is on the client to not become an Open Redirector by blindly copying the value of the state parameter into a Location header.
However, the OAuth Security BCP does make the additional requirement that clients MUST prevent CSRF attacks: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.1 Clients that have ensured that the authorization server supports Proof Key > for Code Exchange (PKCE, [RFC7636]) MAY rely on the CSRF protection > provided by PKCE. In OpenID Connect flows, the nonce parameter provides > CSRF protection. Otherwise, one-time use CSRF tokens carried in the state > parameter that are securely bound to the user agent MUST be used for CSRF > protection (see Section 4.7.1). Using a hardcoded value for state does not provide CSRF protection, and there is no mention of PKCE in the Google API docs https://developers.google.com/identity/protocols/oauth2/web-server#httprest_1 So I would say it's the client's problem that it is possibly an Open Redirector and also does not have CSRF protection. You could make the argument that the authorization server should try to prevent the client from using a hardcoded state value, but ultimately the responsibility is on the client. Aaron On Mon, Jul 1, 2024 at 5:43 AM Filip Skokan <panva...@gmail.com> wrote: > Hello Chaitanya. > > The AS is to treat the state value as an opaque string, merely echoing it > back to the client, at most the AS is required to ensure the state's syntax > is within its ABNF definition, then send its exact value back with the > authorization response. > > I don't find this particular AS implementation's documentation-defined > state use to fall outside of its intended use. Of course it could come with > more guidance on how to achieve those particular purposes securely, so that > the client doesn't become an Open Redirector > <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-29#name-client-as-open-redirector> > . > > S pozdravem, > *Filip Skokan* > > > On Mon, 1 Jul 2024 at 14:20, 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
