Code Injection

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search

As the number of web applications grows, so does the threat landscape associated with them. Cybersecurity risks, especially those stemming from code injection vulnerabilities, have emerged as some of the most critical challenges for developers. These threats target the core integrity, availability, and confidentiality of data within applications, posing serious risks to individuals, businesses, and governments alike. This article delves into the concept of code injection, explores its various forms for countermeasures.

What is Code Injection?

The increasing prevalence of web applications and the sensitive user data stored in them increases the threat of attacks such as code injection. This type of attack, which ranked 1st in 2017 and 3rd in 2021 in the OWASP Top 10 Security Risks, has a significant security impact. Attacks occur through vulnerabilities where insufficiently validated user input can manipulate the code of an application. Attackers can bypass security mechanisms, access confidential data or compromise system integrity. Code injection comprises various attack techniques, including SQL injection, cross-site scripting (XSS) and remote code execution (RCE). These use insufficiently checked user input to execute malicious code in an application. The consequences range from data loss to the impairment of system availability and can cause considerable legal and financial damage. A typical example is the manipulation of PHP functions that process insecure input via GET parameters, allowing attackers to inject foreign code. Protective measures such as robust input validation are crucial to counteract such attacks and ensure system integrity.

Types

Cross-site scripting (XSS)

Cross-site Scripting is one of the most prevalent forms of code injection, targeting the interaction between users and web applications. In an XSS attack, malicious scripts (typically JavaScript) are injected into trusted websites. These scripts execute in the victim’s browser, allowing attackers to steal session tokens, cookies, or sensitive information.

  • Reflected XSS: Malicious input is included in a request and reflected back to the user. It often exploits dynamic webpage generation and is commonly delivered via URLs in phishing emails.
  • Stored XSS: The malicious payload is stored on the target server (e.g., in databases or logs) and served to multiple users, increasing its impact.
  • DOM-based XSS: The payload manipulates the browser’s Document Object Model (DOM) to inject and execute scripts, bypassing server-side defenses.

Countermeasure: Employ robust output encoding and avoid unsafe DOM methods like innerHTML.

For more detailed information: https://wiki.elvis.science/index.php?title=Cross-Site_Scripting_(XSS)

SQL Injection

SQL injection targets an application’s database layer. By inserting malicious SQL statements into input fields, attackers can manipulate database queries, retrieve sensitive data, or even gain administrative control.

Common Techniques:

  • Tautology-based Attacks: Manipulating WHERE clauses to always return true.
  • Union-based Attacks: Combining legitimate queries with malicious payloads using the UNION operator.
  • Error-based Attacks: Exploiting error messages to glean insights about database schema.
  • Blind SQL Injection: Using trial-and-error techniques, such as timing responses, to extract information without visible error messages.

Example for SQL injection:

Attack code

   name'; DELETE FROM items;--

This input leads to two SQL queries

   SELECT * FROM items WHERE owner = 'wiley' AND itemname =  'name';
   DELETE FROM items;

The '--' at the end of the statement is interpreted as a comment marker by most database servers. This query was used to return all data records from the “items” table that have that have “owner” equal to “wiley” are returned. Then all records in the “items” table are deleted and in most cases the number of deleted data records are returned. Many database servers allow the execution of several of several SQL statements that are separated by a simicolon. One example is the Microsoft SQL Server. This function is exploited by attackers to execute arbitrary SQL. Oracle can be cited as a positive example, which a restriction on batch executions, as a result of which such an SQL statement would not be successful.

Countermeasures:

  • Use prepared statements with parameterized queries.
  • Implement strict input validation and sanitization.
  • Minimize database user privileges.
  • Regularly test applications with SQL injection tools.

For more detailed information: https://wiki.elvis.science/index.php?title=SQL_Injection

Remote Code Execution (RCE)

Remote Code Execution (RCE) is a particularly dangerous form of code injection in which an attacker is able to execute arbitrary code on the server. RCE attacks differ from other injections in that they not only affect the client, but also manipulate the server side. RCE attackers exploit vulnerabilities in the processing of user input to cause the server to execute malicious code that allows the attacker to control the system. An example of an RCE attack is an attack on the OpenVPN service in 2024, where attackers were able to inject a malicious plugin into the OpenVPN service to execute privileged commands. The attack could only be carried out with existing access to the system, as administrator rights were required. To prevent such attacks, all user input should be strictly validated and input checks performed to prevent the introduction of malicious software.

Countermeasure: Regularly update software and isolate critical server components.

Server Side Include (SSI)

Server Side Include (SSI) Injection is another form of code injection in which attackers attempt to inject malicious server commands via SSI mechanisms. SSI instructions allow the web server to execute certain scripts or functions before the website is delivered to the user. If this function is not properly secured, an attacker can gain control of the server by injecting malicious SSI instructions into input fields. A successful SSI attack can result in the attacker being able to access sensitive data or even control the entire server environment. These attacks can be detected by using file extensions such as .stm, .shtm or .shtml, which indicate SSI, and by testing SSI commands in the page source code. Examples for SSI:

Commmands Server Side Include

Countermeasure: Disable SSI processing if unnecessary. For essential use cases, apply strict input validation and limit directive permissions.

References