What are the possible attack vectors for reflected cross site scripting?_问答_开发者

Wikipedia provides information about one of the most common scenarios for exploiting a reflected cross site scripting attack - using some degree of social engineering to induce unsuspecting users to click a malicious link:

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.

Mallory observes that Bob's website contains a reflected XSS vulnerability.

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, but will contain Mallory's malicious code, which the website will reflect.

Alice visits the URL provided by Mallory while logged into Bob's website.

The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's开发者_StackOverflow 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.

Now, this is usually tends to be very good example when the website happens to be a page-driven application - the vulnerability is exploited by getting the user to submit a malicious payload to the application (more importantly, by issuing a GET request when logged in) which is reflected back in the response.

Are there any more interesting attack vectors, especially ones to consider when the application utilizes a lot of AJAX with most of the requests being made over HTTP POST?

EDIT

In case I wasn't clear, I'd like to know the various types of attacks vectors applicable to reflected XSS attacks, especially when the client-side tier of the application is implemented differently. Page-based applications would have an attack vector involving HTTP GET requests issued from a user, but it would be interesting to know how this plays out for thick client applications especially the ones using XMLHttpRequest objects that issue HTTP POST requests. Different mechanisms used in client-side rendering will obviously warrant study of different attack vectors. In some cases, there might not be any applicable attack vectors; the question is expressed to elicit such a response.

Yes, in fact there are a few variations on the reflective XSS attack. Mostly notibly is the Samy Worm. In short Samy used XSS to fire off an XHR to MySpace.com to read the CSRF token and forge POST request. In fact this is a general attack pattern that is useful for attacking sites that are using httponly cookies. As the use of httponly cookies becomes more popular, so will this attack pattern.

Another xss payload is the XSS Shell. This provides the attacker an interactive channel to the browser.

XSS is used to deliver a "Drive-By-Download" attack.

Xss can also be used to fake the news. With xss against news sources regularly being found, this is a rather serious problem.

Edit: You might also be interested how the Apache foundation got owned using xss and tinyurl. Here is an exploit that I wrote which uses a Samy style attack in order to obtain CSRF.

benlbroussard touched on this already, but I want to reiterate it because of the importance. Fat client, thin client, POST, GET, PUT; none of these things matter. An XSS hole is based on a site incorrectly rendering some input back to somebody.

If you're looking for a strictly reflected attack then the payload shouldn't be stored anywhere in the target app. In that case I think you're right that a fat client will trend towards being more resistant because a GET is the easiest ways to initiate a reflected XSS attack.

Regarding more attack vectors, one interesting thing about fat client architecture is entity encoding. A thin client can entity encode everything and be done with it, with great benefit. A fat client should entity encode the response to an initial GET, but asynchronous requests with replies headed for JavaScript can't be (entirely) encoded and be valid JS. This back and forth increases the chance of not encoding something that should be, which is a big step towards creating an XSS vector.

Make sense?

Carl

Reflected XSS occurs when a page displays malicious user input. The question "what attack vectors are there?" is therefore synonymous to "what user input can a page receive?"

Some sources are:

The query string of a GET request which can come from:
- a URL in an email
- a redirect (via js, 301 response, or meta tag) from a hacked or malicious site
The body of a POST request which can come from:
- an AJAX POST request from any domain (Same Origin Policy doesn't stop the request, just parsing the response)
- Any form with method="POST" and action="XSSed_site.com". Forms can be posted via js, or by clicking on a button which could be done using click-jacking.
Other forms of input such as:
- external js files like table sorters or libraries that the attacked page is using
- server-to-server communication that is displayed on the attacked page
- any other data displayed on the page being attacked that can be altered by the attacker

I realize that the "Other forms of input" section looks more like a stored XSS vulnerability, but each application is unique, and some may translate user input into how external pieces are composed into the page (hence reflected).

A query string in a GET request from a phished email is certainly not the only vector for reflected XSS (good question though).