CWE ID: 78
Name: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)
Das Produkt konstruiert entweder den gesamten oder Teile eines OS-Befehls unter Verwendung von extern beeinflusstem Input von einer vorgelagerten Komponente, neutralisiert jedoch nicht oder neutralisiert diesen fehlerhaft. Dies ermöglicht die Modifikation des beabsichtigten OS-Befehls, wenn er an eine nachgelagerte Komponente gesendet wird. Dies stellt ein potentielles vulnerability dar, das eine exploitation durch einen Angreifer ermöglichen könnte.
Effektivität: Unknown
Beschreibung: Soweit möglich, sollten library calls anstelle von externen Prozessen verwendet werden, um die gewünschte Funktionalität zu replizieren. Dies reduziert die Angriffsfläche und verbessert die performance.
Effektivität: Unknown
Beschreibung: Für alle Daten, die zur Generierung eines auszuführenden Befehls verwendet werden, sollte diese Daten so weit wie möglich außerhalb der externen Kontrolle gehalten werden. Beispielsweise kann dies bei Webanwendungen bedeuten, dass die Daten lokal im Zustand der session gespeichert werden, anstatt sie in einem versteckten form field an den Client zu senden. Dies minimiert das Risiko von injection attacks und erhöht die security posture.
Effektivität: Unknown
Beschreibung: Für alle Sicherheitsprüfungen, die clientseitig durchgeführt werden, muss sichergestellt werden, dass diese Prüfungen auch serverseitig dupliziert werden. Dies dient der Vermeidung von CWE-602. Angreifer können clientseitige Prüfungen umgehen, indem sie Werte nach der Durchführung der Prüfungen modifizieren oder den Client so verändern, dass die clientseitigen Prüfungen vollständig entfernt werden. Anschließend würden diese modifizierten Werte an den Server übermittelt. Eine robuste validation erfordert daher immer eine serverseitige verification.
Effektivität: Unknown
Beschreibung: Obwohl die Verwendung von dynamisch generierten Query Strings, Code oder Commands, die Kontrolle und Daten vermischen, riskant ist, kann dies manchmal unvermeidlich sein. Argumente müssen korrekt in Anführungszeichen gesetzt und alle speziellen Zeichen innerhalb dieser Argumente maskiert werden. Der konservativste Ansatz besteht darin, alle Zeichen zu maskieren oder herauszufiltern, die nicht durch eine äußerst strenge Zulassungsliste (Allowlist) bestehen (z. B. alles, was nicht alphanumerisch oder Leerzeichen ist). Wenn bestimmte Sonderzeichen dennoch benötigt werden, beispielsweise Leerzeichen, sollten Sie jedes Argument nach dem Maskieren/Filtern in Anführungszeichen setzen. Seien Sie vorsichtig vor Argument Injection (CWE-88). Eine sorgfältige sanitization ist hier essentiell, um vulnerabilities zu vermeiden.
Effektivität: Unknown
Beschreibung: Wenn das auszuführende Programm die Angabe von Argumenten innerhalb einer Eingabedatei oder von Standard Input erlaubt, sollten Sie diese Methode zur Übergabe von Argumenten anstelle der Kommandozeile in Betracht ziehen. Dies kann die Sicherheit erhöhen und das Risiko von Command Injection reduzieren.
Effektivität: Unknown
Beschreibung: Wenn der Satz akzeptabler Objekte, beispielsweise Dateinamen oder URLs, begrenzt oder bekannt ist, erstellen Sie eine Zuordnung von einem Satz fester Eingabewerte (z. B. numerische IDs) zu den tatsächlichen Dateinamen oder URLs und verwerfen Sie alle anderen Inputs. Dies dient der Implementierung einer White-Listing Strategie und minimiert das Risiko, auf unerwartete oder schädliche Ressourcen zuzugreifen.
Effektivität: Unknown
Beschreibung: Führen Sie den Code in einer Umgebung aus, die eine automatische Taint-Propagation durchführt und die Ausführung von Befehlen verhindert, die mit “tainted” Variablen arbeiten, beispielsweise durch die Verwendung von Perl’s “-T” Switch. Dies zwingt das Programm, Validierungsschritte durchzuführen, um die Taint zu entfernen. Achten Sie jedoch darauf, Ihre Inputs korrekt zu validieren, um zu vermeiden, dass gefährliche Inputs fälschlicherweise als “untainted” markiert werden (siehe CWE-183 und CWE-184).
Effektivität: Unknown
Beschreibung: Führen Sie den Code in einer Umgebung aus, die eine automatische Taint-Propagation durchführt und die Ausführung von Befehlen verhindert, die mit “tainted” Variablen arbeiten, beispielsweise durch die Verwendung von Perl’s “-T” Switch. Dies zwingt das Programm, Validierungsschritte durchzuführen, um die Taint zu entfernen. Achten Sie jedoch darauf, Ihre Inputs korrekt zu validieren, um zu vermeiden, dass gefährliche Inputs fälschlicherweise als “untainted” markiert werden (siehe CWE-183 und CWE-184).
Effektivität: Unknown
Beschreibung: Nutzen Sie Runtime Policy Enforcement, um eine Allowlist der zulässigen Befehle zu erstellen und die Verwendung von Befehlen zu verhindern, die nicht in dieser Allowlist enthalten sind. Technologien wie AppArmor stehen für diese Art von Implementierung zur Verfügung.
Effektivität: Moderate
Beschreibung: Setzen Sie eine Application Firewall ein, die Angriffe gegen diese Schwachstelle erkennen kann. Dies kann vorteilhaft sein, wenn der Code nicht behoben werden kann (weil er von einem Drittanbieter kontrolliert wird), als Sofortmaßnahme, während umfassendere Software Assurance Maßnahmen implementiert werden, oder um eine Defense in Depth zu gewährleisten.
Notizen: Eine Application Firewall deckt möglicherweise nicht alle möglichen Input-Vektoren ab. Darüber hinaus könnten Angriffs-Techniken verfügbar sein, um den Schutzmechanismus zu umgehen, beispielsweise durch die Verwendung von fehlerhaften Inputs, die dennoch von der Komponente verarbeitet werden können, die diese empfängt. Je nach Funktionalität kann eine Application Firewall unbeabsichtigt legitime Requests ablehnen oder modifizieren. Schließlich kann ein gewisser manueller Aufwand für die Customization erforderlich sein.
Effektivität: Unknown
Beschreibung: Führen Sie Ihren Code mit den minimal erforderlichen Privilegien aus, die zur Erfüllung der notwendigen Aufgaben benötigt werden [REF-76]. Erstellen Sie nach Möglichkeit isolierte Accounts mit eingeschränkten Privilegien, die ausschließlich für eine einzelne Aufgabe verwendet werden. So kann ein erfolgreicher Angriff dem Angreifer nicht sofort Zugriff auf den Rest der Software oder deren Environment gewähren. Beispielsweise benötigen Datenbank-Anwendungen selten die Berechtigungen des Datenbank-Administrators, insbesondere im Rahmen des täglichen Betriebs.
Effektivität: Unknown
Beschreibung: Bei der Verwendung von PHP konfigurieren Sie die Anwendung so, dass register_globals nicht verwendet wird. Entwickeln Sie die Anwendung während der Implementierung so, dass sie sich nicht auf diese Feature verlässt, und vermeiden Sie die Implementierung einer register_globals-Emulation, die anfällig für Schwachstellen wie CWE-95, CWE-621 und ähnlichen Problemen ist.
