What is SQL Injection Attack?
It is one of the most common and SQL dangerous methods hackers can use to attack websites using the SQL injection attack method.
We’ll talk about how to execute and mitigate web application attacks such as SQL injection, command injection, and cross-site scripting.
SQL is used to operate queries and administer database systems. Like Microsoft SQL Server, Oracle, and so on.
One of the most widely used SQL attacks is the SQL injection attack.
A successful SQL injection exploit can read sensitive data from the backend database.
It can also modify or delete data or execute administration operations.
Sometimes it can even issue commands to the operating systems.
So for example a web page might authenticate requesting a username and password.
Once the user provides the information. It’s passed to the backend database to validate the credentials to allow access.
This is where the threat actor can supply. Specially crafted data in the SQL injection attack which has a malicious code
Instead of authenticating the user, it may cause the application to display the contents of the user database.
Successful SQL injection attacks can have far-reaching implications.
This actually occurred back in 2012. When a hacking group collected the email credentials for 450000 users. Using an SQL injection attack against an unnamed yahoo subdomain.
SQL injection attacks used to bypass authentication disclose confidential information and distribute malicious code. This makes SQL servers a high-value target for threat actors.
The SQL injection attack uses attacker supply data to alter web application SQL statements.
Unless an application uses strict input data validation it is vulnerable to this attack.
In fact,
The open web application security project or o wasp lists it as the number one threat to web applications.
Now let’s look at some various SQL injection attacks.
First is an authentication bypass
Here it allows an attacker to log on to an application without supplying a valid username and password.
Next is an information disclosure
It is used to obtain sensitive information from a database.
The third is compromise availability of data.
Here the compromised data integrity involves altering the contents of a database. To either deface a web page or insert malicious content.
Compromised availability of data allows an attacker to delete information. Either cause harm or delete log and audit information and finally is the remote command execution.
Here it allows an attacker to compromise the host operating system.
Now let’s talk about how to mitigate SQL injection attacks.
An intrusion prevention system or IPS signature used to detect and prevent SQL injection attacks. As long as it has visibility into the application traffic.
End-to-end encryption with HTTPS. For example, hinders the ability of the IPS to spot the signatures of the attack. So you should be sure to update to IPS.
The latest and current signature releases detect new threats. Which are continually developed by the threat actors.
Here is a generic signature for detecting SQL injection attacks from snort. Which is actually a free open source network intrusion detection system or IDS.
This signature relies on regular expressions for the ids to work properly.
Now everyone is fluent right in using expressions and their use. Signatures can make it appear very complicated and confusing but fortunately, there are many examples available out there.
So examining these examples. The built-in snort signatures will help you in developing your own custom rules to detect attacks.
SQL Injection Attack Example
This is the SQL vulnerable application we’ll be trying to hack with a SQL injection attack.
Here are the application logs.
What happens here when we interact with the SQL vulnerable application?
First, let’s try guessing the password.
Okay so guessing the password didn’t work.
let’s try adding a quote character SQL after the password.
The application crashed with an SQL unexpected error. what could that mean? The logs show a SQL syntax error this indicates that the quote character messed something up in an unexpected way.
This is what the application code looks like behind the scenes.
What shall the SQL code gets built as we enter the log in detail?
let’s enter the password with a trailing quote character once more.
The quote is inserted directly into the string and terminates the query early.
This is what caused the syntax SQL error we saw in the logs. This behavior indicates that the application might be vulnerable to SQL injection.
Now let’s try a specifically crafted password. We’re in we successfully gained access to the application without having to guess the password using SQL injection.
The double dashes we entered cause the database to ignore the rest of the statement allowing us to be authenticated. Without having to supply the real password.
