Full Report
While reviewing the application, the author of the post found a self-XSS vulnerability. Normally, this doesn't have any impact on other users but they wanted to create it. Thus starts the chain! The application was vulnerable to login/logout CSRF. So, any user could be forcibly logged into or out of their account. With the login CSRF and XSS, it's possible to execute code within the context of the users account. But, that's not very helpful... so now what? Browsers have a Path attribute. If two cookies share the same name then the one with the most accurate path information is used on the request. This doesn't entirely do much because we can't set the cookies path directly. So, they created a bot that would login, copy the cookies and store them at a URL. Once the creds were needed, the XSS payload could set the cookie at a direct path. This bypasses the issue around the HTTPOnly cookie but still allows for the attacker and user to be logged in at the same time. Here's the full chain: Victim visits the attackers page. Gets hit by login CSRF to attackers account. This includes a redirect to the page with self-XSS. XSS triggers on the page. Attacker gets their cookie information and sets at the settings/phone path. Logout CSRF. Victim logs into their normal account, which redirects back to the page with the XSS once again. There are now two active cookies depending on the page. So, this allows for the page to have the XSS from the attackers account to make API requests with the victims cookie to another account. Overall, a pretty nifty set of tricks! I had never thought of having a bot get credential information for me and manually setting the token data. But, this actually worked pretty well!
Analysis Summary
# Vulnerability: Account Takeover via Login CSRF, Self-XSS, and Cookie Tossing
## CVE Details
- **CVE ID**: Not Assigned (Individual Researcher Finding)
- **CVSS Score**: 8.3 (High) - *Estimated based on Account Takeover (ATO) impact.*
- **CWE**:
- CWE-79 (Cross-site Scripting)
- CWE-352 (Cross-Site Request Forgery)
- CWE-1059 (Self-XSS)
- CWE-629 (Cookie Tossing via Path Attribute)
## Affected Systems
- **Products**: Unspecified .NET Web Application
- **Versions**: Unknown/Current at time of report (Dec 2025)
- **Configurations**:
- Application allows alphanumeric-only validation on some endpoints but fails on others (Profile Edit vs. Add).
- Application lacks CSRF protection on Login/Logout endpoints.
- Application allows multiple concurrent sessions.
## Vulnerability Description
The vulnerability is a complex chain that upgrades a "Self-XSS" (usually considered low impact) into a full Account Takeover (ATO).
1. **Self-XSS**: Found in the "Edit Phone Number" feature. The server failed to sanitize input, allowing for persistent script injection that only triggers when the user views their own settings.
2. **Login/Logout CSRF**: The application lacks anti-CSRF tokens on authentication endpoints. An attacker can force a victim's browser to log out of their session and log into an attacker-controlled account.
3. **Cookie Tossing (Path Specificity)**: Browsers prioritize cookies with more specific `Path` attributes. By setting a cookie with `Path=/settings/phone`, the attacker ensures the browser sends "Attacker" session cookies to the XSS-vulnerable page while sending "Victim" session cookies to all other pages (at `Path=/`).
4. **HttpOnly Bypass**: Because `HttpOnly` prevents reading cookies via JS, the attacker uses an external bot to log into the attacker account, scrape the cookies, and host them on a public endpoint. The XSS payload then fetches these "fresh" cookies and writes them to the browser's document context with the specific path.
## Exploitation
- **Status**: PoC available/verified by researcher.
- **Complexity**: High (Requires chaining four distinct behaviors and hosting external infrastructure).
- **Attack Vector**: Network (Requires victim to visit a malicious link).
## Impact
- **Confidentiality**: High (Access to all victim data and API responses).
- **Integrity**: High (Ability to perform actions on behalf of the victim).
- **Availability**: Low (The attack focuses on session hijacking, not denial of service).
## Remediation
### Patches
- No specific vendor patch version provided. Users of the affected (unnamed) application should ensure they are on the latest software version.
### Workarounds
- **Implement Anti-CSRF Tokens**: Ensure all state-changing requests, including login and logout, require a unique, unpredictable token.
- **Sanitize User Input**: Apply rigid server-side validation and output encoding to all profile fields, especially the "Phone Number" edit functionality.
- **Strict Cookie Attributes**:
- Use the `__Host-` prefix for session cookies to prevent cookie tossing and path-based shadowing.
- Use `SameSite=Lax` or `Strict` to mitigate CSRF.
- **Enforce Headers**: Use `Content-Security-Policy` (CSP) to prevent the execution of inline scripts and restrict data exfiltration to unauthorized domains.
## Detection
- **Indicators of Compromise**:
- Repeated Login/Logout events from the same IP with different user contexts.
- Presence of `<script>` tags or unusual payloads in user profile fields.
- Outbound requests from the client browser to unknown third-party domains (e.g., `attacker[.]com/cookies`).
- **Detection methods**: Web Application Firewalls (WAF) should be configured to flag XSS patterns in profile update requests.
## References
- Researcher Post: hxxps://aretekzs[.]com/posts/from-self-xss-httponly-cookies-and-no-iframes-to-ato/