I wanted to cover some WAF topics I haven’t seen covered much. Most WAF vendors talk about the security their product provides in terms of blocking attacks. I would like to delve into these WAF Blockings as well as mention some ideas for alternative uses for your WAF through it’s interactions with web clients.
Web Application Firewalls are interesting bits of technology. Depending on the product and deployment method you chose, they can transparently protect your web infrastructure using various protections by generating blocks when threats are identified. Depending on the product, they can Vulcan mind meld with your Apache instance, live as another F5 device in your network, take over a slotin your XBeam, or live life as a network appliance inside your datacenters.
This intelligent device COULD interact with the client in additional ways outside generating BLOCKs. For example: developers could leverage a WAF to provide additional protections, send notices to connect clients under specific conditions, or even prompt a client for confirmation before performing a specific function if certain criteria are met. After all the BLOCK a WAF generates doesn’t have to be a BLOCK at all, at least not in the context of traditional firewalls or even active-response IPS devices.
If WAF interaction with the client is a concern because you’re trying to keep your WAF invisible to the bad guys, you should know that that’s not a realistic expectation.
WAF’s block threats to your web applications identified through various security methods, but what does that mean?
There are a few options, largely dependent on the vendor and deployment method (transparent bridge, proxy, router, offline sniffing): TCP Reset, Request/Response DROP, out of band Reset via 3rd party. There’s no hard-fast requirement to only use a TCP Reset that’s sent to client and server, like IPS or active-response causing the TCP session/connection to be terminated, but this is controlled by deployment method.
The DROP method is like a virtual trapdoor inside the WAF where malicious traffic falls into a dark pit, never to be seen again.
Some WAF products can send a web coded response back to the web user inside their active session indicating their request could not be completed, some WAF can be configured to quarantine an IP Address or terminate a web session, in addition to dropping the client request or server response. The use of WAF generated error pages to interrupt and/or stop the web session alongside Request/Response dropping is more graceful than TCP Reset. Depending on your environment, TCP Resetting could create unexpected results on your web servers and typically this requires your WAF to be operating in Proxy mode.
In traditional transparent WAF deployments, these BLOCKs generated by a WAF are typically nothing more than a standard error page or a redirect to a logout sequence coded within the web application being protected. Some WAF’s allow you to customize the page, insert scripting, and push it seamlessly to the end-user inside the existing SSL session. Alternatively, the client could be redirected to a destination within the protected application to log out their session, collect additional information, or open a support ticket (although the last one of those I saw, was more for looks than functionality).
If the WAF can generate web pages in response to client interactions inside an existing SSL session, the client would be interacting with the WAF. The Imperva Application Defence Center (ADC) has an interesting web fraud paper on enabling clients to interact with what I would describe as a security control panel, to help with CRSF/XRSF attacks and web fraud. I have played around with this a little and found some interesting uses – sorry saving that info for my next contracting gig!
The idea of using policies to trigger BLOCKs takes on a new meaning, if the WAF can be leveraged to a generate unique or controlled web pages when a specific policy is triggered or even redirect a user to a specific function inside an application if certain criteria are met, before continuing on inside an application. Don’t get me wrong, TCP Resets are good too – but this path offers much more robust options for a company from multiple perspectives.
Now the WAF can be used to not only BLOCK pure security-centric threats but also control the application behavior and client interaction if something fraudulent, abusive, or irregular is detected. For example you could leverage the behavior deviation capabilities of your WAF (profile violations) and construct a temporary input validation error handling process inside your WAF while your coders developed the handling inside the application. This would be a straight forward use of the acquired knowledge of the WAF, a simple error page containing the prohibited characters, and a method for the client to have a “do over” on the prior page.
Once again, the WAF is providing additional capabilities that an IDS/IPS cannot!
