Generally it is used to attack clients/users.
It can be used for malware upload, botnet hooking, keylogging, a payload delivery system for clickjacking and CSRF attacks and much much more, all for 6 easy payments of $9.99...sorry got carried away there :)
But is is easily preventable. You dont even have to know what XSS (type 0, type 1, type 2, DOM, Stored, Reflected) is to prevent it.
One pretty simple way to prevent XSS is to use the OWASP ESAPI (Enterprise Security API). A very easy tool to use/invoke.
It's also managed and attended to by Chris Schmidt....A great guy...
Regardless of what it does....if there was a mandate to use it on all redisplayed external input a site could become virtually XSS free!! (all for 6 easy payments of......).
It's easy to deploy....
1. Include in JSP (Java version)
2. Invoke in JSP
3. Job done!!!
We include it by
<%@ page import="org.owasp.esapi.ESAPI" %>
We invoke it by
<div><%=ESAPI.encoder().encodeForHTML(contentQuery)%></div>.....here we are escaping HTML element content.
But here be Dragons........
Yes there is an exception to server-side escaping of input....DOM XSS.
Input rendered on the clients which does not touch the server is fair game for XSS'ers!!!
So data sent into the browser which is rendered via client side code. No server interaction needed.
An example of this are URI fragments or Anchors. These are not required for DOM XSS but demonstrate server side reflection is not required (and escaping for that matter on the server is ineffective).
Remember "Learn to code HTML for Food" (otherwise know as the W3C)...well anchors or URI fragmants do not get sent to the server.
Anchors (#) as opposed to query parameters (?) hang about the client (in small groups, causing trouble).
So for server side validation:
http://127.0.0.1:8080/vuln/XSS.jsp#q=<script>alert()</script> ß This fragment is dangerous. Server does not see this. We need some client validation!!
http://127.0.0.1:8080/vuln/XSS.jsp?q=<script>alert()</script> ß This is escaped on server. Need server (and client) validation (depending where the input emanates from).So we need some additional client side controls. This is particularly relevent for RIA applications.
Bring forth ESAPI4JS!!
Simply put ESAPI4JS escapes client side input from external sources.
Again very easy to use:
Import into your page:
<!-- esapi4js dependencies -->
<!-- esapi4js core -->
<!-- esapi4js i18n resources -->
<!-- esapi4js configuration -->
Jim Manico and myself shall be covering this and lots of other security jiggery pokery @
Sec App Dev - Belgium March 7th
OWASP AppSec DC 2012