XSS vulnerabilities and security technology that thinks more like you
Learning about the world around us and then modifying our opinions and actions as we learn more is a skill that we aspire to teach in every classroom, and it is a process that informs how we think about making technology a little bit smarter.
XSS vulnerabilities represent a serious challenge for organizations
In 2012 the number of reported web application vulnerabilities rose 14% YtY, with over 3,500 new web application vulnerabilities disclosed last year. Of these, the two most commonly reported web application vulnerabilities were SQL injection and XSS, with XSS accounting for the majority. According to the 2012 IBM X-Force Trend and Risk Report, 53% of all disclosed vulnerabilities in web applications were XSS vulnerabilities.
Leveraging XSS vulnerabilities allows an attacker to inject and fold their malicious content into whatever content the compromised website delivers to users� browsers. Because the content was distributed through a legitimate and trusted source, it has all the associated privileges of that site, perhaps most importantly, access to session and cookie info. This is useful to an attacker because it can provide them with legitimate access credentials, which then allows them to impersonate users.
Helping to keep organizations protected
The increasing number of XSS vulnerabilities has proven to be a sustained trend. Organizations should take some time to consider how well they are defending themselves against the potential exploitation of these security issues. For years, IBM's application security scanning technology has placed highest in 3rd party tests (2012 results, 2011 results) that have sought to quantify which application vulnerability scanning technology was the most accurate and uncovered the most of these security flaws.
This is also a space where we have continued to push forward and innovate. When we announced AppScan 8.6 last summer, many of the headlines about the release were about the support for Android applications. However, also within that release was the announcement of our new and improved XSS Analyzer. This was no incremental improvement either, this was a huge step forward in how automated software can detect XSS vulnerabilities.
Anyone familiar with this space knows that actually exploiting a XSS vulnerability typically requires finding ways to understand and creatively work around any input validation mechanisms. Input validation mechanisms make it more difficult for an attacker to drop his or her own code into a web application, code that the victim�s browser recognizes as a command and then runs. Validating these inputs is essentially a way to make sure your application can only be used to do the things you've designed it for.
Security technology that thinks more like you
Traditional scanners send a few dozen generic requests from a fixed list of potential exploits when looking for XSS vulnerabilities. These would be attacks are often unsuccessful because they are not specific enough to the environment, or because they are blocked by input validation. When the scanners get negative answers, they don't learn from them, they don't allow the first request to inform the second. This is something a human penetration tester does intuitively, but human intuition has always been difficult to replicate in computer systems.
Penetration testers today have a much more useful methodology in the way they attempt to find vulnerabilities in applications. They do so by beginning with casting a series of wide nets. At the first hint they might be on the right track they essentially start asking an increasingly more specific sequence of questions and start to close in on the ultimate target. They learn the defense mechanisms of the application and attempt to find a creative workaround that bypasses those defenses.
This is the way hackers think and how automated tools should approach identifying XSS vulnerabilities. It's an approach based on accumulating knowledge, something central to the basic concept of data analysis and, if you wanted to go a step further, learning in general.
This process has been reproduced in AppScan by identifying the context of the vulnerability and then continuing to learn more about the constraints within that context. The questions the tool asks move persistently closer to finding the answer to the question of, "where is the vulnerability in this application?" The process looks generally like this:
- Begin with an empty set of constraints
- Pick from a knowledge base a test that matches all known constraints
- Send the test, find its reflected value in the response
- If the reflected value is identical to the test, report a vulnerability and finish.
- Else: split the test into parts, send them one by one to see which one triggers the input-validation mechanism
- Learn a new constraint (based on the results of step 5)
- Go to step #2
If you are more of a visual learner, this YouTube might help you understand the difference in approaches.
One of the factors that had to come into play for this technology to be successful was a much greater number of potential exploits so there is more specificity to cater to individual environments and varying sets of known constraints. Most scanners on the market today have 100 or so potential exploits, and we are not exaggerating when we say that we have over 700,000,000!
In my head I can hear whole IT organizations leaving work early and maybe quitting their jobs altogether at the prospect of running 700,000,000 tests against an application. Don't worry, not the case at all. On average it takes about 20 requests to locate a vulnerability because each request, and the response to that request, eliminates huge volumes of possibilities. When we do locate a vulnerability, because we use this process and have such a level specificity in the exploits we ultimately send, we also keep false positives extremely low.
As is frequently the case, in application security getting the right answer begins and ends with being able to ask the right set of questions. Please leave your comment below with your thoughts and follow IBM Security on Twitter for the latest.
Likes before 03/04/2016 - 0
Views before 03/04/2016 - 8127