0Pricing
Secure Coding & OWASP Top 10 for Backend · Lekcja

Command Injection i Code Injection

Naucz się identyfikować i ograniczać podatności związane z wstrzykiwaniem poleceń systemu operacyjnego oraz arbitralnym wykonywaniem kodu w systemach backendowych.

Command Injection i Code Injection to bezpłatna lekcja Secure Coding & OWASP Top 10 for Backend na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Secure Coding & OWASP Top 10 for Backend, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Secure Coding & OWASP Top 10 for Backend zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

What is Command & Code Injection?

Welcome! In this lesson, we'll explore Command and Code Injection, two critical backend vulnerabilities.

These attacks trick your application into executing unintended system commands or application-level code, leading to severe security breaches.

  • Command Injection: Executes OS commands.
  • Code Injection: Executes application programming language code.

OS Command Injection Basics

OS Command Injection occurs when an attacker can run arbitrary operating system commands on the server hosting your application.

This happens when an application passes unsanitized user-supplied input to a system shell, often through functions that execute external programs.

Attackers can then:

  • Read, write, or delete files.
  • Execute malicious scripts.
  • Gain full control over the server.

Vulnerable OS Command Example

Let's see a vulnerable Java example. Imagine userInput comes directly from a web form.

The attacker can use command separators (like ; or &) to append new commands to the original one.

import java.io.BufferedReader;
import java.io.InputStreamReader;

public class CommandInjectionDemo {
  public static void main(String[] args) {
    // Imagine 'userInput' comes from a web request parameter
    String userInput = "my_file.txt; echo HELLO_INJECTED_COMMAND"; // Malicious input example
    // For Windows: "my_file.txt & echo HELLO_INJECTED_COMMAND"
    
    // VULNERABLE: Direct concatenation of user input into a system command
    String command = "ls -l " + userInput; // Linux example command
    // For Windows: String command = "dir " + userInput;
    
    System.out.println("Executing: " + command);
    
    try {
      Process p = Runtime.getRuntime().exec(command);
      BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
      String line;
      while ((line = reader.readLine()) != null) {
        System.out.println(line);
      }
      p.waitFor(); // Wait for the command to finish
    } catch (Exception e) {
      System.err.println("Error executing command: " + e.getMessage());
    }
  }
}

How the Injection Works

In the previous example, the string ls -l my_file.txt; echo HELLO_INJECTED_COMMAND is passed to the shell.

The semicolon (;) is a command separator on Linux/Unix-like systems. This tells the shell to execute the first command, then the second.

Even if my_file.txt doesn't exist, the echo command will still run, demonstrating the injection.

Mitigation: Input Validation

The primary defense against OS Command Injection is strict input validation.

  • Whitelisting: This is the safest approach. Define exactly what characters, formats, or values are allowed for user input. Reject anything that doesn't match.
  • Avoid Blacklisting: Trying to block known malicious characters (like ;, &) is often bypassable due to different shell interpretations or encoding tricks.

Mitigation: Preferring Safe APIs

Instead of concatenating user input directly into a command string, use APIs that pass arguments as separate elements to the command.

In Java, ProcessBuilder is safer than Runtime.getRuntime().exec() when used correctly, as it doesn't invoke a shell by default to interpret arguments.

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.Arrays;

public class SafeCommandExec {
  public static void main(String[] args) {
    // Imagine 'userInput' comes from a web request parameter
    String userInput = "my_file.txt; echo HELLO_INJECTED_COMMAND"; // Malicious input attempt
    
    // SECURE: Pass arguments as separate strings to ProcessBuilder
    // The shell will NOT interpret '; echo HELLO_INJECTED_COMMAND' as a new command
    ProcessBuilder pb = new ProcessBuilder("ls", "-l", userInput);
    // For Windows: ProcessBuilder pb = new ProcessBuilder("cmd.exe", "/c", "dir", userInput);
    
    System.out.println("Executing: " + String.join(" ", pb.command()));
    
    try {
      Process p = pb.start(); // Start the process
      BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
      String line;
      while ((line = reader.readLine()) != null) {
        System.out.println(line);
      }
      p.waitFor();
    } catch (Exception e) {
      System.err.println("Error executing command: " + e.getMessage());
    }
  }
}

Understanding Code Injection

Code Injection is similar to Command Injection, but instead of OS commands, it executes arbitrary code in the application's programming language.

This can happen when an application:

  • Evaluates user-supplied input as executable code (e.g., using eval() in scripting languages, or Expression Languages in Java).
  • Deserializes untrusted data that can construct malicious objects.
  • Uses vulnerable templating engines.

Code Injection Scenarios

Unlike OS Command Injection which targets the operating system shell, Code Injection targets the application's runtime environment.

  • Dynamic Evaluation: If your application takes user input and uses it in a function like eval() (common in Python, PHP, JavaScript), an attacker can inject their own code.
  • Insecure Deserialization: When an application deserializes untrusted data without proper validation, an attacker can craft malicious serialized objects that execute code upon deserialization.

Java applications are particularly vulnerable to insecure deserialization.

Preventing Code Injection

Mitigating Code Injection requires careful design and strict data handling:

  • Avoid Dynamic Code Execution: Never use functions that evaluate user-supplied input as code.
  • Validate Deserialized Data: Only deserialize data from trusted sources. Implement strict type checks and object validation for any deserialized input.
  • Use Safe Template Engines: Ensure your template engines automatically escape user-provided data to prevent injection.
  • Least Privilege: Run your application with the minimum necessary permissions.

Test Your Knowledge

It's time for a quick check! Select the most effective practices to prevent injection vulnerabilities.

Recap: Injection Defenses

Great job! You've learned about Command and Code Injection.

  • Command Injection allows attackers to run OS commands.
  • Code Injection allows attackers to run application-level code.
  • Key defenses include strict input validation (whitelisting), using safe APIs (like ProcessBuilder with separate arguments), and avoiding dynamic code execution from untrusted sources.

Always treat user input as untrusted data!

Często zadawane pytania

Czy lekcja „Command Injection i Code Injection” jest bezpłatna?

Tak — pełny tekst „Command Injection i Code Injection” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Secure Coding & OWASP Top 10 for Backend, przejdź na CoddyKit PRO. Kurs Secure Coding & OWASP Top 10 for Backend zawiera 4 lekcji w sumie.

Co nauczysz się w „Command Injection i Code Injection”?

Naucz się identyfikować i ograniczać podatności związane z wstrzykiwaniem poleceń systemu operacyjnego oraz arbitralnym wykonywaniem kodu w systemach backendowych. Ćwiczysz Secure Coding & OWASP Top 10 for Backend z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Secure Coding & OWASP Top 10 for Backend?

Nie wymagamy żadnego doświadczenia. Secure Coding & OWASP Top 10 for Backend w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Command Injection i Code Injection”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Secure Coding & OWASP Top 10 for Backend?

Tak. Każda lekcja Secure Coding & OWASP Top 10 for Backend zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Zapobieganie SQL Injection
  2. Command Injection i Code Injection
  3. Cross-Site Scripting (XSS) w backendzie
  4. Zapobieganie wstrzyknięciom XML i LDAP
← Powrót do Secure Coding & OWASP Top 10 for Backend