Application Layer Anti-virus/Firewall
So, we have servers, and these servers host applications. Each application is composed of server-side and client-side components. Traditionally, the server side components is where most of the business logic resides. Traditionally again, in order to secure your application you have to spend considerable amount of time to make sure that every server-side component works as it is intended to. If you happen to miss something, you can quickly patch it with mod_security for Apache. Traditionally, none cares about the client.
If you ask Ivan Ristic, the creator of mod_security, he will tell you all about how good application firewalls are and how everyone should use them. He is sort of application firewall evangelist, although I cannot quite understand why people use this term and why they want to call themselves evangelists, but it is ok.
mod_security is advertised as Application Layer Firewall, but this is quite incorrect. Which side of the application layer we are talking about: server or client? If you play around with it, you will see that it is primarily intended to secure the server although in some situations it may save some trouble for the client. I have been thinking about these type of concepts for quite some time now so I figured that we need to make some clear differentiations.
In this article I will quickly cover some ideas that I’ve been accumulating about client-side and server-side protection. I put all of these concepts under the common term Application Layer Anti-virus so you don’t mistaken them for Application Layer Firewall, as being used by mod_security. In general, I am going to talk about protecting the client and the server all together. If you think that Application Layer Anti-Virus is a bit ambiguous as a name, I apologise. I couldn’t think of anything else.
The biggest question is how to protect the client when the server is vulnerable and how to protect the server when the client is vulnerable. This question does not have a simple straightforward answer. Let’s examine the following case study:
site.com, Joe’s personal information is leaked and his system is exposed to all sorts of other attacks.
Let’s have the same case study but this time change the roles of the client and the server. It looks like the following:
site.com. Joe’s browser is vulnerable to the MHTML or Adobe PDF UXSS bug. Because of Joe’s insecure browser,
site.comis at risk of being compromised.
Can you spot the difference? No matter which side is vulnerable, the other is indirectly exposed to an attack too. Therefore we need to secure both sides. However, it is really hard to secure the client from the server since only the user has access in there. So how, can we make some sort of generic solution that is implemented on the server to resolve client and server issues? Well, it ain’t going to be easy.
site.com. Before login
site.comverifies the integrity level of Joe’s browser (i.e scan for vulnerabilities). Because Joe’s browser has some issues,
site.cominforms Joe that unless he patches his system, he won’t be allowed to enter.
I won’t be surprised if anti-virus vendors such as McAfee, Kaspersky and Symantec get into this type of venture.
Still, there will be some problems with situations where the client-side of the application is vulnerable to issues like DOM-based XSS. To a great extend, this can be handled by our solution by encapsulating the page DOM inside a jailed environment. The solution will be messy but far from being impossible.
To summarize, this is how the proposed system should work:
The server-side solution verifies the input and makes sure the the request and responses are RFC compliant. The client-side solution embeds itself for each stage and verifies the integrity level of the client. For further protection, the solution wraps the page DOM to protect against common DOM-based XSS issues.
This is what I call Application Layer Anti-virus or Firewall. It is feasible to construct something like this and I believe it is very likely to happen in the near future.