Today, we tend to think about web application security in terms of either defending against vulnerabilities or defending against attackers. We put policies in place, audit all of our code, and examine frameworks, libraries, and gems we have in place. We watch CVE lists and try to ensure that our software is always kept up to date.
But, as anyone who’s ever been in charge of a migration from, for example, Rails 3 to Rails 4 knows, staying up to date on everything is not easy, it’s highly time-consuming to identify vulns, patch, test, deploy, and then test again in production. Think about a platform like WordPress, which hosts tens of thousands of blogs — they have a real challenge if they have to go through this routine every couple of weeks.
But even if, by some miracle, this process could happen in a timely fashion, it only covers the vulnerabilities we know about. It doesn’t take into consideration vulnerabilities unknown to the public but known to attackers, or those that have yet to be discovered at all.
Consider this: on average, vulnerabilities sold on the black market are not discovered for 151 days, according to recent research from NSS Labs.
Web Application Frameworks: What They Don’t Know Can Hurt You
One of the most common ways organizations defend against attackers is with Web Application Firewalls (WAFs). WAFs operate by looking for identifiable patterns of possible malicious traffic. To make them work most effectively, though, WAFs need to be configured specifically for your apps. This process requires going through all the different possible routes attackers could use to access your applications, and it takes significant, specialized knowledge — which can be expensive.
On top of all this, WAFs only work at the network layer; they don’t know what’s happening in the app itself. At best, they’re making intelligent guesses about malicious activity.
Since it’s so difficult to configure every point where an attacker can access your apps, inevitably, holes will remain. Attackers use very sophisticated scripts and tools that spider through websites just like Google does. They look on every page, but instead of indexing content on the page, they are searching for buttons and forms -- anywhere they can interact with the page. If you have a tiny security hole anywhere in these forms, this is all it takes for an attacker to insert themselves into your site and take down your defenses.
Another significant problem with WAFs is the sheer volume of false positives they generate. When too many alerts come in, users tend to become numb to them, meaning that sometimes legitimate users inadvertently get blocked from apps and websites.
The Solution: Targeting the Exploitation, Not Just the Vulnerability
At IMMUNIO, we believe organizations should approach this problem by addressing the exploitation of the vulnerability -- an approach we think of as “metasecurity.” If a thief entered your house, hung around for a couple of hours watching TV, and left without taking anything, while it would certainly be creepy, it would cause less harm than if the thief made off with all your electronics.
Runtime Application Self-Protection (RASP) web app security solutions make metasecurity a reality by making it impossible for the digital thief to get away with the goods.
Let’s take cross-site scripting. You can get cross-site scripting where you have expressions — where a hacker can input scripts into your site that can end up being run by another user. The question is, should there be script tags in any of your expression tags? If you wrap the html_safe method, you can see where html_safe is being called from. In the context of Rails, you’re asking Rails to provide you a script tag with some content. If it’s not being called from a known good location such as Rails, it probably does not make sense to put a script tag there.
In addition, a lot of sites don’t do a comprehensive job of locking down session tokens. If an attacker takes control of session tokens via cross-site scripting, he can start to create content as if he were the original user of the session — which is one thing if it happens on a social networking site, but the consequences of such a breach on a banking website are catastrophic.
And with SQL injections, you know that when you execute a query, there is a specific structure you can expect. If later on you see a structure that is different, there is a high probability that something funny is going on. Maybe there is an attack happening. The bottom line is, you have to know what the app should be doing before you can filter out what should not be happening.
Every query is executed from a stack trace, which includes your application code as well. Whenever that line of code is executed, you end up at a stack trace which should always be the same. We can learn that when a query comes in from a specific stack trace, there is an expected structure. New queries that match this structure are good; those that don’t match are bad, and can be blocked with a 403.
RASP Is Metasecurity
Automated RASP solutions apply this concept to a whole series of exploitation classes, including SQL injections and cross-site scripting attacks, but also to remote command execution, open redirects, brute force authentication attempts, HTTP method tampering, automated scanners, and more. RASP runs inside your apps, watches for queries and templates being rendered, looks at the headers of requests coming in, and deploys effective, immediate mitigation strategies without the need for complex code updates or hiring specialized consultants.