The Web is full of cross-site scripting (XSS) attack warnings. Essentially, XSS refers to the injection of malicious JavaScript into a legitimate Web page, where it can then be executed in the browsers of innocent visitors. A Web site is susceptible to XSS if it allows users to upload content to be shared with others and does not thoroughly inspect that content to remove potentially malicious scripts.
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.
What's the big deal with executing a few unexpected JavaScript commands? After all, the JavaScript execution can only do what the user can do in the user's own security context, right?
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.
All of the reviewed browsers included at least some built-in XSS mitigations to prevent malicious exploitation to varying degrees, and all passed the common XSS tests available on the Internet used in this review. That’s the good news. Avoid any browser whose vendor claims that anti-XSS defenses are the sole domain of Web site owners. Also keep in mind that it may be a good idea to disable JavaScript (if your browser allows it) on Internet sites when a new XSS or JavaScript-enabled vulnerability is announced. And if you come across a Web site that appears vulnerable to XSS attacks, notify the content owner. Often they are unaware that their user-friendly site could be the host of unintended maliciousness.