What is Self XSS

Self-XSS (Self Cross-Site Scripting) occurs when an attacker tricks a user into pasting malicious JavaScript into their browser's developer console, executing it in their own context. It’s rarely exploited because it relies heavily on social engineering and user interaction, and modern browsers display warnings against pasting untrusted code. However, attackers can still exploit this!

Exploit Self-XSS

Technique 1

• On your server, create a Cross-Site Request Forgery (CSRF) that automatically logs the victim into the attacker’s account. Use redirection parameters to send the victim to the page where the self-XSS is located (or open a new window). The self-XSS should perform the following actions:

  • Capture the attacker's cookies.
  • Save the cookies to local storage.
  • Clear all cookies to log out the admin upon page refresh. (For HTTP-only cookies, use a Cookie Bomb.)
  • Set the attacker's cookie with a specific path, such as /index.php (preferably where the self-XSS is located), ensuring the cookie takes precedence over others due to its specificity.
  • Redirect the victim to the login page to re-authenticate. (Include redirection parameters to deploy the self-XSS immediately.

• Victim visiting /index.php and the following happen:

  • Upon logging in, the admin accesses /index.php, loading the page with the attacker's cookies.
  • The self-XSS script executes again, with a condition such as checking for a cookie named admin.
  • The self-XSS script exfiltrates all cookies, both the attacker’s and the admin’s.

Technique 2

• On your server, create a Cross-Site Request Forgery (CSRF) that automatically logs the victim into the attacker’s account. Use redirection parameters to send the victim to the page where the self-XSS is located (or open a new window). The self-XSS should perform the following actions:
• Create an iframe that takes up the entire window and insert a URL so that the iframe displays the login page. (You might need to hit the logout endpoint first.)
• Let the user log in, and voila!

Since the iframe and the webpage running the iframe have the same origin (and considering that iframes from the same origin are allowed), you should be able to fetch any information from the iframe during the period the user is using it. This means that if the user logs in, you can use a keylogger to retrieve the information typed. Additionally, you can fetch any information on the HTML page rendered in the iframe (such as API keys, CSRF tokens, etc.).

Technique 3 (Need Review)

• On a server, create a button that clearly encourages user interaction, such as a fake cookie popup or a button that takes up the entire page.
• When clicked, this button should open a new window directing to a sensitive page on the target domain containing sensitive information (e.g., API keys). In this situation we assume that the victim was already logged to their account
• Simultaneously, use the same button action to redirect the current page (original server page) after a few seconds. This should perform a Cross-Site Request Forgery (CSRF) into the attacker account, and redirect the victim to the Self-XSS.
  • Utilize redirection parameters on the login page (CSRF) to redirect the victim to the Self-XSS location.
• At this point, you should have two windows: one performing the self-XSS and another containing sensitive information (Still logged has the victim were there is sensitive information).
• Since both pages now share the same domain, you can fetch using the Self-XSS (from the attacker account) the content of the sensitive information page (From the victim account) as it is no longer cross-site.
• Ensure not to refresh the page, as it will reload using the attacker's account.
• By doing this, you will have the possibility to extracted sensitive information using the self-XSS and CSRF.