Skip to main content

Bypassing Web Application Firewall - Part 1



You can encounter many forms of WAF installations, such as server plugins, filters, or even customized WAFs for a certain application. Also, there are different types of WAFs that we can distinguish in the following three categories:
1.                                                                      Appliance-based Web application firewalls

2.                                                                      Cloud and hybrid Web application firewalls

3.                                                                      Code integrated Web application firewalls
The first category, Appliance-based WAFs, has to do with physical WAFs that the server manager installs physically to the server. It is placed in front of each web infrastructure of the server, and has the great advantage to not have the need of connecting to a remote server for the WAF services. It is fast, reliable, and on your facilities, so you can deal with problems that it may face on your own. Many times, this may be a negative aspect, because you will need specialized staff all the time in your facilities, in case of an emergency problem. Because of the physical structure of this type, appliance based WAFs have to deal with all the traffic and protocol requirements that your server may have, so the time of installation has to be set up for any possible case, or else it may face problems in the future.
The next category, that has many differences from the first one, is cloud-based WAFs, and as the name implies, they are firewalls that are based on the cloud. Most of the time they are installed in a remote server of the cloud WAF provider, or they can be shared between the company’s and cloud provider’s servers. In the case of complete cloud based WAF, we have serious protection of DDoS attacks, which is a common threat the last decade. On the other hand, a distributed solution can be used for companies that have more than one server location, and they do not need a physical solution in all the locations.
Finally, we have Code Integrated solutions, which is only software based, and most of the time, makes changes to the web application code, or sits to the server. As you can understand, the thing that has no need for hardware makes it cheaper, easier to fix, and easier to update. You still need specialized stuff in your company, but if the WAF is well built, it can make things so easy that even the usual IT staff can handle it.

Web Servers and WAF Placement

Web servers are basically the host of web applications and WAFs that we are talking about in this course. It consists of specialized hardware and software that manages the communication between the client and the server, with a variety of protocols, like HTTP and FTP. Web servers are used most of the time to serve web pages, and on the hardware side of things, it is pretty similar to a computer that stores the files required for the webpage’s structure, and serves them to the client. The software side manages the communication and access control of the file system, with many different implementations.
In the situation of a WAF placement on the web server we have the appliance based that as you can imagine is a separate hardware piece, that sits in front of every other hardware on the web server. All the traffic has to first pass and get filtered by the WAF, so everything is connected to it. In the cloud based systems, we may have both hardware and remote cloud service, but the difference is in the remote solution, where the traffic first passes through the remote cloud server, it gets filtered and then it gets redirected to our web server. Finally, we have the code inte- grated solutions that as we said is software that sits in front of all the other software in the web server, filters all the traffic and allows it to the other web applications or blocks it.
There are also two security models that a WAF can follow in developing its security policies, which is positive or negative. In the positive security policy, WAF allows the traffic that has come to be good to pass through, and blocks all the other traffic. In the negative model, the WAF allows all the traffic to pass and only tries to block the known to be bad traffic. Many times, WAF use both of these models, but things get complicated, so most of them
select one of the two.

