In a previous tip, entitled Cross-site scripting 101: XSS attacks plague Web browsers, I wrote about the basics of XSS. This Web browser security issue has been around forever, but like most things security-related, there's more to this story.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In a nutshell, XSS is something that's easily preventable Simply validating user input on Web forms and other input fields will fix most of the problems. Interestingly, there are still a ton of XSS flaws on the Internet (in highly visible commercial sites and applications to boot). The sad part is not the mere existence of these input validation flaws but the fact that so many businesses are not even testing for them.
Sure, some argue that XSS doesn't place sensitive back-end information in direct danger. That's mostly true, but XSS does put users of the site at risk. Plus it creates unnecessary exposure for businesses because their sites are essentially facilitating attacks that can be used against others -- and they never know about it.
What does an XSS attack actually look like? First, we'll check for Web forms that don't properly filter user input.
You can find out this information by testing pages for it manually. My recommendation, however, is to use a commercial Web vulnerability scanner. This method will save you a ton of time and help prevent any oversights. Figure 1 shows the results of an XSS scan using Acunetix Web Vulnerability Scanner.
The nice thing about automated scanners is that they can try many, many iterations of a specific XSS exploit by obfuscating the code to try and get around any minimal controls in place. This is one of the main reasons to use an automated scanner. This obfuscation is shown in Figure 2 where HP WebInspect is embedding scripting code in a vulnerable form.
So, to sum things up, here's how an XSS exploit is carried out:
- A user navigates to a malicious page (as shown in the example above) or clicks on a link received in an email, website or forum posting that contains malicious script code.
- The target website accepts the scripted link from the user (in the case where a user clicks a malicious link).
- The target website serves the HTML and script back to the user.
- The user's Web browser executes the script. After all, the browser trusts the site that the user told it to go to.
- Exploit complete. It really is that simple.
Look at what can be done with XSS and combine it with how many sites and applications are vulnerable to it. It's a recipe for disaster that happens to have a simple fix. But it involves people testing their systems for the problem and having developers fix the weaknesses at the source before we're going to start seeing any changes.
About the author: Kevin Beaver is an independent information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at firstname.lastname@example.org.