Project Description

What is Code Injection

An unwritten rule when developing applications is to treat all data as untrusted data. Code injection is a method that a malicious actor uses to inject malicious code which takes advantage of a validation flaw in the software. Since the application cannot detect the malicious code from its own code, the attacker gains access to restricted information of the application. In this article, we will be discussing various types of injections, what permits a malicious actor to inject code into an application, and also how to mitigate this vulnerability.

Code Injection

Code Injection is a broad term given to vulnerabilities that permit clients to inject code that gets executed by the application. Code Injection ensues when an application transmits untrusted data to an interpreter, the injection can happen both on the server and the client-side. Code Injection is often mistaken for other vulnerabilities, for example, Command Injection. The difference between the two is that threat actors inject code in Code Injections rather than Operating System Commands in Command Injection; nonetheless, both are very harmful vulnerabilities.

Code Injection is restricted to the abilities of the injected language. For example, assuming PHP injection happens in an application, it will impact only the PHP functions used in the application.

The exploitation of the vulnerability begins with the malicious actor testing the file uploads and field forms. If the malicious actor can insert untrusted data in one of the uploads or input forms of the application, then Code Injection occurs; following the injection, the attacker then gains access to the application server-side interpreter, and from there via system calls, the malicious actor can dive even deeper into the application.

Consequences of Code Injection

If successfully exploited, Code Injection impacts the fundamentals of cybersecurity known as CIA:

  • Confidentiality

Includes the sensitiveness of the information that an application holds.

  • Integrity

Maintaining the trustworthiness of data

  • Availability

Information should always be accessible to authorized parties.

Injection attacks are number three on the OWASP Top 10 vulnerabilities; these attacks are highly dominant and impactful, especially in applications that were not built with best security practices.

Code Injection Attack Types

Client-Side Code Injection

Input validation is one of the most common mistakes done by developers when developing an application. Suppose the application in hand is only validating input in the browser. In that case, the malicious actor can use software such as Burp or ZAProxy to intercept and change the request after submitting the request in the browser. In this case, the application server will not receive the original request validated in the browser, but it will receive the modified request.

PHP Code Injection

The eval() function interprets a string as a PHP code. If the data passed to this function is not validated, malicious actors can exploit it to run arbitrary commands. The PHP documentation warns developers of the potential dangers of using the eval() function, and also it highly discourages its use.

PHP Code Injection can fully compromise the application’s data, functionality, and the hosting server.

Cross-Site Scripting (XSS)

Cross-Site Scripting XSS vulnerability occurs when web applications accept data from users and include it in web pages without validating them. Cross-Site Scripting (XSS) permits a malicious actor to insert malicious code into a website and possess the victim’s browser or account. The malicious code gets executed in the targets’ browser, meaning the security restraints get ignored.

There are three types of Cross-Site Scripting:

  • Reflected XSS ( Non-Persistent – Type I)
  • Stored XSS (Persistent – Type II)
  • DOM Based XSS ( Type – 0)

Each of the XSS mentioned above has its exploitation process and consequences. Input fields should constantly be tested for Cross-Site Scripting. The potential of a Cross-Site Scripting attack can result in hijacked accounts, stolen credentials, access to the client machine, Etc.

SQL Injection (SQLI)

SQL Injection (SQLi) is a web security vulnerability that allows a malicious actor to inject malicious SQL statements in the queries an application makes to its database. It permits an unauthorized entity to see the information they ought not to approach, as other clients’ information. A few sorts of SQL injection exists and are arranged in light of the techniques used to get to the information and the potential damage.

  • In-Band SQLi occurs when an unauthorized entity can use the same communication channel for querying the database and gathering information.
  • Inferential (Blind) SQLi occurs when no response is shown on the application itself, but deductions about the database construct can be made based on the server’s behavior.
  • Out-of-band SQLi occurs when an unauthorized entity cannot use the same channel to launch the attack and gather results.

When the data is not appropriately sanitized, meaning the developers did not escape unique characters or handle input accurately, detailed queries can be embedded in the input field, causing undesirable application behavior. In the case of SQL injections, adding Structured Queries in the input field might cause a database leak.

Why am I vulnerable to Code Injection?

Dangerous Functions

One of the main reasons applications are vulnerable to Code Injection is the usage of particular functions when dealing with user input. eval(), setTimeout(), setInterval(), innerHTML, system(), Etc. are all dangerous functions if not used properly. These functions make the job easier for the developers to develop an application; on the other hand, they also make it easier for a malicious actor to exploit the application. The eval() function, for example, evaluates expressions and returns the value, but if it especially operates on user input, it is likely to allow for Remote Command Execution(RCE).

Input Validation

User input is data processed by the application and can be manipulated by the users. Input data is not just file uploads or field forms but also query string parameters, cookies, and other data sources. Ignoring the validation and sanitization of the input data allows the malicious actor to deliver malicious code into the application language, which results in Code Injection.

Dynamic Code Execution

Possibly the most explicit prevention method is to reconsider the need to evaluate any dynamically generated server-side code. If there is a necessity to use dynamic code execution, the application should counteract any externally-provided values used to construct the code.

 

Mitigation

After learning about Code Injection and its potential damage, it is essential that we learn how to protect ourselves and prevent the potential damage by Code Injection; Below can be found some of the best practices against Code Injection:

  • Input Validation
  • Input Sanitization
  • Avoid Dangerous Functions
  • Lock Down the Interpreter
  • Static Code Scanner
  • Dynamic Code Scanner