Listen to this Post
Introduction:
Cross-Site Scripting (XSS) remains a perennial threat in web application security, often stemming from subtle discrepancies between how servers and browsers interpret code. A critical vulnerability arises when sanitization mechanisms focus on exact pattern matching without considering browser parsing behaviors. Specifically, while many filters successfully block the classic `javascript:` scheme, they fail to recognize the `javascript://` variant. Because modern browsers treat the double slash (//) as a single-line comment indicator in a JavaScript context, the payload is ignored as code, resulting in a harmless empty execution that slips past server defenses to reach the client.
Learning Objectives:
- Understand the discrepancy between server-side regex filters and browser URI parsing.
- Learn how to construct and deploy `javascript://` payloads to bypass XSS filters.
- Identify mitigation strategies at both the application and WAF levels to prevent comment-based bypasses.
You Should Know:
- Anatomy of the Bypass: Server vs. Browser Interpretation
The core of this vulnerability lies in the interpretation of the URI scheme. Most server-side filters use regular expressions to block dangerous schemes likejavascript:. They look for the literal string “javascript:” followed by non-whitespace characters.
The Blocked Attempt:
javascript:https://google.com/`https`. It identifies this as a malicious scheme and blocks the request or sanitizes the output.
- Server Logic: The regex matches `javascript:` immediately followed by
– Result: Payload blocked.
The Bypass Attempt:
javascript://https://google.com/`//https://google.com/`. In JavaScript, `//` denotes a single-line comment. Therefore, the browser ignores everything after the double slash, executing an empty statement. The payload executes without error, effectively bypassing the filter and proving the XSS vector exists.
- Server Logic: The filter looks for `javascript:` followed by content. However, due to poor pattern matching (e.g., not accounting for the `//` characters), it fails to recognize `javascript://` as a variant of the same scheme. The payload passes through to the browser.
- Browser Logic: When the browser encounters this as an `href` or a redirect, it interprets the `javascript:` URI. The content after the colon is
2. Exploitation Scenarios in Hyperlinks
This vulnerability is most potent in areas where user input controls hyperlinks, such as comment sections, forums, or profile fields.
Step-by-step exploitation guide:
- Identify Injection Point: Locate a field that accepts a URL (e.g., “Website” field in a user profile) or allows link insertion via WYSIWYG editors.
- Craft the Payload: Use the structure
javascript://<any-text>. For example:javascript://%0aalert(document.domain)
Note: While `//` comments out the rest of the line, you can inject a newline (
%0aor\n) after the `//` to execute arbitrary JavaScript. The `//` comments out the `https://…` part, but the newline ends the comment, allowing the `alert()` to run. - Test the Payload: Insert the following into the vulnerable field:
<a href="javascript://%0aalert('XSS')">Click Me</a> - Execution: When a user clicks the link, the browser parses the URI. The `javascript:` scheme is triggered. The `//` comments out the `%0a` part? Actually, the URL decodes to:
javascript://\nalert('XSS')The `//` comments out until the newline. The `alert()` is on a new line and executes.
- Verification on Windows/Linux: You can test this locally by creating an HTML file and opening it in a browser.
<!-- test.html --> <a href="javascript://%0aalert('Bypassed')">Test Link</a>Open this file. Clicking the link will trigger the alert, demonstrating that the payload is functional.
3. Server-Side Filter Weaknesses (Code Analysis)
The vulnerability often originates from naive regex implementations. A filter might look like this (Python/Flask example):
import re
def is_safe_url(url):
Dangerous: Only blocks if "javascript:" is directly followed by non-// content
if re.search(r'javascript:', url, re.IGNORECASE):
Check if it's the classic pattern, fails to catch the comment variant
if not re.search(r'javascript://', url, re.IGNORECASE):
return False
return True
Test
print(is_safe_url("javascript:alert(1)")) False (Blocked - Good)
print(is_safe_url("javascript://alert(1)")) True (Allowed - Vulnerable)
Proper Mitigation (Secure Code):
Instead of blacklisting schemes, use a strict whitelist of allowed protocols.
from urllib.parse import urlparse
def is_safe_url_whitelist(url):
allowed_schemes = {'http', 'https', 'mailto', 'ftp'} No javascript
try:
scheme = urlparse(url).scheme
if scheme: If a scheme is present, it must be in the whitelist
return scheme in allowed_schemes
return True Relative URLs are usually safe
except:
return False
print(is_safe_url_whitelist("javascript://alert(1)")) False (Blocked)
4. Advanced Payload Obfuscation
To bypass more sophisticated filters that look for the `javascript` keyword, attackers can combine this technique with other obfuscation methods.
Case Manipulation & Encoding:
`JaVaScRiPt://%0aalert(document.cookie)`
Data URI Integration:
While the `//` comments out the rest, you can still execute complex code by placing it before the comment or using newlines.
Windows/Linux Command for Fuzzing:
Security researchers can use `curl` or custom scripts to fuzz parameters for this behavior.
Testing a parameter for the bypass using curl curl -X GET "http://vulnerable-site.com/page?redirect=javascript://%250aalert(1)"
Note: `%250a` is double URL-encoded (%0a). This tests how the server decodes the input before filtering.
5. Impact on Content Security Policies (CSP)
Even with a strong CSP, this attack remains relevant if `unsafe-inline` is present or if the application hosts user-generated content. A CSP directive like `script-src ‘unsafe-inline’` will allow the `javascript:` URIs to execute. Modern best-practice CSPs should use `script-src` with nonces or hashes and explicitly block inline script execution by omitting `unsafe-inline` and using `block-all-mixed-content` where appropriate.
CSP Header Example (Mitigation):
`Content-Security-Policy: default-src ‘self’; script-src ‘self’;` This prevents the execution of inline `javascript:` URIs entirely.
6. Cloud WAF Evasion Techniques
Cloud-based Web Application Firewalls (like AWS WAF, Cloudflare) often have managed rules for XSS. However, attackers can bypass them by exploiting the parser discrepancy.
Step-by-step WAF test:
1. Base Payload: `javascript:alert(‘XSS’)` -> Likely blocked.
- Comment Bypass: `javascript://alert(‘XSS’)` -> Might pass if the WAF rule doesn’t consider `//` as part of the scheme.
- Add Junk Data: `javascript://vulnerable.com/%0aalert(‘XSS’)` -> The WAF sees a benign looking domain (
vulnerable.com) in the path and may allow it, not realizing the browser will execute the `alert()` after the newline.
7. Hardening User Input Handling
Backend Validation (Python/Flask):
import re from flask import escape def sanitize_link(user_input): Step 1: Escape HTML entities escaped = escape(user_input) Step 2: Strip dangerous protocols aggressively This regex looks for any scheme followed by :// dangerous_pattern = re.compile(r'^\s(javascript|data|vbscript):', re.IGNORECASE) if dangerous_pattern.match(escaped): return "" Return a safe link return escaped
Frontend Validation (JavaScript):
function validateUrl(url) {
// Check if the URL starts with javascript: (case-insensitive)
if (/^\sjavascript:/i.test(url)) {
console.warn('Blocked JavaScript URI');
return false;
}
// Also block the bypass variant
if (/^\sjavascript:\/\//i.test(url)) {
console.warn('Blocked JavaScript comment bypass');
return false;
}
return true;
}
What Undercode Say:
- Key Takeaway 1: Input validation must be context-aware. A filter that works for the server may be completely useless to the client. Security must be tested in the browser, not just the backend logic.
- Key Takeaway 2: Whitelisting safe protocols (HTTP/HTTPS) is vastly superior to blacklisting dangerous ones. The `javascript://` bypass perfectly illustrates how attackers exploit what filters don’t look for.
The `javascript://` bypass is a classic example of how small parsing nuances can lead to critical security flaws. It underscores the necessity for developers to think like browsers, not just like regex engines. Relying on pattern-based blocking is a losing battle; instead, applications must enforce strict structural policies regarding what constitutes a valid URL.
Prediction:
As web applications increasingly rely on client-side rendering and complex frameworks, parser confusion attacks will escalate. We predict a rise in “JavaScript scheme smuggling,” where attackers combine `javascript://` with Unicode normalization and newline encoding to bypass next-generation WAFs that still rely on token-based pattern matching rather than emulating full browser parsing behavior.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Aidilarf28 Xss – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
