Injection is an issue that arises quite often and in several forms, things like SQL databases for example might contain issues such as SQL injection and the same might go for things like LDAP, XML, OS commands,... . In other words, there is a range of different injection vulnerabilities that can occur and we will be discussing them in this article.
Often developers will rely on certain techniques to make their web applications less static. This can include things like CRUD actions in the database, Login actions via LDAP or OS commands. These are just a few examples of how a developer can make a web application less static and they all have the same possibilities for vulnerabilities in them which arise when user input is processed without sanitising it. This is when users with malicious intent can insert their own malicious input into these processes which can lead to extremely bad consequences such as SQL injection or even OS command injection leading to remote code execution.
SQL injection is a vulnerability type that arises when developers use things like SQL queries that get data to create their queries from the user's input. If the developer does not properly sanitise this input, they run the risk of the user injection code that will terminate the SQL query after which they can inject their own.
LDAP is a system that is often used in web applications to authenticate users but it comes with some deep pitfalls to which we need to build bridges or we could be allowing malicious actors to intercept our LDAP queries and modify them to inject their own LDAP statements. This problem is made worse by the fact that there is no one single great implementation of LDAP interfaces with easy and safe to use parameters.
At times we may need to generate XML input as a developer. This XML file can come in many different forms and does not have to be limited to pure XML files in an upload functionality. We can see this issue manifest in several different ways ranging from SOAP calls that contain user supplied input to XML files that will also use the user supplied input to generate the file. The attacker will attempt to input values that will disrupt the structure of the generated XML file and attempt to insert their own values.
OS commands can sometimes be directly executed from the code they are running. While this is a useful feature, it does have its downsides and especially if user supplied input is used to run the command. This may lead to bad actors ending the command string and inserting their own. The impact of this is usually quite severe as it will lead to remote code execution.
Web applications can make the choice to store their data in XML files and just like SQL is used to search databases, we can use XPATH to search these XML files. If user input is supplied to the XPATH query and not sanitised properly it could lead to malicious actors injecting their own XPATH query. The impact of this could be sensitive information exposure or more technical issues such as login bypasses when login data is stored in XML files.
CRLF refers to Carriage Return Line Feed, which are two ways of terminating a line. Depending on the application and how it is set up, this could have serious consequences if the attacker is able to insert their own line feeds and subsequently maybe even code for the application to run. This could happen in the form of log injection or HTTP response splitting.
Our application might allow users to send email from within the functionality. This email needs some input such as an email address and content. If some of that input ends up in the headers of the email and is not sanitised properly, an attacker might be able to inject their own SMTP headers. Usually, this issue will be exploited by spammers who want to send phishing emails or perform malicious actions such as attach viruses to emails.