GSoC-2016 Project Summary

ModSecurity Connector for Node.js

Introduction

This page contains summary of the work done by me during the Google Summer of Code - 2016 for the org ModSecurity. My project title is "ModSecurity Connector for Nodejs" and as the title suggests my primary work was to create a Connector for ModSecurity in Nodejs. ModSecurity is a Web Application Firewall (WAF). WAFs are deployed to establish an increased external security layer to detect and/or prevent attacks before they reach web applications. ModSecurity provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

A short introduction on how I choose this project, before applying to GSoC this year I hadn't used ModSecurity and wasn't even aware of any such tools even existing. I was going through the list of participating organizations with "Security" tags, and shortlisted a few organizations based on my search criteria. After going through the list of projects ideas from the ModSecurity team, I was really impressed by the amount of effort that the mentors had put into writing a detailed descriptions of the projects and in explaining the key differences that was introduced in the new version of ModSecurity. This information is important to participants, so that we can have some idea of what we are supposed to do and the relevancy of various projects for their organization. Finally, I decided to go with the ModSecurity project and submitted a proposal after some discussion with the mentors.

Project Planning

Once my project was accepted for the GSoC, I had another small discussion about how to undertake this project. As a team, we decided:

• We will be first creating a Nodejs Binding to the ModSecurity Library
• Then we will create the Nodejs Connector using the binding that was just created

Writing a binding is not an easy task, native bindings are especially hard to write and are a time consuming task which probably wouldn't have been possible to complete within the time-constraints of GSoC. Instead, we used SWIG to accomplish this task. SWIG (Simplified Wrapper and Interface Generator) is a software development tool for building scripting language interfaces to C and C++ programs. SWIG is already used in the current ModSecurity Python binding so it will be convenient to use the same interfacing file (which defines the rules or headers to make the interface) for both the projects.

Once the binding was written the next target was to create a sample connector using this binding. We planned to write two different sample connectors, one is a simple ModSecurity connector in Nodejs and the other is a ModSecurity Connector for Expressjs, both use the same binding that was developed for the project.

Writing Nodejs Binding for ModSecurity

Using the Nodejs binding we can use the underlying C/C++ APIs of ModSecurity. For the list of available APIs exported by ModSecurity please refer to the headers that are exposed as part of this binding. Although this binding exposes the majority of the APIs from ModSecurity, there are still couple of which aren't available in this binding because of the complexity involved in wrapping the target language (JS) around the base language (C/C++). One such example is registering msc_set_log_cb for logging, it's not quite possible to register the same function in JS. A list of all such known issues is available here.

Writing a stable binding is one of the key requirement for building stable connectors. As a result, I spent the majority of my time during the GSoC writing a stable connector for my project. The way I quantified stability is by writing a huge number of test cases so as to have some confidence that it was working as expected. As part of this effort I have included two types of tests:

• Unit tests: Unit tests check the basic functionality of the Nodejs binding. You may run this tests using npm test.
• Regression tests: Regression tests take the test cases from the libModSecurity regression test cases. This is the effective way of verifying if the bindings are working as expected.

If you interested in any of the above I encourage you to check out my ModSecurity Nodejs repository.

Writing ModSecurity Connector

After generating the bindings, the next step was to write a connector that would make use of it. We have written two connector using this binding:

• Simple Connector : this is a simple example of the usage of the binding as a connector. This gives a good introduction on how to use ModSecurity APIs.
• Expressjs Connector : this is another sample connector, but it targets for Expressjs. Its development is still on-going, but the basic prototype is ready. It's a good example that shows how ModSecurity connectors can be hooked within Nodejs based web applications, so as to intercept the incoming or outgoing request before they reaching their designated destinations.

For more information please visit the ModSecurity Nodejs Connector repository.

Scope of future work

There is still a lot of work that we can do with this project (which I am planning to continue), such as:

• Writing native binding: Although with SWIG we were able to generate a binding, this binding has some limitations, like JS callbacks not being supported, some templates like std_multimap.i are missing and many more (see known issues for more details). As a result having a native binding would significantly improve the project.
• Writing connectors for more Node.js based web servers: right now we only have developed a connector for Expressjs. It would be better if we could develop more connectors for different Node.js based web server.
• Supporting newer version of Node: The development of the Node.js binding was done with node v0.10.25. Node.js version 0.12.x and above use the v8 engine. As a result of changes in these newer versions of Node.js some changes to the existing bindings would be necessary in order to function. It would be great if it could support newer version of node as well.

This list is not an exhaustive list, we have more cool ideas for this project. If you have any such ideas free to add that to the project wiki.

Learnings from this project

This project was overall a great learning experience for me. I have gained several valuable skills which I believe will be helpful for me in the future. I now have an understanding of web application firewalls and some generic security principles related to web application security. I have also become knowledgeable about ModSecurity and its design, writing wrapper for C/C++ libraries for scripting languages and understanding the challenges involved in doing so. Lastly, it has also vastly improved my debugging skills along with other facets of my technical skills.

Acknowledgments

I would like to thank Felipe Zimmerle and Chaim Sanders for guiding me throughout my project (and also for being wonderful mentors ;) ). I would also like to thank Robert Paprocki for helping me during this project.