Let's start with something really
straightforward. We know that this syntax
is enormously prevalent. So remember this
was the tortology, closing off a string,
and then using a statement that's always
true. So the 1=1 syntax is enormously
prevalent. Now there are some less
prevalent alternatives that mean the same
thing. And again, keep in mind the whole
definition of a tortology is just to try
and have a statement that's always true.
So for example, this would always be true.
It's a perfectly valid tortology, we're
just matching two strings now instead. Or
another example would be this one, 2 is
always going to be greater than 1, that's
always going to be true. But if the app is
just looking for the all 1=1 syntax, then
this one'll get through. Even a syntax
like this is still accurate, it's
syntactically correct because we have more
characters after the F on the left-hand
side of this equivalency, it's going to
equate to true. So foo is actually greater
than F. And this is the sort of thing
that's often not looked for in signatures
for defending against injection attacks.
What you'll often find when trying these
different attacks, is that it's going to
take a lot of probing. So you'll need to
figure out what sort of patterns are
rejected by the web app versus which ones
are accepted. So this is very much a trial
and error approach. Because so many web
apps are implemented in different ways.
That said, you'll also find that there is
some known vulnerabilities within certain
devices like WAFs and IDSs. So if you can
identify what the device is that's
actually protecting the app, you may well
be able to find known risks within there
that can be circumvented by some of these
evasion techniques. So that's basic evasion, let's go in and look at encoding.