Martijn Grooten Virus Bulletin
It does not need to be explained that HTTP has become a major infection vector for malware. Thankfully, there exist many products that filter web traffic and prevent the bad stuff from making it onto the user's machine. Such products need to be tested, ideally allowing for multiple products' performances to be compared. This paper describes how such tests ought to be run.
Firstly, the paper deals with the question of what we are actually testing. In theory, one can feed a URL to multiple products and compare the outcome of the HTTP requests, in practice it is a lot more complicated. The file that ends up being downloaded may be different depending on the time the request was made, the IP address from which it was made, the browser that was used and the HTTP headers that were sent. These factors need to be taken into account when designing a test.
Next, we will discuss how to define badness: a copy of the Zeus trojan is clearly bad, while a Wikipedia page describing the Greek god Zeus is good, but there is a whole area in between with varying shades of greyness.
We will also discuss how we verify the maliciousness of the 'URL' itself and how we verify a poor result of a product filtering a URL. The latter is no trivial question: a web page that has a malicious PDF embedded via an iframe can be blocked altogether, or the iframe can be blocked, or even the PDF can be prevented from downloading. All of these are to be considered acceptable actions.
An important part of the paper will be dedicated to describing how a test should be run: how to get multiple products to filter the same URL, knowing that sending the request at a different time or from a different IP address could lead to different responses from the web server. And how, for instance, to deal with the fact that most web threats abuse unpatched programs such as Java and Acrobat Reader. Should we test under circumstances that we would not recommend to any user - that is, using an unpatched browser?
The notion of sourcing URLs will be discussed as well. There are ample sources that could provide testers with URLs, both malicious and non-malicious, but they may not all be representative of what a real user or organisation sees.
Finally, the paper will discuss how to deal with false positives. It is possible that the response to a certain URL was not malicious when a request was made from the test lab, but is malicious for some other requests. This should be taken into account before penalising a product for blocking a URL.
The presentation will also include experiences and results based on the running of such a comparative web-filter test in practice.
