What is the general concept behind XSS?

Question

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which enable malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007.

Okay so does this mean that a hacker crafts some malicious JS/VBscript and delivers it to the unsuspecting victim when visiting a legitimate site which has unescaped inputs?

I mean, I know how SQL injection is done....

I particularly don't understand how JS/VBscript can cause so much damage! I thoguht they are only run within browsers, but apparently the damage ranges from keylogging to cookie stealing and trojans.

Is my understanding of XSS correct? if not, can someone clarify?

How can I prevent XSS from happening on my websites? This seems important; 80% of security vulnerabilities means that it's an extremely common method to compromise computers.

Answer 1

As the answers on how XSS can be malicious are already given, I'll only answer the following question left unanswered:

how can i prevent XSS from happening on my websites ?

As to preventing from XSS, you need to HTML-escape any user-controlled input when they're about to be redisplayed on the page. This includes request headers, request parameters and any stored user-controlled input which is to be served from a database. Especially the <, >, " and ' needs to be escaped, because it can malform the surrounding HTML code where this input is been redisplayed.

Almost any view technolgy provides builtin ways to escape HTML (or XML, that's also sufficient) entities.

In PHP you can do that with htmlspecialchars(). E.g.

<input name="foo" value="<?php echo htmlspecialchars($foo); ?>">

If you need to escape singlequotes with this as well, you'll need to supply the ENT_QUOTES argument, also see the aforelinked PHP documentation.

In JSP you can do that with JSTL <c:out> or fn:escapeXml(). E.g.

<input name="foo" value="<c:out value="${param.foo}" />">

or

<input name="foo" value="${fn:escapeXml(param.foo)}">

Note that you actually don't need to escape XSS during request processing, but only during response processing. Escaping during request processing is not needed and it may malform the user input sooner or later (and as being a site admin you'd also like to know what the user in question has actually entered so that you can take social actions if necessary). With regard to SQL injections, just only escape it during request processing at the moment when the data is about to be persisted in the database.

Answer 2

Straight forward XSS

1. I find Google has an XSS vulnerability.
2. I write a script that rewrites a public Google page to look exactly like the actual Google login.
3. My fake page submits to a third party server, and then redirects back to the real page.
4. I get google account passwords, users don't realize what happened, Google doesn't know what happened.

---

XSS as a platform for CSRF (this supposedly actually happened)

1. Amazon has a CSRF vulnerability where a "always keep me logged in" cookie allows you to flag an entry as offensive.
2. I find an XSS vulnerability on a high traffic site.
3. I write a JavaScript that hits up the URLs to mark all books written by gay/lesbian authors on Amazon as offensive.
4. To Amazon, they are getting valid requests from real browsers with real auth cookies. All the books disappear off the site overnight.
5. The internet freaks the hell out.

---

XSS as a platform for Session Fixation attacks

1. I find an e-commerce site that does not reset their session after a login (like any ASP.NET site), have the ability to pass session id in via query string or via cookie, and stores auth info in the session (pretty common).
2. I find an XSS vulnerability on a page on that site.
3. I write a script that sets the session ID to the one I control.
4. Someone hits that page, and is bumped into my session.
5. They log in.
6. I now have the ability to do anything I want as them, including buying products with saved cards.

---

Those three are the big ones. The problem with XSS, CSRF, and Session Fixation attacks are that they are very, very hard to track down and fix, and are really simple to allow, especially if a developer doesn't know much about them.