1

I know what I just described is a reflected XSS vulnerability. What I can't figure out is why it is a vulnerability. Because the way I see it, a user can't be directed to the attacker's content because the AJAX is executed without a page refresh or a URL change. What am I missing here?

-- EDIT --

To edit the question and provide a little more context, I'm trying to figure out how echoing un-sanitized data from AJAX into the page would be a bad thing. Because here is how I see XSS vulnerabilities:

  1. JavaScript from an uncontrolled source (ie attacker) is allowed to insert JavaScript into the page.

  2. The user is navigated to the said page with the evil JavaScript embedded in the page.

  3. Exploit happens (cookies are stolen, user logins over an attacker made login screen, etc...)

I can't see how this is a problem with AJAX. Because the request is made in the page and you (as the attacker) can't direct a user to a page where part of the content was loaded with AJAX.

Or, in other words, you can't perform a search query on a search engine that uses AJAX to query a remote endpoint and display the results on the page, then direct a user to that page with those results shown. The results would disappear.

What am I missing here?

Adam McGurk
  • 73
  • 8

2 Answers2

2

Your first point ("JavaScript from an uncontrolled source (ie attacker) is allowed to insert JavaScript into page.") is a wee bit off. If a page already contains JavaScript from an attacker, the attacker has already won.

A more accurate description of a reflected XSS attack is:

  1. User is navigated to a page that accepts input from the user such that the user unwillingly supplies some of the input.
  2. JavaScript from a controlled source (i.e., the web application developer) takes data from user input an inserts it into the page.
  3. The user input from Step 1 is interpreted as JavaScript (cookies are stolen, etc.).

To provide an example of how your scenario might work, consider a web application that lets users bookmark search results by putting the search term into the query string: https://my-custom-search-engine.tld/search?term=reflected%20xss

Upon loading the /search page, JavaScript on the page reads the query parameter term and makes an AJAX request. Upon receiving the response, JavaScript on the page reads the search term part of the response object and injects it into the page using a vulnerable method. (See the answer of @dandavis for jQuery's .html, or https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet#Example_Dangerous_HTML_Methods for some other dangerous methods.)

In this example, an attacker would have to trick a user into visiting https://my-custom-search-engine.tld/search?term=<script>alert(1)</script>.

PlasmaSauna
  • 574
  • 3
  • 6
  • So I guess what my question would be here, is what about when the search term isn't in the URL? What about when searching is based on a request being sent on a JavaScript event that fires on `keypress` and nothing is passed through URLs? – Adam McGurk Aug 02 '18 at 17:58
  • 1
    Consider social engineering. If an adversary tells users, "See the search results my-custom-search-engine doesn't want you to see!!! Copy and paste this into the search box: – PlasmaSauna Aug 04 '18 at 03:40
1

it depends on what the app does with the ajax return. for example, jQuery's $(selector).html(ajaxContent) Will call eval() (or an equivalent) on strings in the response between <script> and </script>, under certain mime-types. Obviously, that executes arbitrary code which can steal cookies, redirect to bad places, attempt to drive-by download malware, you name it.

dandavis
  • 2,658
  • 10
  • 16
  • It takes a response from the server, plus the original payload (so the attacker JavaScript) and outputs it on the screen – Adam McGurk Jul 26 '18 at 19:41