New lightweight frameworks for building three-tier MVC ( Model, View, Controller ) web applications, have been emerging and are becoming very popular. They combine a HTML templating framework with an ORM (object/relational mapping ) layer, and rely strongly on conventions about what things like variable and class names should be called, and where things should be stored. This enables you to, very quickly create, test, and deploy sophisticated web applications with just a few lines of code. Ruby on Rails is one example of this framework. However, does the speed in developing these applications compromise on security? This is the big question, and my initial efforts in using these applications have raised some alarms.
This is the first, in a series of postings that deal with how easy it is to overlook the security aspects when using these frameworks. We will look at Ruby on Rails in particular.
Cross Site Scripting and Rails Scaffolds
Model: The model maintains the state of the application. It represents data, and all the business logic that applies to that data. It generally represents a table in the database, and determines which table based on a naming convention. For example a model named product represents a database table named products.
Controller: controllers are used to coordinate actions between the view and the model. The framework provides you a mechanism to create the controller using a command line interface.
Scaffolds: Rails Scaffolds allows you to manipulate the model in the application. It is auto generated and provides a default view, that you can use to view and manipulate the model. The form generator created by the scaffold asks the model for information on the fields in the model and uses this information to create an appropriate HTML form.
Cross Site Scripting.
The Html form and corresponding server side code created by the scaffold is vulnerable to cross site scripting. No input validation is done on the data, that is input using this autogenerated form. This un validated data is stored in the database that can potentially lead to persistent cross site scripting. This can lead to the usual exploits that can be achieved with cross site scripting like, stealing authentication credentials etc.
Impact:
Since the developer is accustomed to write minimum code when working with these frameworks, it becomes easy to overlook security issues described above. The developer expects the framework to create the view and corresponding server side code to accept input. The developer focuses on building the data model. This leads to a security hole that can be easily exploited.
Remediation:
Ideally developers using these frameworks should write their own server side validation code. Rails provides a helper function h(string) that sanitizes all data inside the function before displaying it. This prevents execution of code in the view when displaying data. However again no filtering is done on accepting the data and potentially dangerous data may make its way into the database. If another view or another application is ever used to view this data, the attack vector may execute and cause the vulnerability to be exploited.
-Avinash Shenoi
Comments