About
It’s one of the most popular hacking techniques, but also one of the oldest and most prevalent, used in an estimated two-thirds of web app attacks today.
Description
Injection occurs when an actor can send untrusted data to an interpreter as part of a command or query. Malicious data can then be transmitted into an external system and trick the interpreter into executing unintended commands or accessing data without proper authorization. Almost any source of data can be an injection vector. It is more likely when applications enable users to load data without some type of input validation, sanitization, or filtering. Successful injection can result in data loss, exploitation, or disclosure of information to unauthorized parties, loss of accountability, or denial of access. Sometimes it can also lead to complete host takeover.
The most common injection vulnerabilities are often found in:
SQL
LDAP
Xpath
NoSQL queries
OS commands
XML parsers
SMTP headers
Expression Language (EL)
Object Graph Navigation Library (OGNL)
Object Relational Mapping (ORM)
Legacy code is highly susceptible to injection as well since it is often left unsecured, minimally scanned, or located on systems with out-of-date operating systems and minimal security implementations.
When examining the code, these flaws are easily discovered. Therefore, performing source code review is the best method of detecting it, closely followed by thorough automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs. Using static code analysers or DASTs and fuzzing is another way to discover these vulnerabilities.
These are also great ways to prevent them from entering the production environment. If the flaw is identified while in the test environment, proper intervention and secure coding practices can be implemented and retested to ensure a better configuration. There are other ways to deter injection, but they depend highly on the needs of the application. The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface or migrates to use Object Relational Mapping Tools (ORMs). Whitelisting is another option to prevent injection. However, this is not complete protection, as many applications require special characters. Nonetheless, prevention requires keeping data separate from commands and queries.
SQL Injection
Most large websites or web apps usually have at least one interactive area where the content changes based on a user’s input. Examples might be:
· e-commerce sites that populate products based on a search query;
· membership sites that ask for a username and password;
· review sites that allow user-submitted content.
Web servers interact with database servers anytime they need to retrieve or store user data. SQL statements are designed so that they can be performed while the webserver is retrieving content from the application server.
This injection flaw depends on the fact that SQL makes no distinction between the control and data strata. It is a technique, practiced exploiting user data through web page inputs by injecting precisely crafted SQL commands as statements. These statements can be used to manipulate the applications’ web server and trick the system into doing unexpected and undesired things.
The attack consists of insertion or “injection” of a malicious SQL query through the input data into the application to perform the execution of arbitrary SQL commands. Instead of a JavaScript, Python, Perl, or other scripting languages, malicious SQL commands are inserted into the content of the user input. Without enough removal or quoting of SQL syntax in user-controllable contributions, the generated query can cause those inputs to be interpreted as SQL, furthermore, enabling an attacker to interfere with the queries that application makes to its database. Commands convince a database to disclose all sorts of information because it trusts the query created from the app. This can be done to bypass security checks or to inject additional statements that alter the back-end database.
Successful SQLi lets an attacker view data usually not able to retrieve. This might include data relating to other users or any other data that the application itself can access. In many cases, an attacker can also change or erase this data, causing persistent changes to the application's content or behaviour. In some situations, the attack can escalate and compromise the underlying server or other back-end infrastructure, or conduct a denial-of-service, give the attacker administrator privileges, etc.
Overview
Language: Structured Query Language (SQL) is a programming language designed to manipulate and manage data in a database. It enables programmers to »talk« to large databases using nearly plain English. Since its beginning, SQL has steadily found its way into many commercial and open source databases.
Platform: Any, but it requires interaction with a SQL database.
SQLi has become a common issue with database-driven websites, but it can be used to attack any type of SQL database directly. The flaw is easily detected and exploited, and as such, any site or software package with even a minimal user base is prone to be subject to this kind of attack. The problem is that when proper precautions aren’t in place, websites can sometimes be easily tricked into running malicious SQL queries. Due to the predominance of older functional interfaces, SQLi is very common with PHP and ASP applications. It is less likely in J2EE and .NET applications, because of the nature of programmatic interfaces available.
How to detect SQLi Vulnerabilities
SQLi can be identified manually by using a systematic set of tests against each insertion point in the application. As in all types of injection, source code review is the best method of detecting this vulnerability. For more see the OWASP Code Review Guide article on how to Review Code for SQL Injection Vulnerabilities. See also the OWASP Testing Guide article on how to test for SQL Injection Vulnerabilities.
Potential impact
SQLi vulnerabilities and solutions are well known, but they may require costly projects to improve or replace vulnerable systems. Furthermore, companies and organizations often don’t have or are unwilling to spend money on fixing that issue.
SQLi has the potential to be incredibly damaging to any business or individual. If completed successfully, it allows attackers to read, tamper or/and modify existing data. Moreover, to execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system, and in some events issue commands to the operating system and gain access to the system itself. It can cause repudiation issues (such as voiding transactions or changing balances), disclose or erase all data on the system or make it otherwise unavailable, and permit the attacker to become administrator of the database server. This can result in unauthorized access to sensitive data, such as passwords, credit card details, or personal user information.
The main consequences the business will face are:
Confidentiality breach, since SQL databases generally hold sensitive data.
Loss of integrity since it is also possible to make changes or even delete information.
However, the impact depends on the needs of the application and data.
How to prevent SQLi
Prevention measures are relatively easy to implement. Most cases of SQLi can be evaded by adopting frameworks that interact with the database and parameterized queries (also known as prepared statements), instead of string series within the query.
Common examples
There is a wide variety of SQLi attacks and techniques, which arise in various situations. Some common SQLi patterns include:
Retrieving hidden data, where you can adjust an SQL query to deliver additional results.
Suppressing application logic, where you can modify a query to interfere with the application's logic.
UNION attacks, where you can recover data from different database boards.
Examining the database, where you can obtain information about the version and structure of the database.
Blind SQLi, where outcomes of a query are not returned in application responses.
Cases
Many high-profile data breaches in recent years have been the result of SQLi attacks, leading to reputational damage and regulatory fines.
TalkTalk case: In October 2015 SQLi attack was used to steal personal information of 156,959 customers from the British telecommunications company. The attacker accessed private data, including customer names, addresses, dates of birth, phone numbers, email addresses, bank account details, and sort codes. ICO investigation found that the attack took advantage of technical weaknesses and could have been prevented if they had taken fundamental security measures to protect customers’ data. The company failed to check its infrastructure for possible threats properly. It was unaware that the installed version of the database software was outdated and no longer supported by the provider. They did not know that the software was affected by a bug that allowed the attacker to bypass access restrictions. Furthermore, ICO stated that SQLi is well understood, safeguards exist, and TalkTalk ought to have known it posed a risk to its data. On top of that, the company had two early warnings that it was ignorant of (a successful SQLi attack on 17 July 2015 that exploited the same vulnerability and the second attack in September 2015). ICO investigation was limited to TalkTalk’s compliance with the Data Protection Act. It concluded that TalkTalk failed to have in place the appropriate security measures to protect the personal data it was responsible for. This is a breach of the seventh principle of the Data Protection Act. The company has been issued with a record £400,000 fine for security failings. A criminal investigation by the Metropolitan Police has been running separately.[1]
US Election Assistance Commission: A hacker tied to the November 2016 penetration of the US Election Assistance Commission and subsequent database sale has successfully targeted 60+ government agencies and universities by leveraging the same attack method: SQL injection.[2]
By curbing the creativity and persistence of hackers, Starbucks and the U.S. Department of Defense avoided potentially significant financial loss and national security damage, when @alyssa_herrera and @spaceraccoon reported SQLi vulnerabilities.[3]
IBM, Yubico, Cisco, SOPlanning, D-Link, Plone, US Gov Federal Deposit Library, Government of Gibraltar are just a few of the companies that have also been the target of an SQLi attack this year.[4]
____________________________________________________________________________________________
References and more information:
Last updated
