Germany/Projekte/Top 10-2017 A1-Injection

==BAUSTELLE! Hier entsteht das deutsche Wiki der OWASP Top 10-2017==

==Bitte benutzen Sie die PDF Version.==

Bedrohungsquellen / Angriffsvektoren		Schwachstellen		Auswirkungen
Anw.- spezifisch	Ausnutzbarkeit: 3	Verbreitung: 2	Auffindbarkeit: 3	technisch: 3	Business ?
Beinahe jede Datenquelle kann einen Vektor für Injection darstellen: Umge-bungsvariablen, Parameter, externe und interne Webservices können von jedem Nutzer, unabhängig von seiner jeweiligen Rolle, ausgenutzt werden. Injection flaws Injection-Schwachstellen treten dann auf, wenn ein Angreifer bösartige Daten an einen Interpreter zur Verarbeitung schicken kann.		Injection Schwachstellen sind weit verbreitet, insbe-sondere in altem, ungewarteten Legacy-Code. Oft findet man sie in SQL-, NoSQL-, ORM-, LDAP- oder Xpath-Querys, ebenso bei Betriebssystem-Kommandos („OS Command Injection“), in XML- Parsern, SMTP-Headern und Expression Languages. Injection-Schwachstellen sind durch das Prüfen des Quellcodes leicht zu finden. Schwachstellen-Scanner und Fuzzer können Angreifer beim Auffinden von Injection-Schwachstellen unterstützen.		Injection kann zu Datenverlust, -verfälschung, oder Offenlegung gegenüber unauthorisierten Dritten, Verlust der Zurechenbarkeit oder Zugangssperre führen. Unter Umständen kann es zu einer vollständigen Systemübernahme kommen. Die Auswirkungen auf das Unternehmen hängen vom Schutzbedarf der Anwendung und ihrer Daten ab.

Ist die Anwendung verwundbar?

Eine Anwendung ist für diesen Angriff verwundbar, wenn:

Daten, die vom Nutzer stammen, nicht ausreichend validiert, gefiltert oder durch geeignete Sanitizer-Funktionen laufen.
Dynamische Anfragen oder nicht-parametrisierte Aufrufe ohne ein dem Kontext (SQL, LDAP, XML usw.) entsprechendes Escaping direkt einem Interpreter übergeben werden.
Bösartige Daten innerhalb von ORM („Objekt Relationales Mapping“)-Suchparametern genutzt werden können, um vertrauliche Datensätze eines Dritten zu extrahieren.
Bösartige Daten direkt oder als Teil zusammengesetzter dynamischer SQL-Querys, Befehle oder Stored Procedures genutzt werden können.

Injection ist u.a. bei der Verwendung von SQL, NoSQL, ORM-Frameworks, Betriebssystem-Kommandos, LDAP, Expression Language (EL) , Object Graph Navigation Language (OGNL) oder XML zu finden. Das Grundkonzept eines Injection-Angriffs ist für alle Interpreter gleich. Ein Quellcode Review ist eine sehr gute Methode, um Injection-Schwachstellen zu finden, dicht gefolgt vom gründlichen (ggf. automatisierten) Testen aller Parameter und Variablen wie z.B. Eingabe-Felder und Header-, URL-, Cookies-, JSON-, SOAP- und XML-Eingaben. Statische (SAST, Quellcode-Ebene) und dynamische (DAST, laufende Anwendung) Test-Werkzeuge können von Organisationen für ihre CI/CD-Pipeline genutzt werden, um neue Schwachstellen noch vor einer möglichen Produktivnahme aufzuspüren.

Wie kann ich das verhindern?

Um Injection zu verhindern, müssen Eingabedaten und Kommandos (bzw. Querys) konsequent getrennt bleiben.

Die besten Methoden dafür sind entweder eine sichere API, die die direkte Interpreter-Nutzung vollständig vermeidet, bzw. die eine parametrisierte, typgebundene Schnittstelle anbietet oder die korrekte Verwendung eines ORM-Frameworks.
Anmerkung: Stored Procedures können - auch parametrisiert - immer noch SQL-Injection ermöglichen, wenn PL/SQL oder T-SQL Anfragen und Eingabedaten konkateniert oder mit EXECUTE IMMEDIATE oder exec() ausgeführt werden.
Für die serverseitige Eingabe-Validierung empfiehlt sich die Nutzung eines Positivlisten(“Whitelist”)-Ansatzes. Dies ist i.A. kein vollständiger Schutz, da viele Anwendungen Sonder- und Meta-Zeichen z.B. für Textfelder oder Mobile Apps benötigen.
Für jede noch verbliebene dynamische Query müssen Sonder- und Meta-Zeichen für den jeweiligen Interpreter mit der richtigen Escape-Syntax entschärft werden.
Anmerkung: Ein Escaping von SQL-Bezeichnern, wie z.B. die Namen von Tabellen oder Spalten usw. ist nicht möglich.
Falls Nutzer solche Bezeichner selbst eingeben können, so ist dies durchaus gefährlich. Dies ist eine übliche Schwachstelle bei Software, die Reports aus einer Datenbank erstellt.
Querys sollten LIMIT oder andere SQL-Controls verwenden, um den möglichen Massen-Abfluss von Daten zu verhindern.

Mögliche Angriffsszenarien

Szenario 1: Eine Anwendung nutzt ungeprüfte Eingabedaten für den Zusammenbau der folgenden verwundbaren SQL-Abfrage:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Szenario 2: Auch das blinde Vertrauen in Frameworks kann zu Querys führen, die ganz analog zu obigem Beispiel verwundbar sind (z.B. Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery("FROM accounts
WHERE custID='" + request.getParameter("id") + "'");

In beiden Fällen kann ein Angreifer den ‘id’-Parameter in seinem Browser ändern und sendet: ' or '1'='1. Zum Beispiel so:

http://example.com/app/accountView?id=' or '1'='1 

Hierdurch wird die Logik der Anfrage verändert, so dass alle Datensätze der Tabelle „accounts“ ohne Einschränkung auf einen Kunden zurückgegeben werden.
Gefährlichere Attacken wären z.B. das Ändern oder Löschen von Daten oder das Aufrufen von Stored Procedures.

Referenzen

OWASP