Bypassing Unvalidated Open Redirect Filters


A quick PoC/tutorial on bypassing open redirect filters in Infosec Institutes Level 13 CTF challenge. Full details on the challenge can be found here: All credits go to 1N3 @CrowdShield and full disclosure details can be found here:

Request #1

The request below indicates that the affected page is redirecting all requests sent to the redirect= parameter which may be vulnerable to open redirect attacks.

Response #1

The addition of the Location: header indicates that the value specified in the redirect= GET parameter is being injected into the Location: header field.

Burpsuite Open Redirect Fuzz List

Using Burpsuite Intruder or any other web proxy, we can use the following list to check for open redirect vulnerabilities and possible bypasses. This can be downloaded using Gist here:

Bypass Request #2

After fuzzing the redirect= parameter, we can see from the responses that javascript is being executed (levelCompleted(13);) only when the bypass is successful. The application attempts to prevent redirection attacks by blocking absolute redirection targets starting with http:// or https://. However, an attacker can defeat this defense by omitting the protocol prefix from their absolute URL. If a redirection target starting with // is specified, then the browser will use the same protocol as the page which issued the redirection. The application also appears to be blocking the standard protocol-relative sequence (//). However, an attacker can defeat this defense by using backslashes instead. Some browsers (notably Chrome and Safari) accept these non-standard protocol-relative sequences.

Bypass Response #2

Leave a Reply

Recent Comments