[OAUTH-WG] Re: Security Bug | Unintended usage of "state" parameter can lead to Header Injection Attacks

[Filip Skokan <[e-mail]>]

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 <[e-mail]>
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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>