Framework Security: Building Self-Protecting Applications

The Problem with Web Security

Humans are, alas, highly fallible beings. While we are good at creativity and reason, we are pretty bad at mechanically applying rules and taking care of repetitive tasks. And what is web application security, really, but the ability to consistently, accurately, and repetitively apply the right rules to protect against vulnerabilities and threats?

If HTML wasn’t such a mess, maybe all of this would be easy. What about WAFs, you ask? Web application firewalls are a good first step. But they don’t cut it; they can’t take you all the way. Because they don’t have access to what is going on inside the app, they can only look at inputs and outputs to a black box.

What if, instead, you could give the security technology access to the actual execution state of the app? You know, some sort of infallible (i.e., non-human) system to automate what is really a simple, repetitive task to enable the frameworks to defend themselves?

Solution: Framework Self Defense

Real web applications are messy. Sometimes that is because of a design error, sometimes a coding error, sometimes none of the above. Building a strong framework is the only way to:

• Access the internal state to gain more information and enable smarter decisions
• Intelligently modify app behavior
• Avoid having to update code
• Protection across a portfolio of applications

There are some real benefits of securing the framework, thus reducing the impact from coding or development mistakes. From inside the app using agent based runtime application self-protection (RASP) technology you can centrally report events, detect attacks, and prevent against the major vulnerabilities such as cross-site scripting (XSS) and SQL injection.

XSS Example

Preventing XSS illustrates the power of this approach. The conventional wisdom to prevent XSS (and the approach used by many frameworks like Rails) is to escape the greater-than (>) and less-than (<) characters to prevent users from including tags in their input.

This approach doesn’t work in many cases. The challenge of XSS is that the correct escaping depends on the context that user supplied data is put into HTML.

Consider this common example:

<a href=”user-input”>link</a>

Preventing the user-input from containing < and > in this case achieves very little. There are a number of strings that would be executed as script in this context:

• javascript:alert(0)
• &#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3a;&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x31;&#x29;
• “ onClick=”alert(1)
• etc.

None of these malicious payloads include < or > and only one of them includes a quotation mark. Yet including user input in URLs is extremely common. The OWASP XSS Prevention Cheat Sheet lists 7 rules and roughly 8 different contexts that developers must faultlessly apply when building web applications or they risk introducing XSS vulnerabilities. It’s no wonder XSS is so common in real world applications!

This is a perfect example of a problem that’s poorly suited to human developers, but easy for machines to solve. Since RASP products are part and parcel of the applications they protect, it is simple for them to parse the HTML templates being rendered, understand where user supplied data might be placed into the page, and perform the correct contextual output escaping on the fly!

In the case of IMMUNIO, the first two payloads above will simply be removed since they are javascript: URLs. The third will be escaped to ensure browsers treat it as part of the URL itself, rather than introducing a new onClick attribute.

Protecting Software With Software

Good software design is critical. Yet, no matter how fabulous your development team, people will make mistakes and hackers will find ways to exploit them. The best solution is to have technology like RASP build a strong foundation and provide a safety net for your apps.