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.
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.
[IMAGE]
Figure 1 – An automated scanner discovers XSS flaws.
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.
[IMAGE]
Figure 2 – HP WebInspect sends an HTTP request t
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseDesktop.com
o a page susceptible to XSS.
If you want to see an actual XSS hack in action, use Firefox and browse over to http://ha.ckers.org/weird/CSS-history-hack.html. Be forewarned: This link runs an actual XSS exploit but it's rather benign. The page at this link uses Jeremiah Grossman's proof of concept JavaScript code to read Firefox's history to match up where you've been. This exploit can be seen in Figure 3.
[IMAGE]
Figure 3 – Proof of concept XSS code determines websites previously visited.
There are numerous other XSS hacks that can be carried out in JavaScript (or really any scripting code) in a similar fashion in order to determine the IP address of your local machine, launch a port scanner to scan your internal network for live hosts, exploit Firefox's password manager -- you name it. There's even code out there to exploit login forms and password change functionality of certain sites in order to glean user passwords.
So, to sum things up, here's how an XSS exploit is carried out:
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 kbeaver@principlelogic.com.
