SQL-Injection-Scanner auswählen

Angenommen, ein in ein Suchformular eingegebener Wert wird unverändert als Bestandteil einer SQL-Anweisung eingebaut. Eine dynamische Prüfung sendet tatsächlich Anfragen und sucht unter anderem anhand unterschiedlicher Antworten nach Problemen. Die Codeanalyse verfolgt dagegen, woher ein Wert kommt und an welche Abfragen er übergeben wird.

Dynamische Prüfungen können nur Oberflächen oder APIs untersuchen, die sie erreichen. Auch die Codeanalyse kann Probleme übersehen, abhängig von den unterstützten Sprachen und Frameworks sowie der Konfiguration des Analyseumfangs. Selbst wenn eines der Verfahren keine Befunde liefert, lässt sich daraus nicht schließen, dass das andere unnötig ist.

ZAP: Eine Open-Source-Option, wenn Sie eine Webanwendung insgesamt überprüfen möchten. Es bietet aktive Scanregeln für SQL-Injection und kann zugleich auf weitere Webschwachstellen prüfen. ZAP Baseline führt allerdings standardmäßig passive Scans durch. Allein dessen Ausführung bedeutet daher nicht, dass eine aktive Prüfung auf SQL-Injection abgeschlossen ist.

sqlmap: Ein Open-Source-Werkzeug, wenn bei einer bestimmten Eingabestelle ein Verdacht besteht und Sie gezielt auf SQL-Injection prüfen möchten. Da es neben der Erkennung auch Funktionen zur automatisierten Ausnutzung bietet, sollten Sie den erlaubten Umfang festlegen und es in einer Umgebung einsetzen, in der sich die Auswirkungen begrenzen lassen.

Burp Suite Professional: Für Verantwortliche, die HTTP-Anfragen untersuchen und dabei Scanner und manuelle Überprüfung kombinieren möchten. Der automatische Scanner ist unter anderem in der kostenpflichtigen Professional enthalten, nicht jedoch in der kostenlosen Community Edition.

Wapiti: Ein Open-Source-Werkzeug, das Webanwendungen über die Kommandozeile nach dem Blackbox-Prinzip untersucht. Die offizielle Dokumentation beschreibt SQL-Injection-Prüfungen anhand von Fehlern, Wahrheitswerten und Zeitunterschieden sowie API-Scans mithilfe von OpenAPI-Dateien. Prüfen Sie bei Zielen mit SPAs oder komplexer Authentifizierung jeweils gesondert, ob die erforderlichen Pfade erreicht werden können.

Alle diese Werkzeuge senden Anfragen an laufende Anwendungen. Dokumentieren Sie zusammen mit den Ergebnissen, welche Bereiche erreicht wurden – nicht nur sichtbare Oberflächen, sondern auch APIs nach der Anmeldung, Verwaltungsoberflächen und die jeweiligen Benutzerberechtigungen. Kombinieren Sie dies gegebenenfalls mit statischer Quellcodeanalyse als gesondertem Ansatz.

Richten Sie in derselben Staging-Umgebung Eingabestellen mit bekannten Problemen und sicher parametrisierte Eingabestellen ein und vergleichen Sie die Ergebnisse. Prüfen Sie nicht nur, ob die problematischen Stellen erkannt werden, sondern auch, ob die sicheren fälschlich als problematisch eingestuft werden. Kontrollieren Sie außerdem, ob die Prüfung wegen einer abgelaufenen Authentifizierung vorzeitig gestoppt wurde und ob alle erforderlichen Einstiegspunkte einschließlich JSON-APIs durchlaufen werden konnten.

Scans können sich auf Testdaten oder die Verfügbarkeit auswirken. Holen Sie die ausdrückliche Erlaubnis des Eigentümers des Zielsystems ein und vereinbaren Sie den Prüfungsumfang, die Ausführungszeit, die Belastung und die auszuschließenden Aktionen. Testen Sie nach Möglichkeit in einer von der Produktion getrennten Umgebung.

Bei der in der NVD dokumentierten CVE-2023-34362 in MOVEit Transfer konnte SQL-Injection nicht authentifizierten Angreifern möglicherweise Zugriff auf die Datenbank verschaffen. Auch eine Ausnutzung im Mai–Juni 2023 ist dort vermerkt. Während der Entwicklung müssen daher nicht nur Abläufe nach der Anmeldung, sondern auch öffentlich zugängliche Pfade überprüft werden. Das folgende fiktive Lehrbeispiel verwendet TypeScript und node-postgres. Es zeigt weder die Implementierung von MOVEit noch Code zur Reproduktion dieser CVE. Beschränken Sie Prüfungen auf ausdrücklich freigegebene Ziele.

Die grundlegende Korrektur besteht darin, externe Werte nicht mit SQL-Zeichenketten zu verknüpfen, sondern als Parameter zu übergeben. Bestandteile der SQL-Struktur selbst, etwa die Sortierreihenfolge oder Tabellennamen, lassen sich allerdings unter Umständen nicht allein durch das Binden von Werten behandeln. Wählen Sie in solchen Fällen aus festen, von der Anwendung vorgegebenen Optionen.

Im nächsten Beispiel wird der Suchwert gebunden, während die Sortierreihenfolge durch die Auswahl einer von zwei festen Abfragen bestimmt wird. Beschränken Sie zusätzlich die Berechtigungen des Datenbankbenutzers auf das notwendige Minimum und prüfen Sie gesondert, ob der jeweilige Benutzer diese Daten sehen darf. Überprüfen Sie nach der Korrektur erneut, ob der ursprüngliche Befund behoben ist und die normale Suche weiterhin funktioniert.

import type { Pool } from "pg";

export async function findProducts(
  db: Pool, name: string, sort: string,
) {
  const queries = {
    newest: "SELECT id, name FROM products WHERE name = $1 ORDER BY created_at DESC, id DESC LIMIT 50",
    oldest: "SELECT id, name FROM products WHERE name = $1 ORDER BY created_at ASC, id ASC LIMIT 50",
  } as const;
  if (sort !== "newest" && sort !== "oldest") {
    throw new Error("Invalid sort");
  }
  return db.query(queries[sort], [name]);
}