Firekeeper project weblog

Reassembling HTTP response body is not a trivial task, it requires some tradeoffs between efficiency and accuracy. I've just finished to implement solution, that in my opinion is the best. It is based on a way that Snort reassembles TCP streams.

The simplest solution would be to cache response body and not to pass it further, until it is completed. When the whole body arrives, test if it breaks some rules and pass it or cancel. Unacceptable drawback of this solution is its low efficiency. Firefox can process response body before it is fully downloaded and, for example, start to download pictures that are on a page before the whole page is available. This simple solution would disable this optimisation. It would also require unacceptable amount of resources (mainly memory) to handle large responses like for example large files downloading.

Better solution is to cache only fragments of a response. Fragments should have a random size within some range. Each fragment can be tested separately and passed to a browser if it doesn't break any rule. This is how Snort handles TCP stream reassembly. Drawback of this solution is that it isn't 100% accurate. But because fragments have a random size, it is impossible for an attacker to guess where is a border of a fragment and to format a response in such a way that suspicious data is always spread between two fragments and undetected. To further increase accuracy I made following improvement: part of a data from the end of a fragment (also of a random size) is appended to the beginning of a next fragment. It is possible to bypass this system only for attacks which detection requires processing of a large amount of data. But essentially attacks have short fingerprints and can be easily detected with this approach.

I decided to add a separate XPCOM component - Firekeeper judge - responsible for making decisions when page content matches one of rules. Judge can decide to block a page or to allow further processing. I've also tried to add an ability to replace a body and headers of a malicious response with a different ones instead of just blocking a response. But now I see that it can be quite complicated, to make it work Firekeeper should keep track of a content type that receiver expects. Image, for instance, shouldn't be replaced with an HTML document. I leave this problem now, maybe I add a possibility to replace content in a future. Judge can base its decision on a type of rule that matched a content, it can also inform a user about suspicious site and let him to decide what to do. Judge will be also responsible for adding sites to a blacklist. Because judge is a separate XPCOM component, it can be (and it is) written in Java Script. Thus it will be easy to change a decision making logic without any need of changing and recompiling C++ code. It will make Firekeeper much easier to modify and extend even for users not familiar with C++.

Firekeeper can now use its rules to check real Firefox's HTTP traffic. I'm working on some decent user notifications, now it is only an ugly string that replaces original content and it doesn't work correctly with images. I also plan to implement blacklisting of suspicious pages to the end of next week.

Len contacted me with Meredith L. Patterson and she is kind enough to help me solve some problems. I've created C++ version of HTTP protocol handler and channel, this is the only way I've found to capture HTTP traffic. These components implement a lot of interfaces, so code is quite long and not very interesting. Implementation of most methods is just a single line that passes call to the original Mozilla handler. XMLHttpRequest works fine with C++ version of a handler. It turned out that there is an addition security check when component code is written in JavaScript. It checks out if JavaScript version of HTTP handler can be accessed from the context of a web page that performed XMLHttpRequest. I haven't found any way to allow web pages to access my JavaScript handler and, as Meredith pointed out, it might not be a wise thing to do from the security point of view. But fortunately it isn't a problem now, C++ handler works well.