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.
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.
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.
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
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–+
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.
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.
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.
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.
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
This blog post provides a theoretical view of SQL injection which has been around for decades and will most likely continue to pose a threats to websites and security systems. The key to avoid being the victim of the next huge SQL injection data breach is first, to control and validate user input, and second, to prepare yourself for the “when,” not the “if.”
Join Us for a Real Time Career Guidance…