Das Problem
Wir müssen uns gegen einen "WAITFOR DELAY" -SQL-Injection-Angriff in unserer Java-Anwendung wehren.
Hintergrund
[Das ist lang. Weiter zu 'Lösung?' Abschnitt unten, wenn Sie in Eile sind]
Unsere Anwendung verwendet hauptsächlich vorbereitete Anweisungen und aufrufbare Anweisungen (gespeicherte Prozeduren) beim Zugriff auf die Datenbank.
An einigen Stellen erstellen und führen wir Abfragen dynamisch zur Auswahl aus. In diesem Paradigma verwenden wir ein Kriterienobjekt, um die Abfrage abhängig von den Benutzereingabekriterien zu erstellen. Wenn der Benutzer beispielsweise Werte für Vorname und Nachname angibt, sieht die Ergebnisabfrage immer so aus:
%Vor%(In diesem Beispiel hätte der Benutzer "joe" und "frazier" als seine Eingabewerte angegeben. Wenn der Benutzer mehr oder weniger kritische Punkte hätte, hätten wir längere oder kürzere Abfragen. Wir haben herausgefunden, dass dieser Ansatz einfacher ist als vorbereitete Anweisungen zu verwenden und schneller / leistungsfähiger als gespeicherte Prozeduren).
Der Angriff
Bei einer Schwachstellenprüfung wurde ein Fehler bei der SQL-Injektion gemeldet. Der Angreifer injizierte den Wert 'frazier WAITFOR DELAY' 00: 00: 20 'für den Parameter' last_name ', was zu diesem sql:
führte %Vor%Das Ergebnis: Die Abfrage wird erfolgreich ausgeführt, dauert jedoch 20 Sekunden. Ein Angreifer kann alle Datenbankverbindungen im Datenbankpool binden und Ihre Site effektiv herunterfahren.
Einige Beobachtungen zu diesem 'WAITFOR DELAY' Angriff
Ich hatte gedacht, dass wir, weil wir Statement executeQuery (String) verwenden, vor sql injection sicher wären. executeQuery (String) führt keine DML oder DDL aus (löscht oder löscht). Und executeQuery (String) Drosseln auf Semikolon, so dass das 'Bobby Tables' Paradigma fehlschlägt (dh Benutzer gibt 'frazier; DROP TABLE Mitglied' für einen Parameter. Siehe. Ссылка )
Der 'WAITFOR' Angriff unterscheidet sich in einem wichtigen Punkt: WAITFOR modifiziert den existierenden 'SELECT' Befehl und ist kein separater Befehl.
Der Angriff funktioniert nur mit dem 'letzten Parameter' in der resultierenden Abfrage. "WAITFOR" muss am Ende der SQL-Anweisung auftreten
Lösung, billiger Hack oder beides?
Die offensichtlichste Lösung besteht darin, einfach AND 1 = 1 auf die where-Klausel zu setzen.
Der resultierende SQL schlägt sofort fehl und vereitelt den Angreifer:
%Vor%Die Fragen
Die korrekte Verarbeitung von SQL-Injection besteht in der Verwendung parametrisierter Abfragen. Alles andere ist nur in den Wind gepisst. Es könnte einmal, sogar zweimal, funktionieren, aber irgendwann wirst du von diesem warmen Gefühl getroffen, das sagt "du hast es vermasselt, schlecht!"
Was auch immer Sie tun, außer parametrisierten Abfragen, wird suboptimal sein, und es liegt an Ihnen, sicherzustellen, dass Ihre Lösung keine anderen Lücken aufweist, die Sie patchen müssen.
Auf der anderen Seite funktionieren parametrisierte Abfragen sofort und verhindern alle diese Angriffe.
SQL-Injektion ist SQL-Injektion - es gibt nichts Besonderes an einem WAITFOR DELAY .
Es gibt absolut keine Entschuldigung dafür, in dieser Zeit keine vorbereiteten Anweisungen für solch eine einfache Abfrage zu verwenden.
(Edit: Okay, nicht "absolut" - aber es gibt fast nie eine Entschuldigung)
Ich denke, Sie haben die Lösung selbst vorgeschlagen: Parametrisierte Abfragen .
Wie haben Sie festgestellt, dass Ihre dynamisch erstellte Abfrage schneller ist als die Verwendung einer gespeicherten Prozedur? Im Allgemeinen ist es oft das Gegenteil.
Um alle Ihre Fragen zu beantworten:
Ist dies eine brauchbare Lösung für den WAITFOR-Angriff?
Nein. Fügen Sie einfach - zur Angriffszeichenfolge hinzu und es wird Ihre Korrektur ignorieren.
Wirkt es gegen andere ähnliche Schwachstellen?
Nein. Siehe oben.
Ich denke, die beste Option wäre die Verwendung vorbereiteter Aussagen. Mehr Arbeit, aber weniger anfällig.
Ja. Sie beheben die SQL-Injektion nicht selbst. Sie verwenden, was bereits vorhanden ist, und Sie verwenden es richtig, indem Sie einen dynamischen Teil Ihrer Abfrage parametrisieren.
Eine andere, kleinere Lösung besteht darin, jede Zeichenfolge zu entkommen, die in Ihre Abfrage eingefügt wird. Sie werden jedoch einen Tag vergessen, und Sie brauchen nur einen, um angegriffen zu werden.
Alle anderen haben dies (Parametrisieren!) genagelt, aber nur um ein paar Punkte hier zu berühren:
- Ist das eine brauchbare Lösung für den WAITFOR-Angriff?
- Wirkt es gegen andere ähnliche Sicherheitslücken?
Nein, tut es nicht. Der WAITFOR-Trick wird höchstwahrscheinlich nur zum "Sniffing" für die Schwachstelle verwendet; Sobald sie die anfällige Seite gefunden haben, können sie ohne DDL oder (die Nicht-SELECT-Teile von) DML viel mehr tun. Denken Sie zum Beispiel darüber nach, ob sie den folgenden Namen als letzten_Name
übergeben haben %Vor%Auch nachdem Sie AND 1 = 1 hinzugefügt haben, werden Sie immer noch abgespritzt. In den meisten Datenbanken gibt es viele schädliche Dinge, die Sie nur mit SELECT-Zugriff tun können ...
Wie wäre es, wenn Sie xkcd folgen und die Eingabe bereinigen? Sie können nach reservierten Wörtern im Allgemeinen und nach WAITFOR insbesondere suchen.
Tags und Links sql-server jdbc sql-injection