Rohit Sethi is Director of Professional Services at Security Compass.
Insecure applications cause most data breaches, which is one reason an entire industry of products and services has cropped around application security. Yet despite all the attention, application security problems still prevail. One reason for this is that building security-in can be laborious. For example, one of the first security concepts most developers learn about is input validation -- filtering user-created or user-influenced data in order to prevent attacks. Specifically, security experts often teach developers to filter all input using a white-list approach, which means that developers must map out every single character that the application will accept prior to deploying that application. Developing such a list isn't impossible, but it is time consuming. Given the pressures of time-to-market, even security-aware developers often develop software with obvious, easily-preventable security flaws. In this article, I propose one big step that the developer community can take to help most web application developers build more secure software -- secure the frameworks that these applications are built upon.
Frameworks that provide security features by default can significantly reduce, although not eliminate, the burden of building security features from application developers. Developers, in turn, have a more realistic chance at building secure applications within tight timelines. Security professionals will rightly point out that no matter how secure the framework is, developers can and often will continue to introduce other security vulnerabilities. Still, creating secure-by-default frameworks can substantially reduce a number of common but dangerous vulnerabilities thereby reducing risk. A few popular frameworks have already begun to take steps in this direction. For example, the Python-based Django web application framework features out-of-the-box Cross Site Request Forgery (CSRF) protection. ASP.NET provides a feature to automatically encrypt and sign client-side state stored in ViewState. Many enterprise applications, however, are built on Java Enterprise Edition (Java EE). These applications are typically complex and deployed on physically disparate tiers. Unlike .NET or Django, Java EE is a set of specifications rather than a single code base and runtime. Adding systematic protection to the framework is far from simple. For example, the Servlet specification defines the minimum behavior of a Servlet container, but individual implementations such as Tomcat, WebSphere, and WebLogic also feature additional proprietary features (see the Open Source Application Server Comparison Matrix).
The Java community recently had to change the core Servlet specification to add support for the httponly cookie flag. Each individual Servlet container will need to add this feature comply with the new Servlet specification. In addition, many of the common features we expect from large enterprise applications such as Model View Controller (MVC) are not explicitly defined as part of the core Java EE specification. Organizations around the world have built their own proprietary libraries to support this behavior, while others have adopted open source alternatives such as Apache Struts or Spring. Such heterogeneity obviates centralized security features. For example, how can we change the default behavior of Java EE applications to automatically escape web output, thereby significantly reducing risk of Cross Site Scripting (XSS)? The answer, unfortunately, is that we cannot. Unlike ASP.NET, most Java EE applications do not use one single set of tag libraries on one single Servlet container/application server. In fact, many applications do not even use tag libraries, instead opting to create presentation tier logic with raw Java in Java Server Pages (JSPs) or Servlets. As a result, even if security aware developers were to augment a common tag library with output encoding, they would only make a small dent in the total number of Cross Site Scripting vulnerabilities.
Many application security experts attempt to address the security shortfall by educating developers on vulnerabilities, attacks, and defenses. Developers who understand the risks presented by security flaws can fix their applications. In other words, instead of changing the entire Java EE framework to be secure by default we are securing applications one at a time. The problem is that we are making slow progress. Many development shops do not have the budget or even motivation to learn security much less change the way they develop software to include security activities. Moreover, many of these activities such as threat modeling add to project duration and are thus fundamentally at odds with the business motivator of being first-to-market. Make no mistake, developer awareness of security is a fundamental requirement to building more secure applications (see Rob Cheyne Pushes Developer Security Awareness) and secure web application frameworks will not remove this burden. Developer education, although necessary, is not sufficient to help close to gap of application security. To this end, volunteer developers from the Open Web Application Security Project (OWASP) began work on the open source Enterprise Security API (ESAPI). ESAPI helps developers prevent security vulnerabilities in Java and other languages. ESAPI represents a major step forward in web application security because it gives developers the tools, not just the knowledge, they need to build more secure applications. ESAPI is great for securing individual applications. Unfortunately, ESAPI does not, by itself, make web application frameworks secure by default. There is a void between secure development libraries like ESAPI and the default behavior of popular web application frameworks like Struts and Spring. The Security Analysis of Core J2EE Patterns Project attempts to fill that void.
