SQL injections are one of the most popular types of injection attacks for web applications. It affects roughly 25% of web applications, and it is relatively easy to perform. Due to this, developers need to understand how to defend against these types of attacks and proactively test their applications to see if they are vulnerable to attack. Here are our top tips for defending against SQL injection attacks.
How does an SQL injection attack work?
A SQL injection consists of inserting an SQL query into an input form on a webpage. If that input form doesn’t effectively filter out the SQL query before processing the input, the SQL commands are executed by the SQL database. A successful SQL injection can lead to several bad outcomes, including reading sensitive data from the database, data deletion, insertion, update, execution of administrative operations on the database, and even issuing commands on the web servers operating system. If a web application or website uses Oracle, SQL Server, or MySQL, it can be vulnerable to a SQL injection attack. SQL injection has routinely been ranked as one of the top vulnerabilities in the OWASP Top 10 and is a severe security issue.
Tips for preventing SQL injections
Input Validation
The validation process is aimed at determining whether or not the input provider by a user is acceptable. In addition, it ensures that the input received is of the accepted type, length, format, etc. Only if the value passes all of these security checks will it be processed, and this filters out any attempted SQL injection attacks. It’s important to apply this not only to fields where users are allowed to type in input. It also applies to fields like dropdown lists or structured data like name, age, income, etc. By default, block all types of input and only whitelist inputs that meet specified criteria. We refer to this as an “implicit deny” policy within cybersecurity, where only items explicitly allowed processing items.
Parameterized Queries
Using this technique, you create a pre-compiled SQL statement and use the input provided by the user for only a portion of the SQL statement. This way, regardless of what the user gives as input, it will not change the overall intent of the SQL statement. For example, if we want a user to provide their name. We should create an SQL statement and learn a portion of the statement with a variable called “name.” Then, when the user provides their input, it will be quoted and used in place of the variable name. Since we have hard-coded all of the other portions of the statement, they can’t manipulate the SQL database to perform a malicious action because the user input is only responsible for a tiny part of the overall SQL statement.
Stored Procedures
A stored procedure is a means of grouping one or more SQL statements into a unit to create an execution plan. Then, whenever one needs to run these SQL statements in the future, rather than re-writing the code, call on this execution plan and execute the code. It works similarly to creating a function in regular programming; instead of creating secure SQL queries in response to a user’s input, call on one of the stored procedures known to be safe and execute that to get the information we need from the database.
Character Escaping
Most database management systems come with character-escaping functions for user-supplied inputs. This helps ensure irrespective of what the user puts into the input form. Furthermore, it will never be confused with the SQL statement created by the developer.
Don’t Use Administrator Privileges.
If at all possible, avoid connecting your application to any database with root access. This way, if someone does find a way to perform an SQL injection or any other type of injection attack like XSS, it won’t be able to do as much damage. If one of these attacks is carried out with root-level access, it can do anything, while if it runs with lower-level privileges, this will mitigate the damage. Therefore, enforce the least privilege and only use the amount of access you need to get the job done.
Web Application Firewall (WAF)
WAFs are great for overall web application security, and they are a great tool for preventing SQL injection. Essentially, a WAF sits in between your web application and the internet and filters traffic based on predetermined rules. It can look for many things, including screening for potential SQL injection attacks. This way, it serves as an automated defense against SQL attacks and several other attacks such as XSS, DDOS, and cookie poisoning.
SAST and DAST Tools
This stands for “static/dynamic application security testing tools.” These are tools used to scan either source code or a complete web application to see what security vulnerabilities they have. For those without a strong understanding of cybersecurity, this can be a great way to check one’s work without hiring a security consultant. For example, not only will this check for SQL injections, but it checks for a vast amount of security vulnerabilities in both source code (SAST) and at runtime (DAST).
Hide the Database Version
As previously mentioned, any database that uses SQL such as Oracle, SQL Server, or MySQL has the potential to be exploited in a SQL injection attack. One way to reduce the likelihood of being targeted is to hide the exact type of database being used. If the type and version of the database are not apparent, one can avoid being targeted to some degree. This means making sure not to post this information anywhere on the website or web application and check that error codes don’t reveal any of this information.
Recap
SQL injections are a type of web application attack that targets the SQL database of an application. The attacker inputs SQL queries via input forms on the application and tries to alter the database (update, delete, or read from the database). To defend against this type of attack, filter out user input to prevent these queries from being executed by the webserver.
