Block rogue queries before they bite
A SQL (Structured Query Language) injection attack occurs when an attacker injects a piece of SQL script in order to manipulate the SQL script running on a database-driven web-application in an attempt to access/modify/delete something within the database. It can even execute certain administrative scripts.
The SQL injection attack is one of the most common attacks out there. Companies are getting hit by these attacks constantly. You’ve probably seen stories about user information getting posted on sites like PasteBin.
Business Impact of a SQL Injection Attack
The business impact can range widely depending on how vulnerable the database is. For example, if information is not encrypted (as it should be), the hacker might have access to customer login and credit card information. Neither of those should be stored visibly inside of a database.
An equally terrifying possibility is that the certain tables, or the entire database, could be deleted. If no backup is present, an entire web-application could stop functioning. Important data that was aggregated over the years would simply vanish.
Modifying ship-to addresses could result in the hacker receiving merchandise that should have been sent to a paid user.
These are just a couple out of an endless amount of possibilities that could occur with a successful SQL injection attack.
How Does a SQL Injection Work?
Hackers look for entry points on a website, usually forms, that are vulnerable. In other words, if the content that’s submitted is not escaped, the database is most likely vulnerable.
The hacker enters form details and presses submit. The form sends a POST request to the backend and a SQL query is constructed. This could be as simple as searching a product catalog by typing in a string, the backend server taking the string and adding it to form the overall query.
i.e. SELECT * FROM products WHERE keyword LIKE '%search_term%'
Once the query runs, the results are returned. The hacker starts by placing characters that they know will break a SQL query string. If they see that it’s breaking, it gives them first indication that data being brought in from the user is not sanitized. This could be as simple as putting in a single quote into a form field and seeing what the results obtained are. Receiving a server error is a sign that the doors are open. Properly constructed strings will know how to handle the request and will return the same type of response that would be returned if an acceptable character sequence was entered.
The following queries should return the same format:
- Apple — Here are all of the Apples in the database
- Rocks — There are no Rocks in the database
- ‘ — There are no ‘ in the database
Once the issue is detected, the hacker then thinks about what the SQL query might look like on the backend. Let’s say that our query looks like this:
SELECT * FROM products WHERE keyword LIKE '%users_search_term%'
If we look at our single quote example now, we can see why that might break.
SELECT * FROM products WHERE keyword LIKE '%'%'
The query sees an opening single quote, then a % and then another single quote. As soon as it sees the second single quote it stops the execution of the code.
The hacker can then verify that the query is functional again by adding closing the SQL query with a semi colon and adding a --
at the end, which converts everything after it to a comment.
Hacker submission: ';--
This gets interpreted as follows:
SELECT * FROM products WHERE keyword LIKE '%';--%'
The query now states, select everything from the products table that matches wildcard. Theoretically, it should return everything.
From this point on, hackers can extract database table information from the SCHEMA
table and can construct queries to extract data from a table such as users
.
This is part art, part science. Hackers will often rely on utilizing UNION
strings to increasingly extract more and more data. If they’re really malevolent, adding a DROP
statement at the end might actually delete an entire table from the database.
Hacker submission: '; DROP TABLE users;
How to Detect SQL Injection Vulnerabilities?
It usually all starts with a single quote form submission. If the application breaks, the site is likely vulnerable to SQL injection attacks. Boolean statement submission is the next likely scenario. Passing strings to form such as OR 1=1
and getting access is another sign that the database is open for the hacker to enter.
Hackers get creative with attempts, and it’s usually an automated approach with bots crawling the internet for vulnerable forms, so making sure that the application is safeguarded against SQL injections should be top of mind.
There are plenty of tools out there, some even open source, that can look for SQL vulnerabilities on your environment.
https://www.invicti.com/?source=post_page—–471de647e8d7
https://github.com/sqlmapproject/sqlmap?source=post_page—–471de647e8d7
How to Prevent SQL Injections?
Most modern programming frameworks will incorporate SQL injection prevention. Check with the framework that’s being used on your application, and the version, to make sure that you’re protected.
Prepared statements should always be utilized and characters escaped. An example of a prepared statement might look like this:
INSERT INTO products (sku, price) VALUES (?, ?)
You can then bind values to the parameters that were defined and specify the type of data type that’s being passed, such as a string
and a double
.
Cybersecurity Series
Continue your Cybersecurity Learning.
Cut out the silent middle-man
Cybersecurity — P8: Man In The Middle Attack
Part eight of our cybersecurity foundations series dissects Man-in-the-Middle attacks—stealth interceptions that relay or alter data between two parties. Learn classic setups, HTTPS downgrade tricks, Wi-Fi hijacks, and robust countermeasures.
Block rogue queries before they bite
Cybersecurity — P9: SQL Injections
Part nine of our cybersecurity foundations series uncovers SQL injection—the code-in-text attack that turns queries into weapons. See how attackers dump data, bypass auth, and own servers, plus parameterized query and ORM tactics that slam the door.
Patch comes later—attackers move now.
Cybersecurity — P10: Zero-Day-Exploits
Part ten of our cybersecurity foundations series exposes zero-day exploits—attacks that strike before a patch exists. Learn how researchers discover them, how attackers weaponize them, and what layered defenses buy you precious reaction time.