Framework Security: Building Self-Protecting Applications
What if you could give the security technology access to the actual execution state of the app? Some sort of infallible system to automate what is really a simple, repetitive task to enable the frameworks to defend themselves?
Join the DZone community and get the full member experience.Join For Free
The Problem with Web Security
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.
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:
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:
- “ onClick=”alert(1)
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!
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.
Published at DZone with permission of Oliver Lavery, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.