During an injection attack, an attacker can provide malicious input to a web application (inject it) and change the operation of the application by forcing it to execute certain commands.
An injection attack can expose or damage data and lead to a denial of service or a full webserver compromise. Such attacks are possible due to vulnerabilities in the code of an application that allows for unvalidated user input.
Injection attacks are one of the most common and dangerous web attacks. Injection vulnerability is ranked #1 in the OWASP Top Ten Web Application Security Risks. Several injection attacks are also featured in the Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Weaknesses.
Our scans consistently see that websites are sometimes critically vulnerable to these types of attacks. Many injection attacks can harm your web apps and cause severe loss or damage to the data.
Here are the most common and severe types of injection attacks your application may be vulnerable to.
Types of injection attacks
While SQL and Cross-Site Scripting injection attacks are the most common types, there is a host of such attacks, all of which have different aims and means to achieving them.
The main types of injection attacks that your application may be vulnerable to are:
SQL Injection (SQLi)
SQL is a query language to communicate with a database. It can be used to perform actions to retrieve, delete and save data in the database.
An attacker will try to manipulate the SQL query used in the web application and gain direct access to your data during an SQL injection (SQLi) attack. This is typically done through a web form input field, comment fields, or other freely accessible to users.
Such malicious SQL statements will seek to exploit a vulnerability in the authentication and authorization procedures of the application. If they are successful, the SQL database will execute the commands that the attacker has injected.
Depending on the type of SQL injection, it can read, modify, add, or delete data from the database.
Cross-Site Scripting (XSS)
Whenever an application allows user input within the output it generates, it allows an attacker to send malicious code to a different end-user without validating or encoding it. Cross-Site Scripting (XSS) attacks take these opportunities to inject malicious scripts into trusted websites.
For example, a string of text may be added to the URL. If the application fails to validate it and allows it to pass, a user’s browser will execute the code leading to a breach.
An XSS attack can be used to steal cookie details, change user settings, hijack user sessions, and more. This can open the door to impersonation and defacement.
According to various research and studies, up to 50% of websites are vulnerable to DOM Based XSS vulnerabilities. (neuralegion.com)(neuralegion.com)
In this scenario, an attacker is acquainted with the application code and programming language. By exploiting a vulnerability, they may attempt to inject code into the application to be executed as a command by its web server. This differs from an operating system (OS) command injection (see below).
Code typically employs a code injection technique via multiple input fields, including text input, HTTP GET/POST/PUT/DELETE parameters, headers, cookies, etc.
Once inside the target application, the attacker may force the webserver to do what they want by gaining greater privileges.
A code injection may impact an application anywhere, from gaining access to data to fully compromising the system. Therefore, a vulnerability to a code injection is of great concern.
Sometimes web applications need to call a system command on the web server running them. In such instances, if user input is not validated and restricted, a command injection can occur.
Unlike code injections, command injections only require the attacker to know the operating system. Then, the attacker inserts a command into the system, using the user privileges. The inserted command then executes in the host system.
A command injection can compromise that application, its data, the entire system, connected servers, systems, and other infrastructure.
A CCS injection exploits a vulnerability found in the ChangeCipherSpec processing in some versions of OpenSSL.
During such an attack, invalid signals are sent by attackers in the handshake session between servers and clients. This allows them to seize encryption key materials, access the communication between server and client, and possibly perform identity theft.
These are the most common and serious injection attacks used on web applications. Unfortunately, protecting your applications can be a huge uphill task for companies or individuals with many web applications and limited developer time and resources.
Try our free trial and start your first scan in minutes to test your application for SQL Injections, Cross-Site Scripting (XSS), and other OWASP Top 10 Vulnerabilities.
Other Common Forms of Injection Attacks
SMTP/IMAP Command Injection
Apart from the above, there are several other types of injection attacks that are also used. Unfortunately, these are currently not covered by the Crashtest Security Suite.
Also known as an Email Header injection, this mail command injection targets mail servers. This is done by inserting additional headers into a message that contains commands to the SMTP server. Unfortunately, most mail servers don’t have a strong level of protection against attacks on IMAP and SMTP.
Host Header injection
When a server hosts many websites, the server eventually needs a host header. The host header’s value specifies which website or web application must respond to an HTTP request. Manipulating such a host header creates a form of attack that can lead to a password reset. In addition, host header injections can also lead to web cache poisoning.
Lightweight Directory Access Protocol (LDAP) is designed to search resources (devices, files, other users) in a network. It is beneficial for intranets, and when used as part of a single sign-on system, it can store usernames and passwords. An unvalidated LDAP statement is injected, directing a server to perform a certain command during such an attack.
“Carriage Return” and “Line Feed” (CRLF), or \r and \n, are elements that are used in HTTP headers to terminate a line. In addition, they are used to split text streams, such as HTTP headers, into separate parts. A CRLF injection occurs when an attacker manages to introduce a CRLF sequence into an application. Typically this is done by introducing it into an HTTP header called HTTP Response Splitting.
How to detect injection vulnerabilities in your web app?
An automated web vulnerability scanner is the easiest way to detect an injection vulnerability. Such a scanner, akin to an automated pentest tool, can easily detect attack vectors and help you take the necessary steps to protect your application.
Now that you know the most common web application vulnerabilities make sure you cover the basics and account for these common injection attacks in your development process. And if you are unsure how to perform a great vulnerability assessment, we have you covered.
Crashtest Security detects, assesses, and remediates most injection vulnerabilities. Run a full scan for free here and run a vulnerability assessment on risks like SQL injection and Cross-Site Scripting (XSS).
How to prevent injections attacks
To prevent injection attacks on your web application, you must securely code them. OWASP has defined several ways to prevent SQL injection attacks, but these apply to other types of database attacks. These and several other strategies include:
- Validating user inputs by creating an allow-list (whitelist) for valid statements and configuring inputs for user data by context
- Using prepared statements with parameterized queries that help distinguish between code and user input and do not mistake statements for commands
- Using stored procedures that are defined and stored in the database and called from the web application
- Limiting special characters to disallow string concatenation
- Escaping all user-supplied input (the last resort measure, according to OWASP)
- Reducing your application’s attack surface by removing any unnecessary functionalities that would otherwise need to be guarded
- Enforcing the least privilege and strict access by allowing only those privileges that are necessary for an account