handlers: reject protocol-relative URLs in redirect validation

[adilburaksen]

Summary

check_redirect_url in src/appengine/handlers/base_handler.py uses
_SAFE_URL_PATTERN (based on the Closure Library SafeUrl pattern) to
validate redirect targets. The relative-URL branch of that pattern is:

[^:/?#]*(?:[/?#]|$)

[^:/?#]* can match zero characters, after which (?:[/?#]|$) matches
the leading / of //evil.com. This means the pattern accepts any
protocol-relative URL such as //attacker.example.com/steal as safe.

Browsers interpret //evil.com/path as scheme-relative (same scheme as
the current page), so a next=//evil.com/login parameter causes a
post-login redirect to the attacker's host.

Fix

Add a negative lookahead (?!//) to the relative-URL branch:

# Before
r'^(?:(?:https?|mailto|ftp):|[^:/?#]*(?:[/?#]|$))'

# After
r'^(?:(?:https?|mailto|ftp):|(?!//)[^:/?#]*(?:[/?#]|$))'

This rejects any URL that the relative branch would match but that begins
with //, while continuing to accept ordinary relative paths (/login,
relative/path) and absolute URLs with safe schemes.

Verification

>>> import re
>>> p = re.compile(r'^(?:(?:https?|mailto|ftp):|(?!//)[^:/?#]*(?:[/?#]|$))', re.I)
>>> bool(p.match('//evil.com/path'))
False
>>> bool(p.match('/login'))
True
>>> bool(p.match('https://clusterfuzz.com/'))
True

[adilburaksen]

Gentle ping after ~18 days — small change rejecting protocol-relative URLs in the redirect handler to close an open-redirect. CI is green; glad to add a test case or adjust if you'd like a tighter check.

[adilburaksen]

Pushed a follow-up that closes a gap in the original (?!//) check.

The scheme-relative guard alone is bypassable, because browsers normalize backslashes to forward slashes and strip ASCII tab/newline and leading control/whitespace before navigating. Since _SAFE_URL_PATTERN is start-anchored and [^:/?#]* consumes a leading space or backslash, the (?!//) lookahead (evaluated at offset 0) never sees the //:

dest= value	passes (?!//)-only regex	browser navigates to
/\evil.com, \\evil.com, \/\/evil.com	yes	//evil.com
//evil.com, \r\n//evil.com	yes	//evil.com

Both /login?dest= and /logout?dest= are fully request-controlled and reach check_redirect_url, so these navigate to an external host through the trusted login/logout flow.

The added pre-check rejects any input with a backslash, a control character, or leading/trailing whitespace before the pattern match. Verified it blocks all of the above plus the original //evil.com, while still allowing /another-page, /login, https://blah.com/test, /dashboard?q=a b, and still rejecting javascript:.