Conversation
When a client connects to https://example.com/<path>, the state cookie is set to <path><10 random chars> . And after successful authentication, we issue a 307 redirect to the location <path>. We didn't perform any validation on <path>. The signature only proves that the cookie wasn't tampered with, not that <path> was safe. The server signs whatever path the original request happened to have. Problem with a 30x redirect: - If the location starts with // it is interpreted as a host name (//evil.com -> https://evil.com) Also: - WHATWG also treats \ like /, so \/ for example would parsed the same as // - WHATWG strips ASCII tab and newline before parsing, so a redirect to /<TAB>/evil.com would be equivalent to //evil.com This open redirect is a convenient phishing primitive: the user just authenticated, sees the real domain in the URL bar through the entire OAuth dance, and lands on attacker territory primed to be told "session expired, please re-enter your password" or to be served a fake consent screen. That also works because Compute doesn't seem to be doing any URL normalization (such as // -> /). So, add validation.
Pomax
approved these changes
Apr 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a client connects to https://example.com/, the state cookie is set to
<path><10 random chars>.And after successful authentication, we issue a 307 redirect to the location
<path>.We didn't perform any validation on
<path>. The signature only proves that the cookie wasn't tampered with, not that<path>was safe. The server signs whatever path the original request happened to have.Problem with a 30x redirect:
//evil.com-> https://evil.com)Also:
\like/, so\/for example would parsed the same as///<TAB>/evil.comwould be equivalent to //evil.comThis open redirect is a convenient phishing primitive: the user just authenticated, sees the real domain in the URL bar through the entire OAuth dance, and lands on attacker territory primed to be told "session expired, please re-enter your password" or to be served a fake consent screen.
That also works because Compute doesn't seem to be doing any URL normalization (such as
//->/).So, add validation.