- Completeness
- Correctness
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:
- Very greedy.
- Goes ahead even if something goes wrong
Even some Java Implementation is kind of greedy:
com.sun.org.apache.xerces.internal.impl.dv.util.Base64
public static byte[] decode(String paramString) {
if (paramString == null) {
return null;
}
char[] arrayOfChar = paramString.toCharArray();
int i = removeWhiteSpace(arrayOfChar);
The question is: How to rely on WAF or filters controls if they miss some
behaviour?
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:
b64_encode("<script>alert(1)</script>");
PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
Mod_Security:

NoScript:

But since the real decoder is on another layer, let's try with PHP's decoder
using the illegal character '.':
P.HNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
Here's what happens:

ModSecurity (v. 2.5.6-1) and NoScript (v. 1.9.9.61) are bypassed.
Same happens for other illegal character.
Now NoScript is fixed (v. >= 1.9.9.62) 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!


6 comments: