_edited.png)
Before we get into the topic of "SQL Injection", let's first define SQL (or Structured Query Language). It is the language used to communicate with relational databases; it is the query language used by developers, database administrators and applications to manage all types of data generated every day. Not to be confused with a relational database management system (RDBMS or RDBMS) such as Postgresql, MariaDB or MSSQL.
What's in it for the attackers ?
SQL injection is one of the oldest vulnerabilities still present in the OWASP TOP 10 for more than fifteen years. It allows to steal and modify information (sensitive or not), accessible in millions of databases worldwide.
Data seems to have become one of the world's most coveted commodities... and when something is valuable, it attracts the attention of unsavoury people who will want to get their hands on it at any price.
So developers need to understand SQL injection if we are to protect ourselves from it.
Understanding SQL injection
Within an application, two contexts exist:
one for the data,
and one for the code.
The code context tells the computer what to execute and what to separate from the data to be processed. SQL injection occurs when an attacker enters data that is mistakenly treated as code by the SQL interpreter.
Take for example: the input field of a form (username/password combo) on a website, where an attacker enters "' OR 1=1;". This specific string is added at the end of an SQL query. When this query is executed, it allows the attacker to bypass authentication without knowledge of the password.
The implications of SQL injection can be catastrophic. If this happens on a login page, it can return all user records, including usernames and passwords. If a simple query to retrieve data is successful, queries to modify data will also be successful.
Why SQL injection is so dangerous ?
One observation can be made from an Imperva Web Application Attack Report (WAAR) published in February 2020: 29% of web applications are still vulnerable to SQL injections.
Here are three examples of breaches caused by SQL injection:
The plugin security of one of the most popular content management systems (CMS), Wordpress, is reportedly vulnerable to many web exploits. Spanish security researchers Jacinto Sergio Castillo Solana and Manuel Garcia Cardenas have discovered more than 5,000 vulnerabilities, including 4,500 SQL injection (SQLi) vulnerabilities in over 84,000 plugins. Vulnerabilities involving WordPress plugins have become a well-documented source of secondary problems affecting websites. (Source)
Hetzner, a South African web hosting company, suffered a breach of 40,000 customer records. An SQL injection vulnerability led to the possible theft of every customer record in their database. (Source)
A new type of SQL injection has emerged in 2019, "Voice-Command SQL Injection". As the name suggests, this attack relies on voice commands to perform the injection. In order to illustrate this vulnerability and create greater awareness, Protego's Head of Security and Ethical Hacking, Tal Melamed, illustrates how a simple SQL injection can be executed via a spoken command to gain unauthorised access to sensitive account data. This demonstration shows how, in this case, Alexa, can be exploited in an unprotected application, by translating words and numbers. (Source)
Sensitive data can be used to take over accounts, reset passwords, steal money, impersonate you or commit fraud.
Information that is not considered sensitive or personally identifiable can also be used for other attacks. Addresses, coupled with other information, can be used to impersonate companies or reset your password, for example.
When an attack is successful, customers may lose confidence in the company. Recovering damage to systems or paying regulatory fines can cost millions of euros.
But it doesn't have to be that way.
Defeating SQL injection
SQL injection can be defeated by clearly labelling the parts of your application, so that the computer knows whether a certain part is data or code to be executed. This can be done by using parameterised queries.
When SQL queries use parameters, the SQL interpreter will only use the parameter as data. It does not execute it as code.
For example, an attack such as "' OR 1=1;" will not work. The database will look for the string "OR 1=1;" within it and not find it. It will simply shrug and say, "Sorry, I can't find that for you."
Most development frameworks provide built-in defenses against SQL injection.
Object Relational Mappers (ORMs), such as the Entity Framework in the .NET family, will set queries by default. This will support SQL injection without any effort on your part.
However, you will need to know how your specific ORM works. For example, Hibernate, a popular ORM in the Java world, can still be vulnerable to SQL injection if used incorrectly.
Query parameterisation is the first and best defence, but there are others. Stored procedures also support SQL parameters and can be used to prevent SQL injection. Keep in mind that stored procedures must also be constructed correctly for this to work.
Always validate and sanitise your inputs. Since some characters, such as "OR 1=1;", will not be entered by a legitimate user of your application, there is no need to allow them. You can display an error message to the user or remove it from your input before processing it.
However, don't rely solely on validation and sanitisation to protect you. Malicious people have found ways to circumvent this solution. These are good Defence in Depth (DID) strategies, but setting up is the surest way to cover all bases. Ideally, the defences should be combined.
Another good defence in depth strategy is to use "least privilege" in the database and whitelist entries. Least privilege means that your application does not have unlimited power in the database. If an attacker were to gain access, the damage they could do would therefore be limited.
OWASP has an excellent "Cheat Sheet" on SQL injection that shows how to handle this vulnerability in several languages and on several platforms...
Finally, another solution is to call on our services in order to benefit from our expertise and our advice to help you optimise and customise the security of your web applications.
Do not hesitate to contact us for more information and, if you wish, to obtain a free personalised quote.
Related blog posts:
Did you enjoy this blog post?
Find more content related to cybersecurity and GDPR regulatory compliance on the CyberSecura blog!
We need your answers!
By completing this survey, you are helping us to better understand your interactions with our site and your potential needs.
Your answers are anonymous, and unless you ask to be contacted again by our teams, no personal information is requested!
Thank you for your responses!
Would you like to be informed of our news and receive our latest blog articles directly in your mailbox ? Subscribe to our monthly newsletter!
Would you like to discuss your difficulties, your needs, our offers ? Ask to be contacted, free of charge and without obligation, by one of our cybersecurity experts !
Comments