We recently took a look at Cross Site Scripting (XSS) in a “Learning Series” blog article. In this blog article we’re going to turn our focus to SQL Injection, sometimes abbreviated as SQLI. Like XSS, SQL Injection has been on the OWASP Top 10 list of web application risks since the initial publication of the list in 2003. The most recent incarnation of the OWASP Top 10 has SQL Injection included in a broader category labeled, “Injection” and is number one on the Top 10 list of risks. For a threat that’s been around since the inception of the OWASP Top 10 list, it should be troubling that 26 percent of all small businesses have suffered from a SQL Injection attack in the last year. And according to a recent article it remains one of the least-talked about threats to organizations.
What is SQL Injection?
SQL injection essentially involves the insertion of “text” that when read by the application is converted to a query into an SQL database to retrieve data that should not have been accessible through the application. The earliest known SQL Injection attack was discovered in 1998. The simplest example of SQL injection would be a login page with two fields, “username” and “password”. A website set up display your current user profile might require a username and password in order to validate your identity, and validates the username and password by sending a SQL database query, something like:
Assuming a valid username and password, this query would return the user’s city, country, email, phone and first and last name. Now let’s assume a hacker decides to try SQL Injection to get hack this private information from the web application. If the web application did not have any type of coding protection or security protection against SQL Injection, a hacker could simply enter a “username” in the “username” field and “password’ OR ‘1’=’1” in the password field. In an unprotected application this would create the query:
In this case even if the username and password are not correct, the database query would still return the user’s personal information, since the “‘1’=’1′” would come back as “TRUE”, satisfying the SQL query’s “where” statement.
The cyber criminal has essentially hacked the system and gotten personal information without knowing the user’s password. There are of course many more sophisticated variations on this attack, but the “1=1” trick is the simplest and most well-known. Variations on SQL Injection have caused notable data breaches. In February 2002, Jeremiah Jacks discovered that Guess.com was vulnerable to an SQL injection attack, allowing anyone knowledgeable enough to be able to construct a properly-crafted URL to pull down 200,000+ names, credit card numbers and expiration dates in the site’s customer database.
SQL Injection is so ingrained in IT folklore, it even made it to the popular XKCD comic strip:
A recent article from entrepreneur.com gives us some insight into one type of application that significant SQL Injection attack risk:
Older languages, such as PHP, are particularly susceptible to SQL injection attacks, as are sites and applications that don’t receive regular updates.
The article also brings up a good reminder, that no matter how well you’ve coded your application, you should also makes sure all the software you’re using is updated.
If you’re interested in seeing more examples of SQL Injection as well as learn about some of the coding recommendations to prevent SQL Injection attacks, head over to unixwhiz.net and check out their very detailed page on SQL Injection attacks.
Securing your application against SQL Injection attacks
A great start for protection against SQL Injection attacks is using runtime application security. The latest draft version of the NIST Framework for SP 800-53 now includes RASP (Runtime Application Self Protection), as a requirement for an organization’s security framework. By having security that’s close to the application, you get greater visibility and understanding of when an attack is happening, and better tools to control the attack. Traditional security tools like Web Application Firewalls (WAFs), sit on the network perimeter, and can miss nuanced and sophisticated attacks.
K2’s runtime deterministic application security platform monitors the application and has a deep understanding of the application’s control flows, DNA and execution. By validating the application’s control flows, deterministic security is based on the application itself, rather than relying on past attacks to determine a zero day attack. Deterministic security results in the detection of sophisticated zero day attacks and also protects from application from the risks listed in the OWASP Top Ten, including Injection attacks.
In addition to providing runtime application security, K2 can also help with faster vulnerability remediation in your web application code during your penetration testing cycle. The K2 agent is deployed on the pen testing/QA server and no change in testing methodology or setup is required. K2 works in conjunction with your existing scanning tools or pen testing tools. K2 creates a vulnerability report at the end of the testing cycle detailing additional telemetry on the vulnerability including which file and line number in the code has the vulnerability. K2 can also find additional vulnerabilities in the application that the testing tools may have missed.
K2’s Next Generation Application Workload Protection Platform addresses today’s need for runtime security in an easy to use, easy to deploy solution. K2’s unique deterministic security detects new attacks without the need to rely on past attack knowledge, is lightweight, and adds under a millisecond of latency to the running application. To aid in quick remediation of vulnerabilities, K2 also provides detailed attack telemetry including the code module and line number being in the code being attacked, while at the same time integrating with leading firewalls to do real time attacker blocking.
Change how you develop and protect your applications.