WAF Operating Modes
Aside from the security models, we have the operating modes of a WAF. A WAF can operate differently, according
to the use we want it for. Each of them has its positive and negative aspects and it is a seri- ous part to consider
when selecting a WAF for your company. The most famous operating modes are:

 Reverse proxy: As we said in the beginning of the module, a WAF can be used as a reverse proxy, because it sits in front of the server and filters all the incoming traffic, which is the opposite from a proxy. Many times, the negative in a reverse proxy is the latency that may occur, but this problem tends to be fixed in newer solu- tions. In this mode, WAF has its own IP address, and all traffic goes through this address.
 Transparent proxy: This proxy has the same conditions as the reverse proxy, with the change that it does not have an IP address. This is because it sits behind another firewall, and it does not need any networking changes in the server side.
    Layer 2 bridge: In this mode, the WAF is again sitting behind the firewall and acts like a layer 2 switch (more about it here: https://en.wikipedia.org/wiki/LAN_switching). It is a mode with high performance, and no
server side changes.
  Network Monitor mode: In this mode, the WAF sits outside the web server (like the cloud based ones), which sniffs and monitors all the traffic that heads to the web server. In this situation, the WAF is blocking un- wanted traffic, by sending TCP resets to interrupt it.
WAF Filter Rules

•  WAFs have some preset rules out of the box, and of course, they get up- dated many times. These rules are known bad so that when a request is done to the server, WAF is comparing it with these rules. If a request matches one of the preset rules, the request is blocked, because it is faced as malicious. Also, in most of the enterprise WAF solutions, these rules are hidden, and no one can access or see them. This is happening because developers believe that if these rules are hidden, users won’t know them and neither will attackers, so it protects users from easy bypass techniques. Of course, these rules can be bypassed many ways that we will examine in later modules. Some common modifications to bypass filter rules can be shown in Im- age 3. On the other hand, open source WAFs have their rules open, which is an open call for everyone to find by- pass methods easily, and add them to in the filter rules, which is a proven security model of the open source community.

WAF Fingerprinting

The first thing we need to know before starting bypassing WAFs is if there is at all a WAF in the target, and how this WAF works. For these reasons, we perform WAF fingerprinting techniques, which can be separated in two different approaches of fingerprinting. One is passive, where we try to find signs of WAF in the HTTP responses of the web server. Many times, WAFs are leaving HTTP headers or other interesting info about their existence, which we can find and examine, to be able to verify it. The downside of this, is that many times WAFs give false HTTP headers and info, or no info at all, so this technique can be faulty, or not useful at all. The other approach is active fingerprinting. In this approach, we examine the WAF’s behavior. Here we actively examine the web servers’ responses. Many WAFs, for example, are changing its response depending on the way a URI is requested due to the filter rules we saw earlier. If we give two different URIs and the one has successfully returned the re- quested material, and the other not, then we know that a WAF is presented, and we can do some research for this filter to be able to completely fingerprint the WAF. where we will filter all the HTTP Requests. If we see an HTTP request where a cookie has been added by the WAF, we will distinguish the ns_af, which in this situation unveils that the web application firewall is a Citrix Netscaler.
Another way of manually fingerprinting a target WAF is by examining Header alterations that a WAF may imple- ment. Some WAF products like the Netscaler again, allow the header to be rewritten and they can also make the web server to produce different HTTP responses from the common ones. This many times can confuse the attacker or automated tools that we may use.
Continuing, another interesting method is by examining the server responses. This is usually done 
with two ways:
1.      WAFs identifying themselves inside the response
2.      WAFs replying with specific response codes
For the first one, many times WAFs respond with messages from them into the HTML code, which can be easily identifiable. For the second one, many times we can face strange response codes, like 999, that may or may not be ac- companied by a message, which repels us from attacking the system. You can see a good example from the Web-Knight WAF, responding with a 999 code.
Further known methods for WAF fingerprint, are:
 Drop Action – Sending a FIN/RST packet from the server or client to terminate a connection (technically could also be an IDS/IPS)
Pre Built-In Rules – Each WAF has different negative security signatures
Side-Channel Attacks – Many WAFs can be recognized by the response time in a server request (Timing behaviour)


Popular posts from this blog

Haking On Demand_WireShark - Part 5

Detect/Analyze Scanning Traffic Using Wireshark “Wireshark”, the world’s most popular Network Protocol Analyzer is a multipurpose tool. It can be used as a Packet Sniffer, Network Analyser, Protocol Analyser & Forensic tool. Through this article my focus is on how to use Wireshark to detect/analyze any scanning & suspect traffic. Let’s start with Scanning first. As a thief studies surroundings before stealing something from a target, similarly attackers or hackers also perform foot printing and scanning before the actual attack. In this phase, they want to collect all possible information about the target so that they can plan their attack accordingly. If we talk about scanning here they want to collect details like: • Which IP addresses are in use? • Which port/services are active on those IPs? • Which platform (Operating System) is in use? • What are the vulnerabilities & other similar kinds of information. • Now moving to some popular scan methods and ho...
Read more

Bypassing Web Application Firewall Part - 2

WAF Bypassing with SQL Injection HTTP Parameter Pollution & Encoding Techniques HTTP Parameter Pollution is an attack where we have the ability to override or add HTTP GET/POST parameters by injecting string delimiters. HPP can be distinguished in two categories, client-side and server-side, and the exploitation of HPP can result in the following outcomes:  •Override existing hardcoded HTTP parameters  •Modify the application behaviors   •Access and potentially exploit uncontrollable variables  • Bypass input validation checkpoints and WAF rules HTTP Parameter Pollution – HPP   WAFs, which is the topic of interest, many times perform query string parsing before applying the filters to this string. This may result in the execution of a payload that an HTTP request can carry. Some WAFs analyze only one parameter from the string of the request, most of the times the first or the last, which may result in a bypass of the WAF filters, and execution of the pa...
Read more

Bypassing Web Application Firewall Part - 4

Securing WAF and Conclusion DOM Based XSS DOM based XSS is another type of XSS that is also used widely, and we didn’t discuss it in module 3. The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie, and it is also a security feature that limits scripts on different domains from obtaining cookies for other domains. Now, the XSS attacks based on this is when the payload that we inject is executed as a result of modifying the DOM environment in the victim’s browser, so that the code runs in an unexpected way. By this we mean that in contrast with the other two attacks, here the page that the victim sees does not change, but the injected code is executed differently because of the modifications that have been done in the DOM environment, that we said earlier. In the other XSS attacks, we saw the injected code was ...
Read more