I’m testing a number of cloud WAFs right now for how they handle various injection attacks. Pretty fun project. One layer of their defense is anti-automation, so if you start hitting it hard with a scanner it’ll label you as malicious and ban you.
Sounds pretty cool. Unfortunately it’s often trivial to bypass.
The way many WAFs block users is by sending one or more bad-person-cookies and then checking to see if you have them when you come back, which is much like saying,
Hey, be sure to wear this giant red sign every day that says “EVIL-DOER!” so that we’ll know to watch out for you.
And then you’re like, “Um, what happens if I just…um, take the sign off?” And after a confused and angry pause he’s like,
WE’LL GIVE YOU ANOTHER SIGN!
Ignoring tracking cookies using the Cookie Jar
Anyway, with Burp it’s pretty easy to control what cookies you send through the Cookie Jar. Importantly, you can choose to not send certain cookies by name (or ONLY send certain ones by name) for any given tool within Burp, e.g. Proxy, Spider, Scanner, etc.
So to do this you simply go in and tell the scanner that you’re only going to update a certain cookie (and ignore all the rest when the server attempts to set them).
In this case I told the session handler to ONLY send the
JSESSIONID cookie, and not any of the other crap the WAF tries to load you up with. The image up top is an example request from the scanner after this configuration.
Anyway, minor point, as you can always get around this by using manual request in Repeater, but I thought it might help someone who comes up against anti-automation when using a scanner.