This Injection Doesn’t Come with a Lollipop: How SQL Attacks Sneak Past Your Code
- Jen C
- Nov 7
- 2 min read
Do you look forward to receiving an injection?
No?
The same applies for our systems!
Let’s learn more about SQL injections and how this can impact our applications!
“Injection slides down to the third position. 94% of the applications were tested for some form of injection with a max incidence rate of 19%, an average incidence rate of 3%, and 274k occurrences. Notable Common Weakness Enumerations (CWEs) included are CWE-79: Cross-site Scripting, CWE-89: SQL Injection, and CWE-73: External Control of File Name or Path.” - OWASP Top 10:2021
What is a SQL Injection Attack?
In the OWASP 2017 Top Ten list, SQL Injection was listed as the number one threat to web application security. It’s the oldest, most common, and most dangerous of web application vulnerabilities. Sounds malicious! It is. Plain and simple, it’s executing malicious SQL code to capture sensitive data such as
passwords, credit card details, and personal user information. SQL Injection Attacks have been the culprit of many data breaches in previous years. Target, Yahoo, Zappos, Equifax, Epic Games, TalkTalk, LinkedIn, and Sony Pictures, just to name a few.
When is an application vulnerable to an attack?
Data that the user enters has not been validated, filtered, or sanitized, and is used to extract sensitive records.
So how does this happen?
One example is a threat actor searching a web page or web application for vulnerable user inputs. If the vulnerability exists, the site can ask the user for input (username/user ID), and the threat actor can create “input” content that the site unknowingly executes on the database, thereby executing malicious SQL commands. They can alter/update data, add, or delete data, including sensitive data, from the database. One example of a financial application that could be vulnerable to an SQL injection modifies account balances. They can even access and impersonate users' credentials. It could even be admin
rights! Not good indeed.
Here are a few links to OWASP Cheat Sheets:
But what can “I” do to prevent a SQL Injection Attack?
If you’re involved in building the web application, make sure you understand the risks of an SQL injection.
User whitelists to verify and filter user inputs.
Keep your development environment and languages up-to-date. That includes libraries, plug-ins, frameworks, server software, and database server software with
the latest security patches.
Don’t trust any user input. We can prevent this by keeping data separate from commands and queries via APIs. Here are a few other ways:
Input validation
Parametrized queries/prepared statements
Sanitize all input
Remove single quotes from inputs
Use a vulnerability scan before pushing code to production..
Do not share database accounts between different websites or applications.
Ensure you have error reporting and handling in place.
Practice the principle of least privilege when connecting accounts to a SQL database. If you only need to retrieve content, don’t give rights to other functionality such as insert/update/delete.
You can learn more about testing for SQL injections at: OWASP Testing Guide: SQL Injection, Command Injection, and ORM Injection
Comments