Finding cross-site scripting (XSS) application flaws checklist
Kevin Beaver, CISSP
09.25.2009
Rating: --- (out of 5)
|
Cross-site scripting (XSS) is like weak passwords: the problem is widespread; the solution is relatively simple and yet the issue appears to be getting worse.
I remember when XSS was this mysterious Web flaw that no one could really explain. We knew it was something bad but it was hard to put a finger on it. A decade later, XSS plagues the Internet. Everything from basic Web sites to social media systems to e-commerce applications seem to have XSS flaws in some form. Numerous studies have shown that XSS makes up the majority of Internet-related vulnerabilities.
Over the past year, I've found XSS in all but about five percent of the Web sites and applications I've tested. This is a big deal when you factor in the ease of accessibility and exploitation, especially via phishing-related attacks.
Here's what you can do right now to seek out and ultimately eliminate XSS vulnerabilities in your environment.
- Understand the vulnerability so you'll know what you're up against and what to look for. As with weak passwords, XSS is actually pretty basic.
- Assemble your toolset. XSS is something that can turn up on any Web form or input area on your site or application. It's unreasonable to assume you're going to be able to find all of the input areas and throw every possible iteration of XSS at them. You have to have a good Web vulnerability scanner such as HP's WebInspect or Acunetix Web Vulnerability Scanner, just to name a couple. Based on my experience, you're not going to find many XSS flaws, if any, if you're not using a dedicated Web vulnerability scanner and are just using a more generic vulnerability scanner that touts Web capabilities often in the name of PCI DSS scans.
- Scan your systems as an untrusted outsider. I see a lot of XSS in Web applications behind authentication mechanisms. This no doubt highlights input validation issues but it's less of a concern given that the required login can stop the automated aspect of XSS attacks. However, this is changing due to the emergence of persistent XSS, malicious code that's stored in a database and made accessible via rich Internet applications.
- Test every public-facing system whether or not it's critical. The essence of XSS is not necessarily tied to the importance or value of the system. It's the fact that you're enabling the bad guys to exploit a flaw in your environment to take advantage of an unsuspecting user or third-party in the same way spammers take advantage of random open SMTP relays to indirectly carry out their misdeeds against others.
- Don't focus solely on JavaScript. I'm starting to see more VBScript and Flash-induced XSS. It's pretty rare, but I suspect that'll change as applications become more complex. Make sure you're scanning all ...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
parts of your site and/or application with a tool that can uncover all XSS regardless of the language that's facilitating it.
- If you've thoroughly scanned your entire site/application and nothing's turning up, you can check for XSS manually by entering the following into form fields or other input areas like directly in your URL:
< script > alert ('XSS!')< /script >
It's really basic and not guaranteed, but I have found XSS that Web vulnerability scanners have missed by using this technique.
The good news is that XSS often doesn't place sensitive back-office information at risk. It's more of a risk to your users and to unsuspecting third-parties on the client side; but it could ultimately lead to theft of login credentials and session information, which creates an entirely new dilemma for your business. Given the simple solutions, it's still not a risk worth taking.
About the author: Kevin Beaver is an information security consultant, expert witness, author, and speaker with Atlanta-based Principle Logic, LLC. With over 20 years of experience in the industry, Kevin specializes in performing independent security assessments revolving around compliance and minimizing information risks. He has authored/co-authored seven books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). In addition, he's 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 www.principlelogic.com.
|
|
|
|
|
|
