Figure 1: Challenge description

The hints for this challenge suggests that an Open Redirection exploit is present in the input fields of the website shown below (figure 2).

Figure 2: Web portal interface

Mitre’s database lists Open Redirect as CWE-601 and confirms a lack of input validation as a cause, where a malicious input could lead to the browser navigating to an URL of the adversary’s choosing, leading to more severe follow ups such as phishing and download of malware.

As the inputs of username and password then submitting them generates a HTTP POST request to send data to the server and update its information, a relevant tool here to use would be Burp Suite. Portswigger’s official documentation[1] contains description on how to analyze for redirections. The idea being to use Burp’s Proxy interceptor to capture the HTTP POST request then send it to the Repeater.


The website URL link is opened with the Burp Suite browser. The intercept is then turned on. Per instruction, the username of “test” and password of “test!” were entered into the webpage.

When submitted, the browser navigates to the following site.

Figure 3: Interface of redirected site.

The login submission’s HTTP POST request was captured by Burp’s Proxy Interceptor during this. The first interesting finding is that there was a HTTP 302 found status code (figure 4), suggesting that a redirection has taken place.

The second interesting finding is that the beginning part of the flag has already been revealed in the response to the POST request. The last line of the HTTP 302 response contains an anchor element indicating the URL of the website it is redirecting the browser to. In the URL, the id contains the base64 encoded string “cGljb0NURntwcm94aWVzX2Fs” (figure 4) which Burp helpfully decoded as “picoCTF{proxies_al”

Figure 4: The HTTP POST request intercepted and its response, without following redirections.

This request was then sent to the Repeater field, which had the “Follow redirections” option changed from ‘Never’ to the “On-site” option (figure 5) as in this particular instance both sites are from the domain of

Figure 5: Turning the follow redirection on in Burp’s Repeater.

After this, clicking ‘Send’ button resubmitted the POST request, the response now contained new data (figure 6). Namely a snippet of HTML showing the Javascript function, setTimeout() [2], which calls the window.location object after a defined time gap, 2 seconds in this case. In Javascript, the window.location redirect to a new specified URL [3].

Figure 6: The HTTP POST request intercepted and its response, after following redirections.

That the redirect URL in the updated HTTP response (figure 6) contains the the base64 encoded id string of “bF90aGVfd2F5X2EwZmUwNzRmfQ==” which Burp Suite decoded as “l_the_way_a0fe074f}”

The full flag is therefore the 2 parts combined which turns out to be:



[1] “Repeater settings,” (accessed Mar. 31, 2023).

[2] “Window setTimeout() Method,”, 2019.

[3] “JavaScript Window Location,”, 2019.

You Might Also Like

Leave a Reply