In the early days of the Internet, one of the most common attack methods was Brute Force . This attack was usually performed by bots. But there are times when people have a thousand combinations of usernames and passwords to find a match, to access the victim’s account.

Brute force attacks are no longer a threat thanks to password policy, limited login attempts and captchas. But cybercriminals love to discover new methods and use them to carry out new types of attacks.

A long time ago, they discovered that text boxes in apps or web pages can be used by injecting unexpected text into them that will force the app to do things it shouldn’t. Thus, the so-called injection attacks entered the scene.

If your server is running Linux, you wonder if Linux is really immune to viruses and malware?

Injection attacks can be used not only to log into an application without knowing the username and password, but also to reveal private or confidential information or even hijack the entire server. This is why these attacks pose a threat not only to web applications, but also to users whose data resides in those applications, and in the worst case, other connected applications and services.

1. Code injection

Text field injection is one of the most common types of attacks. If attackers know the programming language, structure, database, or operating system used by the web application, they can enter the code through text input fields to force the web server to do what it wants.

These types of injection attacks are possible for applications that lack input validation. To prevent these attacks, the application must limit as much as it can allow incoming users.

For example, you need to limit the amount of data expected, check the format of the data before accepting it, and limit the set of characters allowed.

Code injection vulnerabilities are easy to find simply by testing the text input of a web application with different types of content. But when an attacker succeeds in exploiting one of these vulnerabilities, it could result in loss of confidentiality, integrity, availability, or functionality of the application.

2. SQL injection

Similar to code injection,  this attack injects SQL script – the language most databases use to perform query operations – into a text input field. The script is sent to the application, which executes it directly in its database.

As a result, an attacker can go through the login screen or perform more dangerous actions, such as reading sensitive data directly from the database, modifying or destroying data, or performing administrative operations on the database.

3. Team injection

These attacks are also possible, mainly due to insufficient input validation. They differ from code injection attacks in that an attacker inserts system commands instead of code fragments or scripts. Therefore, the hacker does not need to know the programming language on which the application is based or the language used by the database. But they need to know the operating system used by the host server.

Inserted system commands are executed by the host operating system with application privileges, which can allow to expose the contents of arbitrary files residing on the server, show the server directory structure, among other things, change user passwords and much more.

These attacks can be prevented by the system administrator by limiting the level of access to the system of web applications running on the server.

4.XSS (cross-site scripting)

Whenever an application accepts input from a user that it generates without validating or encoding it, it gives the attacker the ability to send malicious code to another end user.

Cross-site scripting (XSS) attacks take advantage of these capabilities to inject malicious scripts into trusted websites, which are ultimately sent to other users of the application who are targeted by the attacker.

The victim’s browser will execute the malicious script, not knowing that it cannot be trusted. Therefore, the browser allows it to access session tokens, cookies, or confidential information stored in the browser. Scripts can even overwrite the contents of the HTML file if properly programmed.

5. XPath injection

This type of attack is possible when a web application uses user-supplied information to create an XPath query for XML data. This attack works in a similar way to SQL injection: attackers send malformed information to the application to find out how the XML data is structured, and then attack again to gain access to that data.

XPath is a standard language with which, like SQL, you can specify the attributes you want to search for. To query XML data, web applications use user input to set the template that the data must match. By sending incorrect input, the template can turn into an operation that an attacker wants to apply to the data.

Unlike what happens with SQL, there are no different versions in XPath. This means that XPath injection can be done in any web application that uses XML data, regardless of implementation. This also means that the attack can be automated; hence, unlike SQL injection, it can be applied to any number of targets.

6. Mail command injections

This attack can be used to exploit mail servers and applications that generate IMAP or SMTP statements with incorrectly verified user input.

Sometimes, IMAP and SMTP servers are not as robust against attacks as they would be with most web servers, and therefore could be more vulnerable. By logging in through a mail server, attackers can bypass restrictions such as captchas, a limited number of requests, etc.

To use an SMTP server, attackers need a valid email account to send messages with the commands entered. If the server is vulnerable, it will respond to requests from attackers, allowing them, for example, to override server restrictions and use their services to send spam.

IMAP implementation can be done primarily in webmail applications using the Read Messages feature. In these cases, the attack can be performed simply by typing the URL with the commands entered into the address bar of the web browser.

7. CRLF injection

Inserting carriage returns and line feeds — a combination known as CRLF — into input fields on a web form is an attack called CRLF injection. These invisible characters indicate the end of a line or the end of a command in many traditional Internet protocols such as HTTP, MIME, or NNTP.

For example, inserting CRLF into an HTTP request followed by specific HTML can send custom web pages to website visitors.

This attack can be performed against vulnerable web applications that do not apply proper filtering to user input. This vulnerability opens doors to other types of injection attacks, such as XSS and code injection, and can also occur on a compromised website.

8. Node header injection

On servers that host many websites or web applications, the host header becomes necessary to determine which website or web application should be requested, each known as a virtual host, to handle the incoming request.

The header value tells the server which virtual host to send the request to. When a server receives an invalid host header, it usually passes it to the first virtual host in the list. This is a vulnerability that attackers can use to send arbitrary host headers to the first virtual host on a server.

Host header manipulation is usually associated with PHP applications, although it can also be done with other web development technologies. Its consequences can include the execution of sensitive operations by attackers, such as password reset, etc.

9. LDAP injection

LDAP is a protocol designed to make it easier to find resources (devices, files, other users) on the network. This is very useful for intranets , and when used as part of SSO, it can be used to store usernames and passwords.

LDAP queries involve the use of special control characters that affect its control. Attackers can potentially change the intended behavior of an LDAP query if they can insert control characters into it.

Again, the main problem that allows LDAP attacks is incorrectly validated user input. If the text sent by the user to the application is used as part of an LDAP query without clearing it, the query may end up getting a list of all users and displaying it to the attacker by simply using the asterisk (*) on the right to place it inside the input string.

Preventing injection attacks

As we saw in this article, all injection attacks target servers and applications that are open to anyone on the Internet. Responsibility for preventing these attacks is shared between application developers and server administrators.

Application developers should be aware of the risks associated with incorrect validation of user input and learn best practices for cleaning up user input in order to prevent risks.

Server administrators should periodically check their systems to find vulnerabilities and fix them as soon as possible. There are many options for performing these audits, either on demand or automatically.