Skip to content

Why SQL Injection Attacks Still Need to be Dealt With

    
Why SQL Injection Attacks Still Need to be Dealt With
Another_Day_Another_SQL_Injection_Attack

Earlier this week, hackers claimed to have stolen $100,000 from users of a California-based ISP using a SQL injection attack. They even uploaded a video of it as proof. Even though $100,000 is a nice chunk of change, it pales in comparison to the damage done to the company's consumer trust levels. While it's easy to blame the attacker, the organization had a critical vulnerability and didn't make their applications SQL-Injection-Proof. Odds are, $100,000 isn't close to the damage done to the corporate brand by such a publicized breach of security.

But hacker attacks happen every day, every hour, every minute. They happen to governments and businesses alike. Hacks even happen to public relations newswire services (talk about a PR nightmare). In the aforementioned 100k instance, hackers used a SQL injection attack. So let's start at the beginning of SQL injection attacks to see how this attack happened and how it may have been prevented.

What is a SQL Injection Vulnerability?

A SQL injection vulnerability happens anytime untrusted data is combined into a SQL query. The result is that an attacker can change the meaning of that query by sending carefully designed syntax that changes the meaning of the query.  Essentially, they are tricking the application into asking the database to do things for them, like returning information for other clients or corrupting tables. Financial information, medical records, credit cards, and passwords are prime targets for the rich information stored behind supposedly "secure" firewalls.

SQL injection can happen in many different types of code. But we often find these vulnerabilities in web pages that result in "state-changing" operations, such as:

  1. Authentication pages (something that includes a username and password)
  2. Search engines (queries are placed in a search field)
  3. Reporting engines (requesting data from database)
  4. Transactions (details are committed to a databases)

SQL Injection such a big deal that the Open Web Application Security Project (aka OWASP) lists SQL injection attacks as one of the top ten web application vulnerabiltiies

What Does a SQL Injection Vulnerability Look Like?

Here is an example of a real SQL injection vulnerability.  In this case, the untrusted data comes from an HTTP Cookie which contains some Base64 encoded data.  An attacker could create a SQL injection attack, like "foo' or '1'='1" and encode it the same way and send it to the application.

Trace_SQL_Injection_(trace_only)

The trace shows how and exactly where the data is transformed as it flows through the application. Eventually it ends up in a SQL query that is sent to the database.  Contrast is so accurate because it can see all the parts of this transaction, from HTTP, into the code, into libraries and frameworks, and eventually into the SQL database. This whole analysis happens in less than 10 milliseconds, and the results are available to the developer immediately.

How Does Contrast Detect SQL Injection Attacks?

Contrast works by passively tracking untrusted data within your running applications. Unlike static and dynamic analysis, Contrast works inside the running application and has interactive access to the code, configuration, HTTP requests and responses, data flow, control flow, and backend connections. Access to all this information allows Contrast to detect places where your code is susceptible to attack accurately and in real time.

Contrast Regularly Identifies SQL Injection Problems Other Tools Miss

Recently, we identified dozens of new SQL injection vectors in an application with over 10 million lines of code that had been through static analysis, dynamic scans, and even manual penetration testing. The complex data flow and unconventional use of untrusted data to reference table names caused these problems to be missed by traditional tools.  But Contrast's amazing data flow engine handled this application easily.

Identifying the problem is nice, but Contrast goes one step further to help you with remediation because it tells you where you need to go to fix the code. With virtually no false-positives, and direct line-of-code reporting of vulnerabilities, Contrast can save you hours of work in both the detection and remediation of code.

Want to see an example of Contrast in action? Here is a brief video that can show you in under eight minutes how you can have a live dashboard of results after implementing it into your runtime code. runtime-application-self-protection-rasp

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.