Improve Web Application Security with Frameworks: A case study

As a penetration tester, I am exposed to every web programming language out there and every common framework that exists for these languages. Especially during security source code reviews, I can obtain insights into the code quality and security level of applications that are developed in the same programming language, with the only difference being the use of frameworks.

Just recently I completed two very interesting projects that will be compared in this case study.

Each project was a source source review and the applications had the following characteristics:

  • Both applications are developed in PHP, but one of them is using the Symfony2 framework.
  • Both applications have not had any security reviews done prior to the review we have conducted.
  • One application was around 3 years old, where as the other one, using Symfony2, was developed recently.

These two PHP applications sound quite similar, however the differences between them could not have been more diverse.

What is Symfony2?

Symfony2 is a reusable set of standalone, decoupled, and cohesive PHP components that solve common web development problems.” (Source)

Symfony2 is often used as a framework for MVC applications relying on the Doctrine2 ORM to take care of the Model layer. Essentially, the benefit of Symfony2 is that it enables web developers to create web applications that are easy to maintain, quick to develop and quite secure by default.

Differences in Code Quality and Maintainability

The first big difference that becomes obvious, when comparing a flat PHP application with a PHP application that is build on Symfony2, is the architecture of the application. Symfony2 has a very clean directory structure that feels very intuitive and is easy to navigate. Symfony2 relies on the front controller design pattern, that provides a central entry point for all requests and handles all common tasks, such as caching, security, etc. Based on the processed request, the front controller triggers the according functionality. This also solves a typical problem where for each file has to manually include certain core files like the database connections. Each controller looks very tidy and the controller actions are easy to read and understand.

Flat PHP applications often seem like a quick and dirty hack, because they lack a clear architecture and structure. More often than not, we will see code duplications like input validation functions copied to every function that needs to validate input strings before embedding it into a SQL query string, that is if it was not forgotten to be placed there. Just a simple change of the blacklist filter would incur code changes to a high percentage of files. It really is a nightmare to maintain and especially to comprehensively fix security vulnerabilities in the code base. Especially, in the case of this flat PHP application very few of the common best development practices were applied.

Results of the Security Source Code Reviews

Both applications were quite similar in terms of the functionality they were offering and are a good representation of typical web applications.

The flat PHP application:

This application was seriously insecure, if not to say broken by design. We identified close to 20 different vulnerability classes and most of these classes had dozens of instances. The only vulnerability class out of the OWASP TOP 10 this application did not have was “A10-Unvalidated Redirects and Forwards”. This was simply due to the fact that there no such functionality existed in this application. To summarize, essentially every functionality this application provided could either be abused, bypassed or introduced vulnerabilities.

The Symfony2 PHP application:

The “most critical” vulnerabilities we identified were of medium risk, with only two instances that were close to being of high risk according to CVSSv2. The interesting part however is the nature of the findings.

We identified only one permanent Cross Site Scripting vulnerability within the web application and this vulnerability only occurred because the HTML output encoding was explicitly disabled for one variable in the twig view template. No SQL injections, vulnerable file upload, Cross Site Request Forgery or other common vulnerability classes were identified, due to the way how the Symfony2 framework handles these common web development problems.

The other medium risk vulnerabilities were identified in administrative & monitoring services that were not yet restricted to administrators and could be directly accessed by logged-in low privilege users. These functionalities however are mainly used for debugging and could be easily restricted, because Symfony2 has very granular options to configure access control rules in the security.yml file.

The remaining vulnerabilities were relatively minor and could be fixed rapidly by updating the web server software and setting cookie flags according to best practices.

Conclusion

The objective of a framework is to make the life of developers easier, so they don’t have to deal with boilerplate code and can focus on developing the functionality required for their application. Security is one of the areas a framework should take full responsibility of. Vulnerability classes like SQL injection, Cross Site Scripting, Cross Site Request Forgery, insecure file uploads and at least the rest of OWASP Top 10 should all be eradicated by now, because solutions exist are proven and should be enforced by a web application framework.

By design a framework should make it very hard for developers to introduce typical web application vulnerabilities.

What does this mean for the future of web applications? With the rise of web application frameworks, like Symfony2, Ruby on Rails and the like we could potentially see a dramatical decrease of security vulnerabilities in web applications. Could the current OWASP Top 10 become a thing of the past, what do you think?