Vulnerability Open Redirect via Userinfo (@) URL Parsing

linkResolution: ❌

Not valid

This is not an open redirect, nor is it in Amplenote control, e.g. https://www.google.com@amplenote.com/


linkReport

Title
Open Redirect Vulnerability via @ (Userinfo) URL Parsing
 
Target
URL: https://www.amplenote.com
 
Vulnerability Type
Open Redirect
 
Severity
High
 
Description
The application is vulnerable to an Open Redirect attack due to improper validation of URLs containing the userinfo (@) component. By appending a crafted payload after the trusted domain, an attacker can cause users to be redirected to an attacker-controlled website.
 
The browser interprets everything before the @ symbol as the username (userinfo), while the hostname after @ becomes the actual destination. If the application does not properly validate or sanitize such URLs, users may believe they are navigating to a trusted Amplenote URL when they are actually redirected to a malicious domain.
 
Proof of Concept
Payload:
 
https://www.amplenote.com<whitelisted-domain>@attacker.com
Example:
 
https://www.amplenote.comexample.com@attacker.com
Observed Behavior
 
The application redirects the browser to:
 
https://attacker.com
instead of remaining on the trusted domain.
 
Steps to Reproduce
Visit the vulnerable endpoint that processes or redirects user-supplied URLs.
Append the following payload:
https://www.amplenote.com<whitelisted-domain>@attacker.com
Submit the request.
Observe that the application redirects to attacker.com.
The browser treats everything before @ as user information and uses the domain after @ as the actual destination.
Expected Behavior
The application should:
 
Reject URLs containing the userinfo (@) component.
Validate the hostname after parsing the URL.
Only allow redirects to explicitly approved domains.
Prevent redirects to external or attacker-controlled domains.
Actual Behavior
The application accepts the malicious URL and redirects users to an external attacker-controlled website.
 
Security Impact
This vulnerability can be abused in several ways.
 
1. Phishing Attacks
Attackers can craft convincing URLs that appear to belong to Amplenote while redirecting victims to malicious websites designed to steal credentials.
 
Example:
 
https://www.amplenote.comtrusted-site@evil.com
Many users will only notice the trusted domain at the beginning and may not recognize the actual destination.
 
2. Credential Theft
Victims can be redirected to fake login pages that closely imitate Amplenote, allowing attackers to capture usernames, passwords, MFA codes, or recovery information.
 
3. Malware Distribution
Users may be redirected to pages hosting malicious downloads, ransomware, browser exploits, or fake software updates.
 
4. OAuth and Authentication Abuse
If the application uses redirects during authentication flows, attackers may abuse the vulnerability to interfere with OAuth or SSO processes, increasing phishing success.
 
5. Brand Reputation Damage
Users associate the malicious redirect with Amplenote because the crafted URL begins with the legitimate domain. Successful phishing campaigns can reduce customer trust and harm the company's reputation.
 
6. Social Engineering
Attackers can distribute the malicious URL through:
 
Email phishing
SMS phishing (Smishing)
Messaging applications
Social media
QR codes
Since the URL begins with the trusted domain, victims are significantly more likely to trust it.
 
Business Impact
Successful exploitation may result in:
 
Theft of customer credentials
Account compromise
Financial fraud
Increased phishing success rates
Loss of customer confidence
Damage to Amplenote's brand reputation
Increased customer support and incident response costs
Potential compliance and regulatory concerns if user data is exposed
Root Cause
The application validates redirect URLs using string matching rather than parsing the URL according to RFC 3986. As a result, the hostname after the @ character is not properly validated, allowing attackers to bypass whitelist restrictions.
 
Remediation
Parse URLs using a secure URL parser before validation.
Validate the parsed hostname rather than checking whether the string starts with or contains a trusted domain.
Reject URLs containing the userinfo (@) component unless explicitly required.
Maintain a strict allowlist of permitted redirect destinations.
Use relative URLs whenever possible for internal redirects.
Log and monitor blocked redirect attempts for abuse detection.
References
CWE-601: URL Redirection to Untrusted Site ("Open Redirect")
OWASP Unvalidated Redirects and Forwards Cheat Sheet
RFC 3986 Uniform Resource Identifier (URI): Generic Syntax
Suggested CVSS v3.1
Score: 7.4 (High)
 
Vector:
 
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:H/A:N
CVSS Justification
 
Attack Vector (AV): Network
Attack Complexity (AC): Low
Privileges Required (PR): None
User Interaction (UI): Required (victim clicks the crafted link)
Scope (S): Changed
Confidentiality (C): Low
Integrity (I): High
Availability (A): None