SQL Injection & Types, Impact and Prevention

What is an injection vulnerability?

An injection happens when a bad actor sends some type of malicious data through an application. That malicious data can be relayed through the application into an external system. Injection is partly made possible when applications allow users to input data without some type of input validation, sanitation or filtering. Poorly designed applications can allow entire scripts to be injected via user input. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc.

SQL is possibly the most common and widespread injection type. Instead of a Python, Pearl, or other script type, malicious SQL commands are embedded into the content of the user input.

How to check for vulnerability

Checking the code is a fast and accurate way to see if the application uses interpreters safely, i.e untrusted data is separated from commands and queries.

Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application.

Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws.

Types of SQL injection

In-band/Classic SQLi

In-band SQL Injection is the most common and easy-to-exploit of SQL Injection attacks. In-band SQL Injection occurs when an attacker is able to use the same communication channel to both launch the attack and gather results.

1. Error-Based SQLi

This technique relies on error messages thrown by the database to obtain hints about the DB structure. Attacker sends a malicious query to the database which results in errors. On a live site, errors should be disabled or very generic

Example: www.vuln-web.com/photo.php?id=1′

The above query will result in a syntax error and might reveal the backend database type.

2.  Union-based SQLi

This technique uses union command in SQL query to execute additional queries; thereby, modifying / inserting/deleting or dropping the contents of the table.

Example: Query : Select table_schema from information_schema.schemata

Injection : http://fakesite.com/report.php?id=-23 union select 1,2,version(),4,5–+

Inferential/Blind SQLi

A Blind SQL injection attack doesn’t reveal data directly from the database being targeted. Rather, the attacker closely examines indirect clues in behavior. Details within HTTP responses, blank web pages for certain user input, and how long it takes the database to respond to certain user input are all things that can be clues depending on the goal of the attacker.

1. Boolean-Based

This technique relies on sending an SQL query to the database which forces the application to return a different result depending on whether the query returns a TRUE or FALSE result. Wrong queries don’t generate any result so the attackers try to generate logically correct queries. This is a typically time consuming method.

2.  Time-based

This technique relies on sending an SQL query to the database which forces the database to wait for a specified amount of time (in seconds) before responding. The response time will indicate to the attacker whether the result of the query is TRUE or FALSE. If a time delay is observed, one can conclude that the input syntax used can be utilised for further elaborate injections. This is a time consuming process.

Real-life SQL injection attack

In August 2014, the IT security company Hold Security revealed that Russian hackers had stolen 1.2 billion logins and passwords on 420,000 websites around the world. And this would have allowed the group of hackers “CyberVor” to access 500 million email accounts. Hackers used programmed botnets to visit sites and perform vulnerability tests. In order to exploit SQL injection vulnerabilities and access databases. If the attack is notifiable on a large scale, it has ultimately had no major consequences. According to the FBI, the information has only been used in a large spam campaign on social networks for instance but this hacking record remains a mystery for the organization.

SQL attack steps

• Searching for a vulnerable point
• Fingerprinting the backend DB
• Enumerating or retrieving data of interest – table dumps, usernames/passwords etc.
• Eventual exploiting the system once the information is handy – OS take over, data change, web server take over etc

Impact

OWASP categorizes the impact of the Injection attack as severe. Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover. What’s even more troublesome is that SQL injection, the number one application risk in the 2017 OWASP Top 10, is stubbornly difficult to eliminate. Veracode’s research for 2017 State of Software Security (SOSS) report, found that 28 percent of applications have a SQL injection vulnerability, a figure that hasn’t changed much over the past five SOSS reports

How to prevent Injection

• Performing source code reviews, using static coder analyzers or DASTs
• If the vulnerability is detected while in the test environment, proper mediation and secure coding practices can then be implemented and retested to ensure a better configuration.
• If data is separated from commands and queries, injection can be prevented.
• Limit database permission and privileges
• Whitelisting and sanitizing user inputs is another option to prevent injection.