Website Security, Application Firewalls, and Auditing at a Glance

A good article here on “at a glance” website auditing.

Take a look at any Website. Just by looking at the URL bar, I can glean several things right off the bat. If the site does a redirection to another page, it might show a file extension like “.aspx” or “.php.” In my experience, a .aspx extension generally implies that there are fewer cross-site request forgeries, fewer cross-site scripting vulnerabilities, and fewer login problems than a .asp classic site. And the HTTP headers help to tell what type of machine the Web server is.

It’s not perfect science but it’s a good place to start.

Reading that piece led me to another article somewhat related to one I wrote a few weeks ago that led to accusations of madness being levelled against me. In my blog “We can’t write secure code” (May 16th) I claimed that “systems are simply too complicated with too many lines of code for anyone to expect that they can be released without containing bugs and security holes” In Developer’s Dillemma , this theme is taken further:

We are at an interesting tipping point. On one hand, we are training our development teams to work faster, and usually with less quality, in an effort to quickly iterate on our code. Yet such haste pretty much eliminates the effort to analyze and fine-tune the code to reduce security issues.

It’s another arguement in favour of Web Application Firewalls. We can’t develop faster and be more secure at the same time so we need to put the security at a layer in front of the code. In fact, even OWASP agree. See this PowerPoint presentation from AppSec 2006 where Ivan Ristic states that web application firewalls are “an important building block in every HTTP network.”

At this very moment I’m reviewing a report I’ve been given relating to the security of a website. All the usual suspects are present: SQL Injection, Cross site scripting, error messages, and so on. It’s a production product, taking in and reporting live data. Fix the bugs or a WAF? We can’t take the site down and can only afford to do one or the other. I know where I’ll be saying we should be spending the money.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

On route to India and been meaning to reply to your first post for a while. I am sorry but I think you are plain wrong. If you think technology is the solution to the problem then you don't understand the problem. A band aid may work for lab environments but when you look at the real world issues a WAF could potentially fix and the real issues that concern web sites (not the ones the media hypes up like XSS), then you will understand that this is a fools errand to think a WAF is the right solutions. Raises the bar, sure but in enterprise web apps the bar lowers as complexity increases. Let me ask you a question? Would you drive a car that only had safety for head on impacts? I doubt it. So why would you think safety for a web site involves strapping a bumper on the front of your broken car? I will post a long mail on my blog with images from my deck at OWASP App Sec 2008 when I explain why this is a short sighted approach that is already costing people. Take a look at slides 8 to 10. If your architecture is slide 8 then you are all set. If its like slide 10 then you arent. Slide 10 is real BTW! More when I am on Terra Firma again. Stuart, love your blog and respect your writing but you are dead wrong and plain mad on this!
And my the way OWASP dont agree. Look at my first slide. Its hard to get a man to understand something if his salary depends on him not understanding it (Upton Sinclair). Ivanworks for a WAF company! Note: He is among the most level headed and unbiased (and plain nice) people in the industry and I refer to his blog for an authorititaive accurate description of what a WAF can and cant do but you have to understand web applications are not just about HTTP! Far, far from it!
Thanks Mark, I appreciate your feedback. I don't disagree with you - technology is a means to an imperfect end. WAFs don't solve the problem but they do reduce some of the risk if they are appropriately implemented . In my scenario I have limited resources and need a quick solution. I'm not so stubborn and dogged that I can't see the other side of the arguement - in fact it's something I've spoken about frequently including on my blog. The reality of working within a commercial organisation such as mine is that there is a continual trade-off between deadlines (short), resources (few), budgets (fixed), and risk (varies). Safe travels.
But you'll be luring yourslef into a false sense of security. If you think the real issues to web apps are the one the WAF;s can protect against (the same ones the media like to portray) then I think you'll stop sleeping at night. Take a serious look at the OWASP Top 10 and think about how these can be addressed by a WAF. Most can't. Leaving India on a late plane tonight so I'll either blog, mail you or fall asleep ;-)
[Mark, you have to stop being so nice to me. You are really going to start making me blush.] I would like to make a few points: 1. I believe the issue with application security, and security in general, is that we do not have a choice right now. Virtually every application out there is vulnerable in some way or another. So the question is not "Do I use a WAF or improve the security of my systems?", but "What can I do to reduce risk of exploitation _while_ I am improving the security of my systems?". 2. I am yet to meet someone who has designed and implemented a truly secure non-trivial system. We are just at that point that we don't know how it's done. 3. People often forget that a large number of problems stems from deployment errors, so even if you eliminate all the problems in your code, your system (which is the implementation of the code) is still going to have problems. Which brings me to my final and most important point... 4. Web application firewalls are seriously misunderstood. Most people view WAFs as remediation tools, but they are not (just) that. They are operational/deployment tools with a wider scope, which you use only once the application is done. Their primary purpose is to give _visibility_ into what is happening. I cannot stress this strongly enough. How can you be in control if you don't know what kind of traffic is flowing in and out? Once you have the visibility you can build on it, analysing traffic in real time, reacting to it and--gasp--even blocking attacks. Also, automated learning (which works because most applications conform to certain standards) is a very useful technique that significantly reduces the administrative overhead, and thus the overall WAF cost. To summarise, I believe that most people object to what they think WAFs are, rather to what they really are. The problem is that I am really finding it difficult to explain the latter, due to too many loud voices complaining about the former.