XSS Vulnerabilities Continue to Run Deep

Veracode, a company that specializes in security testing and analysis issued a press release recently that it would be offering free scanning for Java applications to look for cross-site (XSS) scripting threats.

This announcement caught my eye because it shows that application vulnerabilities continue to run deep, enlaced within application logic. Moreover, it highlights some of the expensive measures that must be taken in terms of code auditing, static analysis, and testing that must be employed to look for these types of code injection vulnerabilities in order to eradicate them fully.

The cost isn’t in running the tools once, it’s in maintaining the process and ensuring that the tools and analysis are done every single time the code changes. It’s the ongoing costs that are the killer here. Murphy’s law tends to be a good guide. I’ll bet that the one time the validation process is skipped or abbreviated is the time when a new input field is added with less than perfect validation controls and viola, XSS can weasel its way back inside.

 

Our answer at Intel is security decoupling. In a previous post on the OWASP Top Ten I described this concept more fully and aside from our particular product solution for this, which is a Service Gateway, decoupling really gets its value from enforcing specialization of roles. Our view is that enforcement of threat prevention, including cross-site scripting should be a job of the security architect, not the application developer, and further, that the architect should be able to implement security policies for input validation and code injection separately from the core business processing of the application. The service gateway model is one expression of decoupling that allows this to happen at a practical level.

I wonder if static analysis tools can also be used to seek out XSS vulnerabilities that involve encoded XSS threats? For example, Intel(R) Expressway Service Gateway can block XSS threats that appear in encoded formats found in different parts of the message as well. Our philosophy is that if you can prevent the code injection threat from reaching the business processing application, you may be able to obviate some of your static analysis costs.

For reference, here is a sampling of encoded threats that can be blocked by Intel(R) Expressway Service Gateway. As a side note, I had to paste this table in as a picture as I don’t want to be accused of mounting an XSS attack in my HTML post against Intel Software Network :)

 

Blake Dournaee

About Blake Dournaee

Passionate, energetic product manager that lives at the intersection of business, innovation and technology. I currently work at Intel in the Datacenter Software Division working on products and technologies relating to mobile, APIs, cloud services and big data.

Comments are closed.