Menu

Injections - The Many Faced Threat

July 29 2021 | 3 min

Many of the most dangerous vulnerabilities for web applications, listed by OWASP, are injection vulnerabilities. When exploited, an injection vulnerability essentially allows attackers to gain access to your web application by injecting maliciously constructed inputs into your code via text field, URL or XML document.

SQL Injections - The Many Faced Threat

Ten Types of Injections

Since there are many different ways to inject harmful code into systems, I have put together a list of 10 particularly dangerous and frequent injection vulnerabilities, that many have faced.

1. Code Injection

Code Injections are a highly common type of web vulnerability, in which the attacker injects code through the text input fields. This is possible if the application lacks input validation, which allows the attacker to inject harmful code to exploit the web application. However, the attacker needs to know which database, framework, or programming language was used to construct these inputs. The consequences of such an attack are often data theft and broken functionality.

2. SQL Injection

To communicate with databases, most web services use SQL as a data access language. Attackers do this by inserting an SQL query into a text input field. When this input is submitted to the database unchecked, the attacker can in the worst case execute arbitrary SQL statements. In the worst case, this allows attackers to make changes to the database and extract or destroy information.

3. Command Injection

During Command Injections, attackers mimic the command that the web application would normally send to the operating system. They simply inject their own operating system command. Attackers can insert command injections without knowing what language a web application is written in. Unfixed Command injection vulnerabilities can have devastating consequences, as they expose information about the operating system or even worse, give attackers control over the entire system.

4. Cross-Site Scripting (XSS)

Although it has a different name, Cross-Site Scripting is basically a type of injection vulnerability. The main target of this attack is other users of a web service. When exploiting an XSS vulnerability, attackers insert malicious JavaScript. When the web application communicates with other users, their browser executes this code, which can expose the victim’s browser data or redirect him/her to a different website.

5. XPath Injection

XPath is a language that is often used in web development to communicate with XML databases. During an XPath Injection, the attacker first injects a malformed input to gain insights about the XML data structure. Then they use this information to construct an XPath command that allows them to access the XML data. If XML is used for authentication, attackers can even use XPath Injections to gain admin rights. 

6. Mail Command Injection

When email servers are not properly secured, they become vulnerable to injection attacks. To exploit email servers and services that build IMAP and SMTP statements, attackers inject malicious code via email messages. This allows them to override server restrictions and send spam messages from the server.

7. CRLF Injection

Carriage Return and Line Feed, is an input that represents the end of a line or command in several web protocols (HTTP, MIME, NNTP). A CRLF Injection happens when this code sequence is inserted into a web service externally. When user input is not validated sufficiently, attackers can inject CRLF code snippets which allow them to extract data, modify cookies and conduct further injection attacks. 

8. Host Header Injection

The main target of a Host Header Injection is actually the virtual host of a web application. In web services that consist of many different websites, the value indicated in the host headers determines which virtual host should process an input.

Often, invalid requests are by default forwarded to the first virtual host available. Thus, attackers can exploit this vulnerability to inject code, through the host header, straight to a virtual host. This attack could grant attackers access to sensitive data such as password information.

9. LDAP Injection

LDAP Injections are another attack that can be prevented by validating user input. The LDAP protocol is often used in intranets to help with resource management and store data from single sign-on systems. In an LDAP Injection, external attackers make changes to an LDAP query through an input field. Even tiny changes in the LDAP, can potentially lead to a massive data breach.

10. XXE-Injection

During an XXE Injection, attackers aim to inject code into legacy functionality in XML parsers, which are often not too well secured. Attackers can then design XML documents to execute various commands, such as e.g. remote code executions. XEE-Injections are highly severe, as they are listed number four in the OWASP Top Ten Vulnerability Ranking.

Learn More

LinkedIn_Info_petrol

How to Prevent Injection Vulnerabilities?

Once attackers have found a way into your system, the only thing you can do is to cut your losses. To make sure that this doesn’t happen to you, it is crucial that you properly test your code for security vulnerabilities and eliminate them before an attacker finds them.

One of the best ways to prevent the threat is to apply sophisticated dev tools for dynamic application security testing (DAST) and automated fuzz testing in an early stage of the development process. I know, this sounds complicated, but it's not! 

Code Intelligence for example offers a platform for automated security testing (CI Fuzz), that allows you to find runtime errors and edge cases with dynamic inputs. By using specialized injection sanitizers, you can even instrument your application to search for specific bug classes, such as Cross-Site-Scripting (XXS) or SQL injections.

However, even the best security tools are only useful if they can be easily integrated into your development environment. Because, when it comes to security solutions, usability tops everything! Therefore, you should properly evaluate whether Code Intelligence supports your development environment before you make any major decisions!

Click Here to Evaluate the CI Fuzz Testing Platform

 

Recent Posts

One Year of Fuzzing and Fixing Suricata

Autofuzz: Fuzzing Without Writing Fuzz Targets or Harnesses

Fuzzing 101 – The Basics (FAQ)

19 Bugs in Jsoup Found With Jazzer

Share Article

Subscribe to updates