Injections are amongst the oldest and most dangerous attacks aimed at web applications and can lead to data theft, data loss, loss of data integrity, denial of service, as well as full system compromise. The primary reason for injection vulnerabilities is usually insufficient user input validation.
An injection attack is a malicious code injected in the network which fetched all the information from the database to the attacker. This attack type is considered a major problem in web security and is listed as the number one web application security risk in the OWASP Top 10. SQL Injection flaws are introduced when software developers create dynamic database queries that include user-supplied input.
To avoid SQL injection flaws is simple. Developers need to either: a) stop writing dynamic queries; and/or b) prevent user-supplied input which contains malicious SQL from affecting the logic of the executed query.
Classification of Injection attacks
Injection attacks are classified into various categories as below:
- SQL Injection:
This type of injection refers to an attack where the attacker executes a malicious Payload (malicious SQL statements) that control a web application database server. This is one of the oldest vulnerabilities as all the websites or web applications use SQL-based databases. By leveraging SQL Injection vulnerability, given the right circumstances, an attacker can use it to bypass a web application’s authentication and authorization mechanisms and retrieve the contents of an entire database.
SQL Injection can also be used to add, modify and delete records in a database, affecting data integrity. Impacts of SQL Injections are Authentication Bypass, Information Disclosure, Data Loss, Data theft, and Data Integrity loss, Denial of service and at times System Compromise.
- Cross-site scripting (XSS):
In a Cross-site scripting attack, malicious scripts are injected into a web page, and are executed when that page is visited by a user. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
- XPath injection:
Similar to SQL injection attacks, XPath Injections attack web sites that operate on user-supplied information to construct an XPath query for XML data. An attacker can enquire detailed information on how the XML data is structured, or access data that is not normally accessible by sending malformed information to the website. Apart from this, these vulnerabilities can also elevate the attacker’s privileges on the web site if the XML data is being used for authentication (such as an XML based user file).
- Template injection:
In a Template Injection, the attacker submits malicious code that is executed when the application takes user-supplied input and transforms it into a file according to a template, such as generating a custom welcome page for a new user.
- Code Injection:
As the Name signifies, this attack introduces a malicious code into the application, which is capable of compromising database integrity and/or compromising privacy properties, security and even data correctness. It can also steal data and/or bypass access and authentication control. A code injection to any application can lead to a full system compromise, causing a Plague to the system.
- CRLF Injection:
The term CRLF signifies, carriage return Line feed, usually denoting termination of a Line. A CRLF Injection attack occurs when a user manages to submit a CRLF into an application which is most commonly done by modifying an HTTP parameter or URL. CRLF injection is a software application coding vulnerability that occurs when an attacker injects a CRLF character sequence where it is not expected. When CRLF injection is used to split an HTTP response header, it is referred to as HTTP Response Splitting. CRLF injection vulnerabilities result from data input that is not neutralized, incorrectly neutralized or otherwise un-sanitized.
- Email header injection:
Most of the time a contact form sends SMTP headers such as From and Reply-to to make it easy for the recipient to treat communication from the contact form just like they would any other email rather than sending email to an intended recipient of the message by a legitimate user. Unless the user’s input is validated before being inserted into SMTP headers, the contact form might be vulnerable to Email Header Injection (also referred to as SMTP header injection). This is because an attacker may be able to inject additional headers into the message, thereby instructing the SMTP server to carry out different instructions than intended. Such attacks usually lead to Information disclosure and Spam Relay.
- Host Header Injection:
The host header specifies which website or web application should process an incoming HTTP request and the web server uses the value of this header to dispatch the request to the specified website or web application. As a common practice of hosting several websites and web applications on the same IP address, most web servers are configured to pass the unrecognized host header to the first virtual host in the list. Therefore, it’s possible to send requests with arbitrary host headers to the first virtual host. Another way to pass arbitrary Host headers is to use the X-Forwarded-Host header. In some configurations this header will rewrite the value of the Host header
- LDAP Injection:
Lightweight Directory Access Protocol (LDAP) is an open-standard protocol for both querying and manipulating X.500 directory services. An attacker alters the construction of an LDAP statement, when a web application fails to properly sanitize user-supplied input. When an attacker is able to modify an LDAP statement, the process will run with the same permissions as the component that executed the command. (E.g. Database server, Web application server, Web server, etc.). This can cause serious security problems where the permissions grant the rights to query, modify or remove anything inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can also be similarly applied in LDAP Injection. These injections target authentication bypass, privilege escalation and authentication bypass.
- OS command injection:
OS command injection (also known as shell injection) is a web security vulnerability that allows an attacker to execute arbitrary operating system (OS) commands on the server that is running an application, and typically fully compromise the application and all its data. Very often, an attacker can leverage an OS command injection vulnerability to compromise other parts of the hosting infrastructure, exploiting trust relationships to pivot the attack to other systems within the organization
Vulnerabilities attacked by Injection attacks
The best way to determine if your applications are vulnerable to injection attacks is to search the source code for all calls to external resources (e.g., system, exec, fork, Runtime.exec, SQL queries, or whatever the syntax is for making requests to interpreters in your environment). Note that many languages have multiple ways to run external commands. Developers should review their code and search for all places where input from an HTTP request could possibly make its way into any of these calls.
In an SQL injection attack, an attacker includes some SQL in a piece of data that the application expects to receive, like a user’s profile text or email address. Then, because of vulnerability in the application code, the application runs the SQL on the database.
For example, in an application submission of New User for a website:
- The attacker navigates to the new user page of the target application.
- In the Email field, they enter text containing SQL that instructs the database to list all the user email addresses in its records.
- When the form is completed and submitted, the application tries to process the data in the Email field in the normal fashion. However, because of the structure of the data, it is manipulated and runs the statement as a command.
- The email addresses of all the users are then displayed in a list in the attacker’s browser.
Injection attacks do not necessarily attack SQL databases only, and nor does the method of injecting the malevolent content have to include a ‘web form’ as an injection platform. Any instance where an application allows users to enter or upload data might contain a loophole that can invite an injection attack.
Defenses against Injection attacks
OWASP has defined a primary and additional defense mechanism against Injection attacks. These techniques can be used with not just SQL programming but other database programming as well. Below are the Defense mechanism techniques to be followed while safeguarding your web applications from any injection attacks:
Primary Defenses:
- Use of Prepared Statements (with Parameterized Queries)
- Use of Stored Procedures
- White list Input Validation
- Escaping All User Supplied Input
Additional Defenses:
- Enforcing Least Privilege
- Performing White list Input Validation as a Secondary Defense
Using other security techniques like access control, data monitoring can also help in scrutinizing these attacks and secure the database.
