Fooling B64_Encode(Payload) on WAFs and filters


When dealing with Web Application Firewall, IDSs or application filters trying to block attacks there are always two big problem:

We know Regexp could be faulty, but let's suppose there's some sort of encoding in the payload which is furtherly decoded on some server side layer and then used in clear text to pass it to another layer.
A good defense should be to let the WAF/Filter decode it and check for attack patterns (using regexp..).
Now the question is how can I implement a decoder to get the input back in clear?
Let's talk about Base64.

Base64 encoding and decoding are implemented in many ways and many languages.
For example PHP base64_decode() is:

Even some Java Implementation is kind of greedy:

public static byte[] decode(String paramString) {
if (paramString == null) {
return null;
char[] arrayOfChar = paramString.toCharArray();
int i = 

The question is: How to rely on WAF or filters controls if they miss some

NoScript checks for Base64 encoded Xss.
ModSecurity implements Base64 decoding using the following rule:

SecRule ARGS:b64 "alert" "t:base64decode,log,deny,status:501"

So the following payload is caught by both:




But since the real decoder is on another layer, let's try with PHP's decoder
using the illegal character '.':


Here's what happens:

ModSecurity (v. 2.5.6-1) and NoScript (v. are bypassed.
Same happens for other illegal character.
Now NoScript is fixed (v. >= and I expect ModSecurity to be fixed soon.

The question still remains.
How to rely on WAF or filters controls if they miss some behaviour?

WAFs and IDSs are good for defense in depth.
So don't rely too much on those.
Apply SSDLC by implementing correct filters and controls and
Test, Test, Test in your own environment!