67 Days to Fix a Serious Web Vulnerability?

We recently heard some startling information—WhiteHat reported it takes the industry an average of 67 days to fix Cross-Site Scripting (XSS) issues! They shared this fact during a presentation revealing research on the progress companies are making in Web application security.

According to Jeremiah Grossman, WhiteHat found that 83% of websites have had at least one serious vulnerability. 64% of websites currently have at least one serious vulnerability, the most prevalent being XSS. Although awareness of XSS is building and they know how to fix it, Jeremiah says it still takes time to fix the issue. If an organization has a vulnerability for 67 days, it can create a downturn for the website or a loss in revenue. Why is it difficult for some companies to resolve vulnerabilities quickly? This can happen for a number of reasons including the coding is old and no one currently at the organization can maintain it, the code was outsourced or the error does not cause a compliance violation and it gets overlooked.

The presentation went on to say that only 30 to 60% of vulnerabilities ever get fixed. Although there is awareness for web application problems, there is not enough being done about them.  Imagine how an ecommerce site would suffer during the holiday season if it had a web vulnerability for 67 days!  This is a common issue and one the cloud computing industry is particularly susceptible to. One of the major uses for cloud services right now is overflow services during holidays and other abnormally high web traffic periods. This is the reason we have created made hyperguard SaaS for Amazon Web Services available – to allow companies to extend protection into the cloud.

Why is Cross-site Scripting Still a Problem?

We had some great feedback from developers in LinkedIn about this issue. Some thoughts worth sharing below.

Brian Hidgen chimed in with his thoughts:

“I perform security code reviews of internally written and commercial packages every day. It is stunning how many problems I see. Why does XSS still happen? For one, time pressure. Developers are under time constraints to deliver so they cut corners and push things out. Management for the most part does not take security seriously or they adopt a see no evil mindset and ignore the problem until they get bitten down the road. Lack of understanding is a big one too. I have been a developer for a long time and I was not trained or even sensitized to the issue until relatively recently. I know a lot of my colleagues past and present are in the same boat. We aren’t doing Cobol on a mainframe either, we are all Java/.Net/Ajax/Web 2.0 developers. The problem simply isn’t well understood and not enough attention is paid to it.”

Milton Smith shared a little more with us:

“The problem with XSS, and cyber security in general, is awareness. People don’t see security as a problem until it impacts them. Next, highly secure software is a consumer EXPECTATION. It’s not generally a feature consumers are willing to pay extra to include in their products.

Building secure solutions takes: education, training, tools, process improvements, etc. As such, it’s all too easy for commercial software vendors to bargain away the features consumers cannot see, like security. Other areas of non-functional requirements suffer as well: performance, scalability, reliability, and diagnostics.

The causes for XSS are well known. Poor cyber security is like showering in a glass bathroom blissfully unaware everyone is watching.”

Exposed to XSS? Regain Your Composure (and Security)

I recently read a very interesting article, Tech Insight: XSS Exposed, by Dark Reading’s John Sawyer. He discusses how a cross-site scripting (XSS) attack can steal a user’s credentials, exploit their Web browsers and take action on their behalf without their knowledge. I wanted to add some of my thoughts on this article and share ways users can prevent and protect themselves against these attacks.

As stated in the article, XSS is always caused by missing input validation, the place where hyperguard comes into play. It scans every request (and therefore every user input) for malicious code that wants to be stored or executed. When a user is tricked into clicking a link containing XSS, the request is denied by the distributed web application firewall (dWAF) and the script will not run. Also, the script will not get stored into a database if the dWAF prohibits the request with the data from entering the web application. The problem with persistent XSS is that it is typically done on a prepared site that has bait for the victim, resulting in running malicious code.

The mechanism behind the protection that hyperguard delivers is easy and contains blacklist rules. These patterns know what an XSS looks like and causes the dWAF to deny the request. The second and more secure approach is to whitelist all input in the application. This is more work, but it helps to create a very secure web application, where every user input is validated. XSS attacks can take on many forms so you should never trust input from users.

In John’s article, he mentions OWASP’s XSS Prevention Cheat Sheet, which provides detailed information on when and where encoding should be done. XSS attacks should be taken seriously because they do happen often and can be very costly for businesses. It is important to take the necessary steps to prevent them and learn how to protect yourself if they do occur.