Take, for example, a Web site that hosts a user-contributable blog. Perhaps all the Web developer wanted was for users to be able to upload plain text and never considered that this would also allow scripting. Because of this oversight, the developer never thinks to filter the content. Bad mistake.
[ For the full Test Center rundown on browser security, see InfoWorld's special report. ]
A common test script used to determine whether a Web site is vulnerable to XSS is:
<SCRIPT>alert("XSS is possible");</SCRIPT>
If you can upload that content to the Web site, and you can see the alert when the page is viewed, then the Web site is XSS exploitable. An excellent tutorial on XSS issues is available on the Open Web Application Security Project Web site.
Unfortunately, a lot of bad things can be done in the user's context, especially when the majority of Windows users are running as Administrators. XSS attacks have been highly successful at reaching outside of the browser to steal confidential information the user would otherwise not want to share. In some cases, they can cause buffer overflows and even complete system compromise.
Once during my professional penetration-testing days, my team was hired to break into a cable company through its own cable set-top devices. The set-top boxes were completely HTML-enabled and allowed tremendously fine-grained control over the user's experience. They even included a host-based firewall.
A quick check, using the test script string noted above, showed that the firewall's log file was XSS exploitable. I created a script and injected it simply by attempting to attack the device remotely; although my attack was unsuccessful, the set-top device duly recorded the script in its log file. I then called the cable company's tech support company and complained that my set-top box was being attacked and asked kindly if tech support could confirm it by reviewing the log files.
Within a few seconds, I had the tech support's password and shadow files (that is, their Linux-based password storage files) in hand. The script I had injected instructed the tech support's PC to send the password files to my e-mail account. My coworker and I quickly sifted through the resulting password files, found everything we needed to know, and soon took over the cable company's entire network. We had been hired to break into the company's set-top box to see what mischief we could cause there, and within a few hours, we owned the corporation's global network. That's the power of XSS attacks and why you must take them seriously.