What is the danger of Reflected Cross Site Scripting?

Question

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?

Answer 1

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

Answer 2

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

• http://deadlytechnology.com/web-development/xss/

Answer 3

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.

Answer 4

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.