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.
Since there are many different ways to inject harmful code into systems, I have put together a list with 10 particularly dangerous and frequent injection vulnerabilities.
Code Injections are a highly common type of web vulnerabilities, 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 detect those injections 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!
FuzzCon Europe 2021 is a developer conference that is all about fuzzing and automated security testing. We connect developers and security experts from industry and research.
Let's join forces to make software more reliable and secure!
Tickets are now available at www.fuzzcon.eu