Felipe Gaucho's Blog

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.

Comments

• Err. What about using c:out with escapeXml="true"? Ie. I never had the urge to prevent HTML injection, though I see the point.

  Posted by: blizzy on November 02, 2005 at 01:09 PM

• Hi blizzy,

  I´m perceiving now the ambiguity of my entry title. My prime intentions was to create an isolated layer of filtering over the requests. The Html injection is just one of this layer utilities. The c:out is a strategy to keep the injection and just avoid it manifestation into the Html. And it is also useful only in JSP/Html views. What about Swing view or other technology.
  The idea of my MutableHttpServletRequest is to provide a set of generic filters useful to clean the parameters in all communication through http. Other topic is concerning the type of these filter, which can include html injection and several other cleaning methods (script injection, SQL injection, etc.).
  BTW: your comment let me to think about an hybrid solution, including the JSP as part of the filter strategy.
  Thank you very much to give me other perspective over the problem.

  
  Felipe Gaúcho
  Cejug-Classifieds owner
  

  Posted by: felipegaucho on November 03, 2005 at 04:36 AM

• Just beware that an HtmlInjectionFilter may not be enough to prevento injection bugs on your apps. First, because sometimes you'll want yout data to contain HTML, so you need flexibility to not filter it out (and select which tags and attributes to filter). Second, because the injection may target your SQL statements and not HTML/Javascript.

  Anyway it's nice to see more developers concerned that this is a problem that needs imediate attention. Most CTOs still believe web security is handled by criptography, firewalls and IDSs alone.

  Posted by: flozano on November 03, 2005 at 10:58 AM

• 
  Having been down this kind of path before, I'd suggest that you lock down the parameters once you've done filtering them. The bugs that a junior developer can introduce when they have the ability to change the parameter map are pretty horrific.
  

  Posted by: bob_boothby on November 04, 2005 at 01:19 AM

• humm... nice tip. I will do that. Thank you.

  Posted by: felipegaucho on November 04, 2005 at 04:02 AM

• 廣告設計,推廣計劃,網頁設計,廣告片拍攝,電視廣告,個人影集,彩盒,專業攝影,小冊子,VCD製作,報紙廣告,公司形象,
  Office Furniture|Wooden Filing Cabinet|Office Partition|Mobile Cabinet|File Cabinet|Office Desk|Storage Rack|室內設計|辦公室屏風|wow gold

  Posted by: bengjing2008 on August 21, 2007 at 07:09 PM

This work is licensed under a Creative Commons License.