- Injection is a type of security flaw that has topped the OWASP Top Ten since around 2010.
- Currently, it is ranked as an A1 vulnerability.
- So it is not a new vulnerability, and despite information on how to prevent it, it continues to be a problem.
- Any application that allows user input is potentially vulnerable to injection.
What is an SQL 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 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. For instance, 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 Python, Pearl, or other script types, hackers embed malicious SQL commands 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 one has separated untrusted data 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 uses the same communication channel to both launch the attack and gather results.
- Error-Based SQLi
This technique relies on error messages thrown by the database to obtain hints about the DB structure. An 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. In conclusion, 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.
- 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. Moreover, the 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 you can detect the vulnerability while in the test environment, you can implement and retest proper mediation and secure coding practices to ensure a better configuration.
- If you separate data is from commands and queries, you can prevent injection.
- Limit database permission and privileges
- Whitelisting and sanitizing user inputs is another option to prevent injection.
Above all this blog post provides a theoretical view of SQL injection which has been around for decades and will most likely continue to pose a threat to websites and security systems. If you do not want to be the victim of the next huge SQL injection data breach is firstly, to control and validate user input and secondly, to prepare yourself for the “when,” not the “if.”