The problem with web applications is that they are openly exposed to billions of internet users, many of which will want to break its security measures –for whatever the reasons.
In the early days of the Internet, one of the most common attack methods was basic, simple brute force. Bots usually performed these attacks –or persons with plenty of time off– who tried zillions of combinations of usernames and passwords until they found one that would grant access to the target application.
Brute force attacks are no longer a threat, thanks to password policies, limited login attempts, and captchas. But cybercriminals love to discover new exploits and to use them to perform new types of attacks. Long ago, they discovered that text fields on applications or web pages could be exploited by entering –or injecting– unexpected text into them that would force the application to do something it was not supposed to do. In that way, the so-called injection attacks entered the scene.
Injection attacks can be used not only to log in to an application without knowing username and password, but also to expose private, confidential, or sensitive information, or even to hijack an entire server. That is why these attacks are not only a threat to web applications, but also to the users whose data resides on those applications, and in the worst cases, to other connected applications and services.
Code injection
Code injection is one of the most common types of injection attacks. If attackers know the programming language, the framework, the database or the operating system used by a web application, they can inject code via text input fields to force the webserver to do what they want.
These types of injection attacks are possible on applications that lack input data validation. If a text input field lets users enter whatever they want, then the application is potentially exploitable. To prevent these attacks, the application needs to restrict as much as it can the input users are allowed to enter.
For example, it needs to limit the amount of expected data, to check the data format before accepting it, and to restrict the set of allowed characters.
The code injection vulnerabilities can be easy to find, just by testing the text input of a web application with different types of content. When found, the vulnerabilities are moderately hard to exploit. But when an attacker manages to exploit one of these vulnerabilities, the impact could include loss of confidentiality, integrity, availability, or application functionality.
SQL injection
In a similar fashion to code injection, this attack inserts an SQL script –the language used by most databases to perform query operations– in a text input field. The script is sent to the application, which executes it directly on its database. As a result, the attacker could pass through a login screen or do more dangerous things, like read sensitive data directly from the database, modify or destroy database data, or execute admin operations on the database.
PHP and ASP applications are prone to SQL injection attacks due to its older functional interfaces. J2EE and ASP.Net apps are usually more protected against these attacks. When an SQL injection vulnerability is found –and they could be easily found–the magnitude of the potential attacks will only be limited by the attacker’s skill and imagination. Thus, the impact of an SQL injection attack is undoubtedly high.
Command injection
These attacks are also possible, mainly due to insufficient input validation. They differ from code injection attacks in that the attacker inserts system commands instead of pieces of programming code or scripts. Therefore, hacker doesn’t need to know the programming language in which the application is based or the language used by the database. But they need to know the operating system used by the hosting server.
The inserted system commands are executed by the host operating system with the privileges of the application, which could allow for exposing the content of arbitrary files residing on the server, for showing the directory structure of a server, for changing user passwords, among other things.
These attacks can be prevented by a sysadmin, by limiting the system access level of the web applications running on a server.
Cross-site scripting
Whenever an application inserts input from a user within the output it generates, without validating or encoding it, it gives the opportunity to an attacker to send malicious code to a different end-user. Cross-Site Scripting (XSS) attacks take these opportunities to inject malicious scripts into trusted websites, which is ultimately sent to other users of the application, which become the attacker’s victims.
The victims’ browser will execute the malicious script without knowing it should not be trusted. Therefore, the browser will let it access session tokens, cookies, or sensitive information stored by the browser. If properly programmed, the scripts could even rewrite the contents of an HTML file.
XSS attacks can be generally divided into two different categories: stored and reflected.
In stored XSS attacks, the malicious script resides permanently on the target server, in a message forum, in a database, in a visitor log, etc. The victim gets it when its browser requests the stored information. In reflected XSS attacks, the malicious script is reflected in a response that includes the input sent to the server. This could be an error message or a search result, for example.
XPath injection
This type of attack is possible when a web application uses information provided by a user to build an XPath query for XML data. The way these attack works is similar to SQL injection: attackers send malformed information to the application in order to find out how the XML data is structured, and then they attack again to access that data.
XPath is a standard language with which, like SQL, you can specify the attributes you want to find. To perform a query on XML data, web applications use user input to set a pattern the data should match. By sending malformed input, the pattern can turn into an operation that the attacker wants to apply to the data.
Unlike what happens with SQL, in XPath, there are no different versions. This means that XPath injection can be done on any web application that uses XML data, regardless of the implementation. That also means that the attack can be automated; therefore, unlike SQL injection, it has the potential to be fired against an arbitrary number of objectives.
Mail command injection
This attack method can be used to exploit email servers and applications that build IMAP or SMTP statements with improperly validated user input. Occasionally, IMAP and SMTP servers don’t have strong protection against attacks, as it would be the case with most web servers, and therefore could be more exploitable. Entering through a mail server, attackers could evade restrictions such as captchas, a limited number of requests, etc.
To exploit an SMTP server, attackers need a valid email account to send messages with injected commands. If the server is vulnerable, it will respond to the attackers’ requests, allowing them, for example, to override server restrictions and use its services to send spam.
IMAP injection could be done mainly on webmail applications, exploiting the message reading functionality. In these cases, the attack can be performed by simply entering, in the address bar of a web browser, a URL with the injected commands.
CRLF injection
The insertion of carriage return and line feed characters –combination known as CRLF– in web form input fields represents an attack method 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, the insertion of a CRLF into an HTTP request, followed by some certain HTML code, could send custom web pages to the visitors of a website.
This attack can be performed on vulnerable web applications that don’t apply the proper filtering to the user input. This vulnerability opens the door to other types of injection attacks, such as XSS and code injection, and could also derive in a website being hijacked.
Host Header injection
In servers that host many websites or web applications, the host header becomes necessary to determine which of the resident websites or web applications –each of them known as a virtual host– should process an incoming request. The value of the header tells the server to which of the virtual hosts to dispatch a request. When the server receives an invalid host header, it usually passes it to the first virtual host in the list. This constitutes a vulnerability that attackers can use to send arbitrary host headers to the first virtual host in a server.
Manipulation of the host header is commonly related to PHP applications, although it can also be done with other web development technologies. Host header attacks work as enablers for other types of attacks, such as web-cache poisoning. Its consequences could include the execution of sensitive operations by the attackers, for example, password resets.
LDAP injection
LDAP is a protocol designed to facilitate the search of resources (devices, files, other users) in a network. It is very useful for intranets, and when used as part of a single sign-on system, 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 in it.
Again, the root problem that allows for LDAP injection attacks is improperly validated user input. If the text a user sends to an application is used as part of an LDAP query without sanitizing it, the query could end up retrieving a list of all users and showing it to an attacker, just by using an asterisk (*) in the right place inside an input string.
Preventing injection attacks
As we saw in this article, all injection attacks are directed towards servers and applications with open access to any internet user. The responsibility to prevent these attacks is distributed among application developers and server administrators.
Application developers need to know the risks involved in the incorrect validation of user input and learn best practices to sanitize user input with risk prevention purposes. Server administrators need to audit their systems periodically to detect vulnerabilities and correct them as soon as possible. There are many options to perform these audits, either on-demand or automatically.
