SQL Injection Attacks (SQLi) — Web-based Application Security, Part 4

How secure is your organization’s web presence? The statistics are pretty alarming – Acunetix’s Web Application Vulnerability Report 2019 scanned 10,000 websites over a year and found that 46% have high-security vulnerabilities, and 87% have medium-security vulnerabilities.

In this blog series, we shine the spotlight on the Top 5 vulnerabilities with pointers to secure your web presence. Here are a few of our past deep-dives: Part 1: Open Redirection Vulnerability, Part 2: Cross-Site Forgery and Part 3: Cross-Site Scripting (XSS) Vulnerability. In this part, we analyze the second-most prevalent vulnerability and one of the oldest – SQL Injection.

Understanding the SQL Injection Attack Vulnerability

SQL Injection is a type of Injection Attack – the basic premise being the insertion of untrusted input in a valid command or query, which then maliciously alters the execution of that program. The other types of Injection Attack vectors include the widespread XSS attacks, injection via code, email, LDAP and XPath. SQL injection has such a long and infamous history, that it even finds its place in popular culture – in StarTrek and J.K. Rowling’s “The Casual Vacancy” amongst others.

OWASP describes SQL Injection as follows, “A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data, execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.”

A high-level diagram of a SQL Injection Attack.

In Action: SQL Injection Attack

With attacks tracing back to 2002, SQL injection has a formidable track record with plenty of real-world examples. Here is a sample walkthrough of an attack:

Consider that your application has a SQL command as follows where uname and pwd are POST inputs from the user.

SELECT * FROM users WHERE user_name = ’” + uname + “’ AND password=’” + pwd + “’”

Recommended for You

Webcast, July 31st: 3 Foolproof Ways to Grow a Massive Email List

The attacker enters the password as password’ OR 1=1; DROP TABLE

As “1=1” always holds true, when the query is run, the entire table of users would be deleted.

A viral xkcd cartoon from way back in 2013 (that led to SQL Injection being renamed as Bobby tables), elegantly and amusingly highlights how SQL Injection attacks are simple to execute, but potent enough to cause serious damage.

Comic courtesy of XKCD.

The ease with which SQL Injection aka Bobby Tables can easily break your applications is why it still continues to be a top attack vector. The last major attack being a few months ago, where a SQL Injection vulnerability in the immensely popular Fortnite video game website allowed attackers to gain access to all their user accounts.

What’s most deadly about a SQL Injection attack though is that the repercussions do not end with a website shut-down as with a Denial of Service attack. The consequences are far-reaching – all that valuable user information is sold to identity theft “wholesalers” on the dark web (an “invisible” part of the internet that is typically used for unlawful activities). Reports say that access data from 70% of top US and EU websites is being sold on the dark web, because basic cybersecurity measures to prevent vulnerabilities like SQL Injection are not being implemented.

Preventing the Injection Attack Vulnerability

Here are some basic coding hygiene practices to secure your organization’s website from XSS attacks:

• Parameterize your Queries instead of directly embedding user input in them.
• Escape the characters that have a special meaning in SQL.
• Pattern-check your parameters.
• Restrict access to sensitive tables with database permissions

For further details on preventing SQL Injection attacks, check out OWASP’s SQL Injection Prevention Cheat Sheet.

Stay tuned for the next part of our Web Application Security Series where we examine the XML External Entity vulnerability.