21

What is the danger of Reflected Cross Site Scripting?

I understand the Reflected XSS is dangerous, because it's possible. But what practical attacks can be performed using Reflected XSS?

curiousguy
  • 5,028
  • 3
  • 25
  • 27
Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196

4 Answers4

13

You can do a lot when you can inject code into a page. For example, you can

  1. steal credentials in non-HTTPOnly cookies.
  2. send requests to a server with the user's credentials. Think XSRF
  3. steal secrets that are stored in JS variables.
  4. prompt the user to download content by submitting a form
  5. display text that seems to come from the site owners. Think phishing.
  6. display a password input, log keystrokes, and send the result to a site of your choosing
  7. redirect to another site
  8. get GPS/camera data if the user has granted that site access to the device
Mike Samuel
  • 3,873
  • 17
  • 25
  • 1
    The attack vectors you list here are completely valid. However, the OP is asking what exploits he can do using reflected XSS. Your answer does not specify how you would use these particular attacks with a reflected attack. Your answer becomes useful to the OP only after reading dr jimbobs answer below where he specifies how these attacks would actually be carried out. I would give it an upvote if you were to add that information. – 0112 May 01 '17 at 15:24
  • @0112, I'm not sure I understand. Reflecting is a way to get code to run in a browser under an origin you don't control without persisting the payload in any server side storage. The means of reflecting (getting user to click on crafted URLs, x-origin iframes, etc.) a payload seem orthogonal to what that payload can do and the OP seems more related to "why should I care?" than "what can I do about it?". – Mike Samuel May 01 '17 at 15:33
  • In the OPs own words: "But what practical attacks can be performed using Reflected XSS?" The examples you list are all completely valid and practical. Your answer is great on a technical level. Your examples only become useful to a new reader of this question when they understand how a malicious URL could be delivered. The examples you list could be equally applied to a persistent XSS vuln. Whereas the question asks specifically how a non-persistent vulnerability could be exploited. – 0112 May 01 '17 at 15:45
  • I'm not trying to nit-pick your answer. I personally think it becomes more valuable within the context of delivering the malicious code. – 0112 May 01 '17 at 15:48
  • I saw that sentence. Partial answers could include "An attacker can trick a user into clicking a crafted link on a forum that includes a query parameter that is echoed unescaped" which gets at how, or "an attacker could steal non-httponly cookies" which gets at why, or the cross-product of how x why. I can do the cross product but I'm not convinced you're right about their intent and they declined to ask for more. – Mike Samuel May 01 '17 at 15:54
  • 1
    @0112, nit-pick if you like :). Alternatively, post a more complete answer and I'll upvote. Or I can communitize this answer if you want to supplement. – Mike Samuel May 01 '17 at 15:57
  • ^^ You are probably correct about the OPs intent. As a new reader of this question, I was initially confused - but was able to get more out of your answer once I understood the context of how the attack would be delivered. Whichever you prefer. I'm fine communitize-ing. But I've never done so before and I'm unfamilliar with the process. – 0112 May 01 '17 at 16:22
  • 1
    @0112, It's community wiki now. Edit away. – Mike Samuel May 01 '17 at 18:07
12

The wikipedia article does it great justice:

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the request.

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.

...

Non-persistent (aka reflective):

  1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information.
  2. Mallory observes that Bob's website contains a reflected XSS vulnerability.
  3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website (either directly or through an iframe or ajax), but will contain Mallory's malicious code, which the website will reflect.
  4. Alice visits the URL provided by Mallory while logged into Bob's website.
  5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). The script can be used to send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc.) without Alice's knowledge.

Do you have any questions about it?

The standard XSS defense work against it; e.g., sanitize untrusted user input; e.g., only let them insert a small subset of HTML (from a safe limited markup language) or pass through a good html sanitizer/purifier, don't use unsafe patterns in scripts (e.g., eval in javascript on user input), ideally use a browser with CSP and sandboxing, etc.

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
4

From OWASP:

Reflected XSS Attacks: Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server.

What this means is I can put malicious code as part of the query parameters (the part of the url after the ampersand or question mark. I can send out a malicious email, use bit.ly or similar, or combine with other attacks to get you to make a unintended request, which is not filtering for the XSS.

In terms of attacks, Phishing is going to be the big one, get someone to trust my evil link. This type of attack can also be combined with CSRF or any of a number of attacks, any time and attacker can get another site to run their code, and you to run the page with javascript enabled, its going to be bad.

Some links

Eric G
  • 9,691
  • 4
  • 31
  • 58
3

I recommend you take a look at BeEF - The Browser Exploitation Framework http://beefproject.com/ It's basically a tool for showing the dangers of XSS. By using a reflected or persistent XSS attack, beef hooks into the given web site, and allows the attacker control over the browser on the given page. BeEF integrates with Metasploit, which allows an attacker to send browser exploits etc. to the user's browser. You can steal data, steal sessions etc. There are some decent videos on there as well.

Anything BeEF can do, attackers can also do. XSS can be pretty bad.

Erlend
  • 2,195
  • 14
  • 13
  • I wanted to say this. Whenever developers or owners of web applications try to minimize the dangers of Reflected XSS, I show them BeEF at work on their site. – mcgyver5 May 19 '15 at 15:13