Page 14 - index

It turns out experienced pen testers will tell you every web application tied to a relational database is
vulnerable to SQL injection. “But how can that be”, you may be asking yourself. “We rewrote our web
applications and validated the code. We even installed a Web Application Firewall (WAF).”

Well here’s the issue with a WAF. A WAF attempts to detect SQL injection that’s attacking at the
database tier while examining the situation from the web tier. The WAF is too far removed from the
actual attack surface, it’s unable to determine how the application will interpret a very obscured SQL
injection attack. The WAF can’t see the actual rogue SQL statements that will be executed on the
database.

“If you’re solely relying on a WAF to protect your databases from SQL injection you’re in a sad state,”
said Joe McCray, CEO of Strategic Security. “The WAF uses signatures to catch the well known SQL
injection attacks and also automated SQL injection attack scripts. But a WAF won’t prevent a
determined hacker. My business is pen testing and I’ve not met a WAF that I couldn’t bypass, a few in
less than half of an hour.” Joe makes a very valid point. A web search for “WAF Bypass” returns many
thousands of articles and tutorials describing exactly how cybercriminals are able to conceal their SQL
injection attacks so they pass seamlessly through the WAF.

What about rewriting your web applications to remediate all possible SQL injection vulnerabilities?
Assuming your organization has sufficient resources and budget to accomplish such a monumental task,
it’s may be a reasonable idea. But it’s critical to utilize the proper coding practices necessary to actually
reduce your SQL injection vulnerabilities. For example, you’ll often hear that using stored procedures
will eliminate your SQL injection vulnerabilities. It turns out that’s not exactly correct. In reality you may
simply be relocating the SQL injection vulnerability from one part of your application into a stored
procedure. Basically you’ve simply moved the problem, because now the stored procedure is vulnerable
to SQL injection attack.

To properly remediate SQL injection vulnerabilities in your web applications you need to follow two
important coding principles; 1) never concatenate dynamic SQL from external input and 2) always use
parameterized SQL anytime you must use external input.

However, once all of your applications have been rewritten, using the above coding rules, you’re still not
out of the woods. Any third party software you’re running may be vulnerable to SQL injection. If the
framework you have written your application on is itself vulnerable to SQL injection, you have a big
problem.

After you’ve rewritten your web applications and validated all of your third party software you have
significantly reduced your SQL injection vulnerability, but not eliminated it. A determined cybercriminal
can create SQL injection vulnerabilities in your web application through malware. “With enough time
and determination, the web application itself can be exploited,” said Joe McCray. “It may be worth the
effort because the web application is already integrated with the database.” That’s a good point. The
web application and the database share a trusted relationship, a communications channel, and a

14 Cyber Warnings E-Magazine – August 2013 Edition
Copyright © Cyber Defense Magazine, All rights reserved worldwide