3

I was wondering how many different methods exist for executing XSS attacks.

In just about every demonstration I see, the attack is triggered in one of the below 3 ways:

  1. By entering the script into an input field. The front-end then uses that input to populate a request, which it is already designed to perform. The script input gets returned in the request's response and then gets executed if the front-end then adds it to the DOM.
  2. By entering the request in the url bar. This works only with GET requests. If one of the parameters has a script for input and if the parameter is visible (as html) in the response the response page will execute it.
  3. By providing an unwitting user with a link. If the user mistakenly clicks the link, they will inadvertently execute the process described in #2.

Are there any other ways it is done? Are there any resources that describe other ways of it happening?

Also, if the website uses session tokens for each login, is there anyway to get that token included using methods 2 and 3? Or do session tokens protect us from these approaches?

1

Point 1. is more of a (DOM-based) self-XSS issue. And as you said, point 2. and 3. are really the same (the attack happens by visiting a URL).

A GET request via a link is the most common way to execute an XSS attack. The link could for example be send to a victim via email or posted in a forum.

But there are other ways. The defining characteristic of reflected XSS is that input is reflected, meaning that the server takes some sort of value from a HTTP request, inserts it into a HTML context in the response, and the browser then renders that response, thus executing the injected code.

POST-based reflected XSS

Reflected XSS can also be performed via POST requests (which are not protected from CSRF). Eg:

<form action="https://example.com/vulnerable" method="POST">
    <input type="hidden" name="number" value="[XSS payload]" />
</form>
<script>document.forms[0].submit();</script>

In the same manner, a GET request could be send via a form (by changing the method to GET). An attacker might choose this approach if a POST request is required, or if they think that it is more likely that a user visits a page where they can post scripts, and less likely that they will click on a link to the victim site.

Exploiting Self-XSS

Your point 1. might be exploitable if the site is frameable. Some browsers - eg Firefox last I checked - allow the dragging of text into iframes (not out of them though).

By performing a clickjacking attack, an attacker could get a victim to "enter" the XSS payload and execute it.

Another way to execute a self-XSS would be to simply ask the user to post the payload ("can you post this long, HTML formatted post [containing an XSS payload] to your website?", "Can you upload this harmless image [whose filename contains an XSS payload] to your blog?", etc).

Session tokens as (non-) protection

do session tokens protect us from these approaches?

If your session tokens are always included in the URL, and the page doesn't reflected any input when the session token is missing (and the session token is securely generated), then that would indeed protect against (non-self) reflected XSS that send a victim a malicious link. In the same manner CSRF tokens protect requests against (non-self) reflected XSS.

However, now you have a new problem. Sensitive data in URLs is strongly discouraged. It can easily leak via referers, when users share links, etc. And once that happens, anyone could have access to that users account.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.