🔓 Free Link

Table of Contents

1. Summary of the Vulnerability
2. Proof of Concept (PoC)
3. Impact

Summary of the Vulnerability

DOM-based open redirection is a client-side vulnerability where redirection logic is handled entirely in the browser using JavaScript and relies on untrusted data from the URL.

In this lab, the application includes a "Back to Blog" link that processes the current URL using a regular expression and extracts a url parameter directly from location. The extracted value is then assigned to location.href without validation.

The relevant logic can be summarized as follows: the script reads the current URL, attempts to match a pattern like url=https://…, and if a match is found, redirects the browser to that value.

Because this happens purely in the DOM and not on the server, traditional server-side protections are bypassed. An attacker who can control the url parameter can force the browser to navigate to an arbitrary external domain.

Proof of Concept (PoC)

Steps to Reproduce

• Open the lab and take one of the available blog articles.

• Attempt to submit a blog comment containing a redirection payload, for example pointing to google.com.

• After submitting the comment, observe that the injected payload is not executed. This indicates that server-side input handling is not directly vulnerable to script execution in this context.
• Next, view the page source and scroll toward the bottom of the HTML document.
• Identify the JavaScript logic responsible for handling client-side navigation. The script extracts a value from the current URL and assigns it to location.href without proper validation.

• At this point, it can be assumed that if an attacker gains control over the URL value processed by this script, an open redirection condition can be triggered, allowing redirection to an external, attacker-controlled destination.
• Since the lab requires the use of the exploit server, copy the exploit URL provided by the lab environment:

https://exploit-0a92005c047ba8de808e114101b0005b.exploit-server.net/exploit

• Modify the target request by appending a url parameter containing the exploit server link:

https://0a98002d04faa8ec80e212d3003d003b.web-security-academy.net/post?postId=9&url=https://exploit-0a92005c047ba8de808e114101b0005b.exploit-server.net/exploit

• Load the modified URL in the browser. The client-side script processes the injected url parameter and redirects the browser to the exploit server.
• Verify successful exploitation by checking the Access log on the exploit server, where the incoming request from the victim is recorded.

• With the redirection confirmed, the lab is successfully completed.

Impact

In production systems, DOM-based open redirection is often underestimated because it does not involve server-side logic. In practice, it can be just as dangerous. Attackers can weaponize trusted domains to deliver phishing campaigns, credential harvesting pages, or malware downloads. Since the redirection originates from a legitimate website, users are far more likely to trust the link and proceed.

📢 Enjoyed this post? Stay connected! If you found this article helpful or insightful, consider following me for more:

• 📖 Medium: bashoverflow.medium.com
• 🐦 Twitter / X: @_havij
• </> Github: havij13
• ☕ Coffee: Ko-fi

🙏Your support is appreciated.