Today, on the internet, a whole range of applications are moving to the web, and so are security vulnerabilities. Hackers are concentrating on attacking web applications. As part of the defense of web apps, WAFs (web application firewalls) are now becoming common place. A WAF signatures block layer 7 http(s) attacks; it is becoming as important as a traditional firewall. WAFs are indispensable now for banks, e-commerce sites, and any other site that does commercial transactions via their websites.
Among web attacks, SQL injection is one of the deadliest because it has the potential of retrieving the whole database from the webserver.
To look at things from a larger perspective, most security attacks come about due to an essential feature of how computers were designed. We keep both data and code in similar containers — both are in memory. There is no fundamental distinction between data and code, in the sense that both exist as binary data in memory. As a result, hackers insert code inside memory meant to hold data to fool the computer and make it execute code that hackers want instead of what the original programmer wanted. In SQL injection, the query itself is changed so that the attacker can get different data out from the database than what the original query intended to give out.
Consider a classical SQL injection example. Suppose there is a form on a web page that asks for the user id and password. After the user, say, John, inserts his user id and password, and clicks the submit button, the following SQL query gets executed so that John gets logged on, and a login screen appears.
SELECT * from contacts WHERE userid=’john’ AND password=’xsz297gh’
contacts are the table in the database where users and passwords are stored.
If there is no preliminary check done by the programmer as to what the fields the user id and password should consist of and the query is directly passed to the database, a lot of mischiefs are possible. For instance, the user could enter nothing in the space meant for user id and password as
and the SQL query will be turned into the following:
SELECT * FROM contacts WHERE email=” AND password=” OR ‘1’=’1′
( Please note that closing quote ‘ at the end of the query is not entered by the user but provided by the system.)
SQL interprets this query as
SELECT * FROM contacts
as the latter statement
WHERE email=” AND password=” OR ‘1’=’1′
will be interpreted as true every time.
As a result, the whole database table contacts will be output and all user ids and passwords on the database stolen. (We are assuming here that passwords are stored in clear text in the database, which is not a good practice, but that is a different issue.)
What is happening here? The hacker has successfully entered data such as OR ‘1’=’1’and fooled SQL in treating it as code/query. This is because of how SQL is designed. Just insert a quote and SQL changes the context from data to code or vice versa.
Usually, WAFs will try to block any OR followed by ‘1’= ‘1. The interesting part here, however, is that not just ‘1’=’1 would work here but even ‘2”=’2’ or for that matter
‘2’ + ‘1’ = ‘3’
also. In fact, any arithmetic expression would work. For instance, something else that would work is the following:
‘ OR 1 DIV 1 —
‘ OR 2 DIV 2 —
( The – at the end is to ensure that the ending quote ‘ that the system provides at the end is treated as a comment. If not, an SQL error would occur. Two hyphens indicate a comment in SQL.
There would be huge such combinations out there. And it is important that the WAF is programmed to stop them all. Only experts can do this task.
Have today’s WAF signatures covered all such cases? The success of WAF evasion challenge competitions worldwide tells us that the answer is ‘no”. Hackers keep coming up with newer and newer combinations to beat WAFs. The best we can do is keep pace — keep updating our WAF signatures on a day-to-day basis and be on the lookout for new research in this direction. Companies are best off outsourcing this work to security experts rather than doing this task in-house.