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?

Improve this question

4 Answers 4

Reset to default
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
Improve this answer
8
  • 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.
    – kingsfoil
    Commented May 1, 2017 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
    Commented May 1, 2017 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.
    – kingsfoil
    Commented May 1, 2017 at 15:45
  • 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
    Commented May 1, 2017 at 15:57
  • 1
    @0112, It's community wiki now. Edit away.
    – Mike Samuel
    Commented May 1, 2017 at 18:07
13

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.

Improve this answer
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

Improve this answer
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.

Improve this answer
1
  • 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
    Commented May 19, 2015 at 15:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .