Although modern Web apps are complex, building them within an MVC framework can prevent an increased occurrence of vulnerabilities by improving the flexibility and maintainability of the code.
One of the questions I’m asked most frequently is, “How can our organisation develop more secure Web applications?”
There are many ways of improving in-house application development processes, and most come under the concept of the Security Development Lifecycle (SDL). The aim of the SDL is to reduce the number of security-related bugs in applications in order to improve reliability and reduce maintenance costs. In this article, I want to look at the Model-View-Controller (MVC) framework, which lends itself very well to those who wish to learn Web application development methodology and can be used within the SDL.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Web applications often grow in an ad hoc fashion, creating so called "spaghetti code," where complex and tangled control structures make managing and reviewing the code very difficult. This lack of structure and readability means bugs and vulnerabilities can creep in as the program evolves. Although modern Web apps are complex, building them within an MVC framework can prevent an increased occurrence of vulnerabilities by improving the flexibility and maintainability of the code.
Using a framework such as MVC ensures the code doesn’t become unnecessarily bloated, remains structured and organised, and is understandable to other developers on the team, as well as to third parties such as code reviewers and auditors. In addition, using an MVC architecture ensures the foundations of the application can easily be built on and expanded without breaking existing functionality. This is achieved by separating the code that handles input, processing and output into self-contained and reusable modules.
There are various flavours of MVC, but generally the workings of an application are split into three core components, each handling a discrete set of tasks, as follows:
- The model represents the data on which the application operates and applies its business rules.
- The view renders the model into an interface, usually a webpage, suitable for interaction with the user.
- The controller responds to user actions and invokes changes on the model or view as appropriate to fulfil the request.
Because the model is self-contained and separate from the controller and the view, it's much less painful to change the data layer or business rules. For example, a switch from an Oracle to a MySQL database only entails alterations to the model, as the view is agnostic as to where the data comes from. This contrasts sharply with how most developers tend to build applications, mixing data-layer code, such as database queries and application logic, with the user-interface code.
Data returned by the model has no formatting, so it is display-neutral. This means model code only needs to be written and tested once, as the display of the data is handled by any number of different views and display interfaces, such as WAP or Flash. This eliminates huge amounts of code duplication, because MVC separates the data and business logic from the display. Given the number of devices users want to use to interact with Web apps -- PDAs, smartphones, iPads and so on -- being able to use multiple views that rely upon a single model is a huge time saver.
As the view only deals with outputting data and accepting user input -- the click of a button, for example, to submit a form -- the graphic design team can work on the application’s look, feel and user experience without having to worry about how the database is constructed or writing code to extract data from it. Meanwhile, the controller handles the input events when the user interacts with the user interface, taking the request and determining which model components to invoke and which view to apply to the resulting data.
MVC is not a new approach. It was first described in 1979 by Trygve Reenskaug, but it hasn’t been utilised by too many developers. This is probably because it extends the initial stages of development and requires discipline to implement properly, neither of which appeal when the client wants the application built yesterday. The payback comes, though, in fewer vulnerabilities making it through to the release version, and far greater ease of maintenance and upgrades as the application matures.
Some coders complain that a drawback of MVC is you have to spend a lot of time thinking about how the various elements of the application will interact. In fact, this is an essential stage in good application development. You certainly end up with a lot more files using an MVC approach, but each one has a single purpose and is far more easily understood than those that include many different functions and purposes. Also, once a component within MVC has been tested, you can reuse it repeatedly, knowing it works and has been security checked.
MVC may be overkill for a very small project, but there are numerous open source application frameworks that create the core structure and base files for you, greatly reducing the work involved in creating the architecture of an MVC-based application. If you develop your applications using PHP, you have a wide choice of first-class open source application frameworks that are based on MVC architecture.
PHP MVC framework tutorial resources:
- Nette Framework
- Prado Component Framework
- Qcodo Development Framework
- Recess the RESTful PHP framework
- Open-Source PHP Web Framework
- Zend Framework
These frameworks not only help keep the code compact and organised, but include features to help secure it, too. Many automatically incorporate or set security features by default so common vulnerabilities caused by poor coding are prevented. For example, most implement some form of cross-site request forgery token to prevent cross-site request forgery attacks, and input data is automatically validated against the expected input type. The same goes for escaping output, so every variable output is correctly escaped to prevent cross-site scripting (XSS) attacks.
I’m not suggesting developers blindly use these features without fully understanding how they work and why they’re necessary, but the fact that they are there, well written and tested, can save a lot of time and effort, and result in a more robust application from the start -- and hopefully more security-aware developers, too.
The MVC architecture instils good coding practices, no matter which development language you use. Which framework you choose is not as important as simply having one. It involves some extra effort at the beginning of a project to architect an MVC application, but it is well worth the investment, as the result is more reliable, robust, reusable and organised code: a recipe for more secure applications.
About the author:
Michael Cobb, CISSP-ISSAP, CLAS is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.Cobb serves as SearchSecurity.com’s contributing expert for application and platform security topics, and has been a featured guest instructor for several of SearchSecurity.com’s Security School lessons.