Hello Chaitanya! This is likely deeper than a sanitization issue. Sanitation would be making sure you don’t output formatting or delimiter characters when manually building up a response, such as including HTML tags like “script” in a state parameter which is dropped into a form as a hidden input field, or using it for a database lookup on the client side without protecting from SQL injection.
Instead, these client are not validating the response matches the request they made. This allows a malicious party (browser extension, AS) to modify the request or response. So if the state value is the final location without any integrity checks, an intermediary in the transaction can change this to any value before it is returned to the redirect URI, and treat the client as an open redirector. This client responsibility is mentioned in section 4.7.1 of the OAuth Security BCP. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.7 , albeit in the context of explaining how state has less protocol/security requirements with the addition of PKCE. -DW > On Jun 30, 2024, at 10:50 PM, 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
