I work programming Enterprise Java applications and do very little web development in 2002. I'm interested in security and like to read articles about it. However, I never fully understand how XSS works. Can you explain it to me or pointing some resource to read? The Wikipedia article give me a good idea but I don't think I understand it very well.
closed as too broad by Eric G, Xander, TildalWave, Iszi, AJ Henderson May 14 '14 at 14:34
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
XSS - Cross Site Scripting (but not limited to actual cross site scripting)
XSS is usually presented in 3 different ways:
Non-persistent (often called reflected XSS)
This is when you are able to inject code and the server returns it back to you, unsanitized. Often this can be exploited by distributing an (usually innocent looking) URL in some form or way for others to click on.
This can be particular effective when you're dealing with focused attacks against someone. As long as you can make someone click the URL you sent there is a chance you can gain elevated privileges on the system.
A site containing a search field does not have the proper input sanitizing. By crafting a search query looking something like this:
Sitting on the other end, at the webserver, you will be receiving hits where after a double space is the users cookie. You might strike lucky if an administrator clicks the link, allowing you to steal their sessionID and hijack the session.
Using techniques like spam email, message board posts, IM messages, Social Engineering Toolkits this vulnerability can be very dangerous.
Of course criminals would modify the URL to make it more innocent looking. The same payload as above just encoded differently:
You can even mask it better when sending to email clients that support HTML like this:
Once you are able to persist an XSS vector the attack becomes much more dangerous very fast. A persistent XSS is reflected back to you from the server, usually because the XSS has been stored in a database field or similar. Consider the following input is stored to database and then presented back to you on your profile:
If you are able to make the application accept and store unsanitized input, all you have to do is make other users view your profile (or where the XSS is reflected back).
These kinds of XSS can be not only hard to spot, but very devastating to the system. Just take a look at the XSS worm called Samy worm!
In the early days of XSS you saw this kind of exploit all over guestbooks, communities, user reviews, chat rooms and so on.
Two attack vectors
Now that you know the different ways of delivering a XSS payload I'd like to mention a few XSS attack vectors that can be very dangerous:
Sorry about the long post. I'll stop now. As you can see though, XSS is a very big topic to cover. I hope I made it a bit clearer for you, though.
Exploiting XSS with BeEF
To easy see how XSS can be exploited I recommend trying out BeEF, Browser Exploitation Framework. Once it's unpacked and run on a webserver with PHP support, you can easily try spawning a simulation of a victim (called a zombie) where you can very easy try out different XSS payloads. To mention some:
The list goes on. Recommend seeing the video on the BeEF homepage.
UPDATE: I've done a write up on XSS on my blog which describes XSS. It contains a bit about the history of XSS, the different attack types and some use-cases including BeEF and Shank.
To piggy-back on what SteveSyfuhs said, there are many possible malicious ways XSS can be used.
One example would be to inject malicious code into a database field. Subsequently, any time that field is displayed to the end-user unsanitized, their browser would execute the code. This is called Persistent/Stored Cross Site Scripting.
Another would be the ability to insert code into GET or POST parameters without them being validated or sanitized. When those variables modify the content of your page, the modified data will be displayed to the end-user and their browser would then execute the malicious code. This is typically present in malicious links via email/web that send these GET parameters when someone clicks the link. This is called Reflected Cross Site Scripting.
XSS is about letting arbitrary data into a system and then showing that data unmodified to a user. If I saved some js to my profile and got someone to view that page, the js would execute. As an example I could have the js send contents of the users cookie to my web service, allowing me to do whatever i wanted with their cookie like steal their session.
In a nutshell, cross-site Scripting tricks the web browser into executing malicious code because the developers didn't check untrusted input.
More information can be found here: OWASP XSS page