Information Disclosure – Redirect Debug Comment Exposure | Redirect Run
Lab Link
Lab: Redirect Run
Overview
Quikpay uses short receipt URLs that redirect customers to a friendly purchase confirmation page.
From a normal user perspective, the redirect happens instantly and nothing appears unusual. However, the intermediate redirect endpoint contains leftover production debugging information that was never removed before deployment.
By interacting directly with the redirect endpoint rather than simply following it in the browser, sensitive internal metadata becomes visible.
This results in information disclosure through exposed debug comments.
Objective
Inspect the receipt shortlink workflow, access the intermediate redirect endpoint, and recover sensitive information exposed through production debug comments.
Vulnerability Identification
Classification Hierarchy
A02 - Security Misconfiguration └── Exposed Debug Information └── Information Disclosure └── Sensitive Metadata in Redirect Response
Reconnaissance
Navigate to:
1
https://398ee607-4065-redirect-run-e0f27.challenges.webverselabs-pro.com/receipt
The page advertises a demo receipt shortlink:
1
2
3
<div class="url">
<a href="/r/qp-r4-7821ab">qp.link/r/qp-r4-7821ab</a>
</div>
The application encourages users to follow:
1
/r/qp-r4-7821ab
which appears to be a simple redirect mechanism.
Exploitation
Step 1 - Identify the Redirect Endpoint
Viewing the page source reveals:
1
<a href="/r/qp-r4-7821ab">qp.link/r/qp-r4-7821ab</a>
The receipt flow therefore passes through:
1
/r/qp-r4-7821ab
before reaching the final destination.
Step 2 - Intercept the Request
Capture the request in Burp Suite.
Original request:
1
GET /receipt HTTP/2
Modify it to directly request:
1
GET /r/qp-r4-7821ab HTTP/2
This allows inspection of the intermediate response rather than automatically following the redirect.
Step 3 - Inspect the Response
The response contains a hidden HTML comment:
1
2
3
4
5
6
7
8
9
10
<!--
─── Quikpay redirect debug (production safe? — TODO: strip before launch) ───
request_token: qp-r4-7821ab
upstream_status: 200
upstream_latency_ms: 38
internal_ref: WEBVERSE{.....}
reconciliation_window: 24h
cookie_strip_policy: strict
note: leave this in until QA signs off on the new tracing pipeline
-->
The comment exposes internal operational data that should never be returned to public users.
Step 4 - Extract the Flag
The flag is disclosed directly inside the debug block:
1
internal_ref: WEBVERSE{.....}
Flag:
1
WEBVERSE{.....}
Proof of Exploitation
Public Endpoint
1
/receipt
Redirect Endpoint
1
/r/qp-r4-7821ab
Exposed Debug Comment
1
2
3
<!--
internal_ref: WEBVERSE{.....}
-->
Flag
1
WEBVERSE{.....}
Impact
An attacker can discover:
- Internal identifiers
- Debug metadata
- Operational configuration
- Tracing information
- Backend implementation details
- Sensitive references
In production systems, similar disclosures have exposed:
1
2
3
4
5
6
API keys
Internal hostnames
Session identifiers
Customer references
Database information
Debug credentials
Such information frequently assists further attacks.
Mitigation
Remove Debug Artifacts Before Deployment
Development comments should never be present in production responses.
Separate Debug and Production Builds
Use dedicated build pipelines that automatically strip:
1
2
3
4
TODO
DEBUG
TRACE
DEV
content.
Avoid Exposing Internal Metadata
Information such as:
1
2
3
4
internal_ref
latency
backend status
tracing identifiers
should remain server-side.
Review Intermediate Responses
Security testing should include:
1
2
3
4
5
Redirect targets
API responses
Error pages
Source code
Comments
rather than only visible page content.
Conduct Release Reviews
Perform final production audits for:
1
2
3
4
Comments
Debug routes
Temporary features
Diagnostic output
before deployment.
Real-World Insight
Attackers often inspect pages that users rarely see directly:
- Redirect responses
- Error handlers
- Intermediate APIs
- Debug endpoints
These locations frequently contain leftover development information because teams focus on the visible application experience rather than every response returned by the server.
The Redirect Run challenge demonstrates a common security lesson:
Sensitive information does not need to be visible to be exposed. If it is sent to the browser, it is available to the user.