What’s with WAF
Web Application Firewall, or, simply put, WAF.
True, the name does not explain very well what it is and what it’s supposed to do, although you’d probably guess it has something to do with protecting a web application. And you’d be right. It’s the “firewall” bit, that is, to say the least, obsolete.
To understand what a WAF is or should be and why, let’s analyze the issue first.
In the recent years, Internet threats have shifted. Slowly in the beginning but increasingly rapidly in the last two years, from email to web based threats. In the past, hackers would use emails to distribute new threats, embedded into an email. Personally, I have not seen this for at least two years now, and the likely reason is because we all have anti viruses in place to protect us from email embedded threats. There is actually also another reason – distributing threats this way is very inefficient. It might have been useful ten years ago, but today, at the rate new threats are being created (40,000 new variations per day in some cases), this is no longer sufficient. It is far more efficient to compromise one website and then infect all the thousands of computers that will connect to said website via their web browsers.
Of course, I can create a website riddled with Trojans from the get go, and send out emails hoping people will click on a link, which points to that web site. But it is certainly more effective if I can compromise a trusted website (without the need to send out any emails at all) because, to be candid, people will just “come” – the website is legitimate and regularly visited by users for business or personal reasons.
You’ve probably heard about things like XSS (cross site scripting), SQL-injection, drive-by downloads and some other similarly scary expressions. These and many more, are methods often used by hackers to compromise websites. Some Trojans can even upload themselves from the client to the web server via the browser. I won’t dwell on the details of these attacks; let’s just assume malware was placed onto web servers, and when users connected via their browsers, attacks happened.So, how does a web site become compromised?
Enter the Web Application Firewall (WAF) as a way of protecting the web server from becoming compromised in the first place. The protection now moves from your workstation to the web server. The first generation of WAFs was firewalls and IPS systems running a set of signatures meant to protect web servers from known vulnerabilities. These early WAFs have not been very successful though, and the reason has been lack of specificity – traditional WAFs protect the web server (Apache, ISS) but they know nothing about the actual web application running on that server; hence an attack aimed at exploiting programming errors or other vulnerabilities of the application itself are not protected.
In principle, it would be impossible to assume that an IPS company would have signatures for a web application I’ve written. Of course, they’ll have signatures against exploits to vulnerabilities of the web server I may be using; but they know nothing about my own application. And that is why, even with a WAF in place, my web application may still be subject to attack, which in turn may compromise the computers of those who connect to my web based application.
Clearly, an entirely new approach is needed.
In our forthcoming article, I shall illustrate how Network Box resolves these issues – how the next generation WAF which Network Box has just introduced will protect web servers much more effectively.
Until the next post, here’s to a safe and productive work week for us all.
Notes: Wikipedia states “Cross-site scripting (XSS) is a type of computer vulnerability typically found in Web applications (such as web browsers through breaches of browser security) that enables attackers to inject client-side script into Web pages viewed by other users … Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities documented by Symantec as of 2007.”