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.
XSS the top vulnerability in most Web applications in Q1 Cenzic's Application Security Trends report shows various cross-site scripting (XSS) vulnerabilities dominated the top 10 vulnerabilities in commercial and open source.
XSS prevention in Java Cross-site scripting exploits can devastate Java apps. With XSS attacks on the rise how can you prevent these exploits in J2EE applications.
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.
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.