A03:2021 – Injection

Injections are a type of vulnerability consisting of an attacker sending untrusted data through a request or query to an interpreter, causing a disruption in the execution flow or the behavior initially intended for the application. 

In this way, actions can be carried out ranging from the extraction of additional information about the attacked system, to the theft of a user session or even the remote execution of commands and the subsequent takeover of the web server itself where the hosts the application.

Injections have been classified as the most critical and constant throughout the successive editions of the OWASP Top 10, because they can lead to absolute control of the target machine. In fact, they have been at number one on the list during all editions until 2021, where it dropped to third position.

Types of injections

As it depends largely on the interpreter used, the language used or the storage system used in the backend of the server, there is also a significant number of different injections that can occur, such as:

Inyecciones SQL (SQLi - SQL injections) 

It allows unwanted manipulation of existing data in non-relational databases, modifying or altering data information, or allowing evasion of existing authentication and/or authorization systems. 

Contrary to what non-experts usually think, these types of injections are not a “90s thing.” Today, SQL (Structured Query Language) type injections are still used, used in queries or modifications of relational databases. A clear example has even been many times, as has been demonstrated in one of the vulnerabilities detected in the TSA (Transportation Security Administration) system, which has allowed the security of 77 airlines that used a certain system to be ignored. with one of the most trivial injections of this type. 

NoSQL injections (NoSQLi -NoSQL injections)

With the emergence of non-relational databases, such as MongoDB (where data is stored in BSON, a data format similar to JSON), CouchDB, or Redis, the type of injection changes to adjust to this type of information, but The result can be just as devastating. 

Command Injections (CI)

In this case, what is “injected” are unwanted commands into the underlying operating system. 

Inyecciones LDAP (LDAPi - Ligthweight Directory Access Protocol injections)

In this case, the exploitation of the injection is caused by the unwanted manipulation of LDAP or Lightweight Directory Access Protocol queries, to access or manipulate network resources or the authentication of users who use this type of protocol in the web application. 

Inyecciones XML (XMLi - XML injection, XXE - XML eXternal Entity injection)

In this case, the XML requests made to the server are manipulated to include uncontrolled entities, even external entities loaded from the attacking machine itself (in the case of XXE), to be able to read internal files or even perform remote command execution. 

XPath Injections

In this case, the manipulation of XPath queries (XML Path language) will be abused to access or modify data or attributes in XML documents. 

Using Cross Site Scripting (XSS - CrossSite Scripting)

In this type of injections, they are initially considered injections on the “client” side, as they mainly affect the relationship between web applications and what happens in the users' browser. 

But this fact, which could initially be considered not particularly relevant, is not so, if it is considered that a reflected XSS can lead to identity theft attacks or theft of user sessions or, in the case of stored , leading to the compromise of a complete infrastructure and not only the defacement or disfigurement of the web application. 

Furthermore, in combination with other types of attacks (the aforementioned SQLi, or others such as SSRF-Server-Side Request Forgery, CSRF or XSRF-Cross-Site Request Forgery...) they can be especially dangerous. 

They stand out for their use of JavaScript (or similar scripting languages ​​used on the client, such as vbscript, although less common today) and HTML (HTMLi or HTML Injection). 

Server-Side Template Injection (SSTI)

With the emergence of new frameworks on web servers such as PHP, Spring in Java, Flask/Django in Python, Express (Node.js), to traditional backends, certain popular template processing engines emerged on the web server, such as Jinja or Jinja2 (Python), Twig (PHP), Pug/Jade (Node.js), EJS (JavaScript), Freemarker (Java), etc. 

And with them, new types of injection abusing these existing templates, where, through proper manipulation and injection of specific commands, an attacker could interact with the entire server environment, including existing files or services, or even the system itself. operational. 

ORM Injection (Object-Relational Mapping Injection)

Although the use of an abstraction layer using Object Orientation is highly desirable to precisely avoid types of SQL or NoSQL injection, avoiding the direct construction and manipulation of SQL strings, a poor ORM implementation can lead to the discovery of database information. of underlying data, through the use of dynamic queries manipulating the logic of this type of objects, in an analogous way to what would be done with an SQLi. 

In this sense, several forms of injection have been discovered in popular ORMs such as SQLAlchemy (for Python) or Hibernate (for Java). 

Code Injections

The abuse of this type of injections depends exclusively on the type of language used for dynamic code execution in the web application. For example, PHP (with functions like eval()) or Python. 

Format String Injection

Here the injection would be given in the string format functions used for the manipulation of user input data, which would allow the disclosure of unwanted information on the server side, or the execution of even arbitrary code. 

Regular Expression Injections (Regex Injection)

The exploitation of this type of injections is generally given by the laxity in the implementation of certain regular expressions used in the system, allowing their manipulation to carry out attacks to obtain additional information, evasion of filters, or even Denial of Service (DoS) attacks. ).

HTTP Header Injection

The injection in this case is given in the HTTP header of the requests sent to the server, allowing other types of attacks such as cache poisoning (Cache Poisoning) or the manipulation of cookies used in the application session. 

In fact, it is common to use other types of injections mentioned within the headboards as well. 

Why do injections occur?

Most injections occur for a common reason, regardless of the language used in the backend, the infrastructure deployed or the server configuration, which will motivate the choice to use some types of injection or others. 

The main reason is the lack of controls for the validation of user input data, as well as the output (or cross-layer processing), of the information to the server.

It should not be forgotten that initial requests can be intercepted after passing filters on the client side, and manipulated to also affect the server, as long as controls and validations have not been established especially on this side.

Nor should these types of attacks be conceived as attacks that only affect web applications, many of these described injections being possible (especially SQLi) in non-web client-server architectures (even where the client and the server are on the same machine). .

Mitigation measures

The following are given as main recommendations:

• A zero trust policy must be established in everything regarding the inputs that an application can receive, establishing adequate sanitization, in such a way that unwanted characters are escaped (avoiding as far as possible the use of blacklists and replacing them with security functionalities regarding character escape depending on the technologies used). 

• Additionally, the use of parameterized queries is recommended in the case of access to database servers, following the security recommendations of each database provider, as well as the technology used. 

• Proper database abstractions must be made to avoid the direct construction of SQL queries through correct use of ORM (Object-Relational Mapping). 

• Regardless of the above, correct access control must be implemented, limiting permissions on the server, both for the running web service and access to the database, or to the specific directories where the application is being executed. application, in such a way that access to other areas of the server is severely limited. 

In this way, by establishing the “principle of least privilege”, the subsequent steps of a possible attacker will be restricted as much as possible, if they have been successful in exploiting any of these attacks. 

• Resort to additional layers of protection, such as executing a WAF (Web Application Firewall), with well-defined rules to stop this type of attacks, or blocking possible automation in injection attempts. 

Of course, without trusting solely and blindly in this type of systems, which can also be evaded.