Cleaning the servlet requests from Html Injection
Holiday in Brazil, a good moment to taste crabs aperitifs on the sunny beach and to fix some old issues in the code of my Open Source projects. Some of these issues had revealed subtle gaps in our traditional programming - like the Web Application Security Vulnerabilities. Reviewing the code of Cejug-Classifieds, I noted the lack of control over Html Injection and I decided to dedicate my afternoon working around to fix that gap. This blog entry describe my first effort in order to reinforce the security of the code of my project, and it should evolve in the next weeks. It is an opportunity to share with you my project decisions and also a hope in order to learn more about that.
Reading the excellent paper of Stephen Enright, I started to design a general solution to Html injection - adapting the paper tips to the patterns IÂ´m using in the cejug-classifieds. Before describing the solution details, let me introduce you the idea of the classifieds: The Cejug-Classifieds is a study case, with the aim to produce a web-application based on Desing Patterns. All frameworks were ignored in order to provide a clean view over the layers of the application - since the jsp view to the jdbc persistence. The project started from my need to learn patterns - a first step in the Architect Certification direction.
The project has a FrontController which receives all requests and then identify a Helper able to deal with each request. This Helper creates a Command, which use DAOs to manage data into a database. Factory and Filter are other patterns explored in the project.
The idea is to prevent request parameters containing injection tricks, like scripting injection and Html injection. I designed a HtmlInjectionFilter to solve the problem: the idea of this filter is to remove the dangerous characters before processing the FrontController doGet or doPost methods, like shown in the figure below:
Quite simple? Not yet. Despite the simple idea behind the filtering Html injection, some code details concerning the manipulation of requests become trickiest than expected - mainly the need of a modifiable map of the request parameters. The interface javax.servlet.http.HttpServletRequest is primary implemented through the class javax.servlet.http.HttpServletRequestWrapper and the map of parameters used by this class is locked, i.e., non-mutable. My filter was designed to replace the dangerous parameters by the clean ones, but the map doesnÂ´t allow me to change the contents of the original parameters map. After some posts into discussion lists, I developed a request wrapper. I called that as MutableHttpServletRequest due to its mutable map of parameters. It works fine right now, despite the need to improve its functionality in order to reinforce its robustness. The class has a internal Map that overwrites the superclass map. The constructor copies all values from the original map filtering injection and then uses the clean map as the data structure of the request.
Well, the work is under progress and some patches will be necessary before it becomes stable enough to a release. The project have promoted good discussions into foruns and discussion lists, and that is one of its major objectives. If you are interested in discussing more project details, be my guest to contribute.
Felipe GaÃºcho - Dia de Finados 2005.