 |
|
|
|
|
|
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
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 a not-trusted 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 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 type="text/javascript">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.
This was first published in September 2009