To wit, to WAF? Part 1.

The world is a web application. From your humble social media posts, to your grocery orders to a slightly squiffy looking "Contact Us" form on the webpage of a local guy who was recommended to refit your bathroom - Interactions with some form of web application are an inevitable part of daily life, and there seems to be no bounds to the data these applications expect from us; cat pictures to our most sensitive personal medical information, it's all welcomed with open arms by the ever present web application. 

So, take a step back for a moment. How do you trust the web application to securely store your cat pictures, and not to accidently disclose them to your ex, or your bank details to some enthusiastic hacker type who may or may not be adorned with a balaclava and oversized gold-rimmed sunglasses? You trust the developer of the application, and those responsible for hosting her code and looking after the myriad of servers, platforms and databases which serve the application to you. Dear reader, you are entering the world of Application Security. 

Let's flip things around now. Let's assume that you are the developer. You think you've done a reasonable job of building a secure application - you 've used some commonly available OSS tooling in your pipeline that hasn't flagged anything you think is particularly serious in your code, you're not connecting your application's backend to your database using a privileged role on the SQL server, so you're all good. Right? Hold that thought...

Introducing... The WAF! The WAF, or Web Application Firewall - to be formal, is a piece of technology, often a physical appliance but also available in virtual appliance, Apache/NGINX module, SaaS manifestations whose job it is to inspect every request made to the web application and to let the nominal ones through, and to block those which are deemed to be malicious. What do we mean by malicious? You've probably heard of the OWASP Top Ten (https://owasp.org/www-project-top-ten/) and that's a good place to start. Malicious requests can be thought of as requests designed to elicit some response from the web application that it was not designed to provide, for nefarious reasons. I'm pretty sure that you would never include logic in your GP appointment booking system that could reveal the medical records of all the practice's patients, but an SQL Injection flaw if present could do exactly that...

How does the WAF do all this magic? If you're familiar with the reverse-proxy, the WAF works in much the same way, but it discriminates and won't send forth any requests which it deems to be malicious to the application, and in most cases will apply the same scrutiny to the response too (is several megabytes of what looks like patient information in the response legitimate? If the WAF doesn't think so, it can block it) 

Here's a breakdown: 

1. The WAF is positioned somewhere in the application stack, between the internet, and your application. 
2. An incoming request from the internet, destined for your application arrives at the WAF. GET, POST, whichever.
3. The WAF normalises it, reverting any non-standard encoding to a standard form. Should this step be omitted, it might be possible for an attacker to encode their malicious request data in such as way that it doesn't arouse suspicion.
4. At a minimum*, the WAF will compare the normalised information in the request body (and header, form and cookie) to a vast oracle of known malicious request patterns.
5. Any requests which are deemed to be malicious will generate an alert. Depending on how the WAF is configured, that alert result in the request being dropped and a pretty "Oops!" 404 served up instead, or a log recorded but the request allowed through, or the attacker's IP address blocked for a period of time, or a counter incremented to inform a later decision should the determination only be borderline malicious, and much more. 
6. Good requests are forwarded to the application server, and the response forwarded back to the client, in the usual proxy fashion.
   
   *Signature matching is really the barest minimum of techniques a WAF can apply when making the malicious-or-not determination. Think: threat intelligence feeds, machine learning based off actual payloads or metadata, risk scoring...

All sounds rather magical doesn't it? Part of my motivation for writing this piece is that I've worked in a few roles now where a WAF was desired, purchased, perfectly implemented with regard to operational resilience and performance and yet... never actually "turned on"; every request is being passed directly along to the application and the expensive WAF isn't adding any security value. In part two, we'll look at how expectations compare to reality, and a pragmatic approach to getting value from our WAF.