it-swarm.com.de

Ist es möglich, 100% von SQLi mit einem einfachen regulären Ausdruck zu erkennen?

Ich frage mich, ob es möglich ist, 100% der möglichen SQLi-Angriffe mit einem einfachen regulären Ausdruck zu erkennen.

Mit anderen Worten, mit sehr einfachem PHP Code als Beispiel:

if (preg_match("/select/i", $input)) {
    attack_log("Possible SELECT SQLi detected.")
}

Die Fragen sind:

  • Wird dieser Regex alle möglichen SQLi-Angriffe abfangen, die SELECT verwenden? Wenn nicht, ist es möglich, diesen regulären Ausdruck so zu ändern, dass alle Injektionen erkannt werden, die auf SELECT beruhen?
  • Ist es möglich, diesen regulären Ausdruck so zu ändern, dass alle möglichen SQLi-Anweisungen abgefangen werden, also nicht nur SELECT-Anweisungen, sondern auch alle anderen? Ich befürchte, dass ich, um dies zu erreichen, jedes mögliche SQL-Schlüsselwort zur Regex hinzufügen müsste, einschließlich "AND" und "OR".
  • Angenommen, es ist nicht möglich oder machbar, alle SQLi zu erkennen, indem versucht wird, alle möglichen SQL-Schlüsselwörter abzugleichen. Gibt es eine begrenzte Teilmenge von Schlüsselwörtern, mit denen ich die überwiegende Mehrheit der möglichen Angriffe erkennen kann?
37
reed

Die Schlüsselwortfilterung für SQLi ist keine gute Technik. Es gibt zu viele Möglichkeiten, dies zu umgehen.

Verrückte Dinge wie sel/**/ect Könnten zum Beispiel funktionieren. Oder Spiele mit substr() spielen. Und dann gibt es EXEC('SEL' + 'ECT 1').

Es gibt viele Anleitungen zum Umgehen gängiger Filtertechniken.

Aber dann könnten Sie fragen, ob es eine Obermenge von Dingen gibt, nach denen gefiltert werden muss (wie select und /**/ Und substr und EXEC), aber dann die Liste wird sehr, sehr lang und Sie erhalten möglicherweise immer noch keine umfassende Liste.

Der bessere Ansatz besteht darin, den Bereich akzeptabler Eingaben zu verstehen und diese zu schützen oder die Verwendung von SQLi durch ordnungsgemäßes Design unwirksam zu machen.

169
schroeder

NEIN

Da jede SQL-Injection (per Definition) gültiges SQL ist und SQL eine kontextfreie Sprache ( Quelle ) ist, gibt es (wiederum per Definition) keinen regulären Ausdruck, der mit einer SQL-Injection übereinstimmen und es versuchen kann dies zu tun würde wahrscheinlich ein ähnliches Ergebnis wie this ergeben.

Verwenden Sie, wie in so ziemlich jedem Kommentar gesagt, das richtige Werkzeug für den Job. In diesem Fall handelt es sich um eine vorbereitete Aussage.

106
Sefa

Technisch ist dies völlig möglich (obwohl dies auch die Datenbank unbrauchbar macht):

  • .+ Erkennt tatsächlich jedes mögliche SQLi.

Es erkennt jedoch auch jeden Versuch, normale Abfragen (oder überhaupt einen Text) durchzuführen, wodurch die Datenbank vollständig unbrauchbar wird .

Sie können auch sagen, dass das Deaktivieren der Datenbank vor SQLi schützt. Es ist wahr, aber es macht die Datenbank auch für den beabsichtigten Zweck unbrauchbar.

Verwenden Sie vorbereitete Anweisungen oder parametrisierte Abfragen. Sie existieren, um dieses Problem zu lösen.

58
Fake Name

Ich frage mich, ob es möglich ist, 100% der möglichen SQLi-Angriffe mit einem einfachen regulären Ausdruck zu erkennen.

Die Tatsache, dass Sie die Frage auf diese Weise stellen, zeigt, dass Sie falsch über das Problem nachdenken.

SQL Injection ist keine Sicherheitslücke in Daten. Es ist eine Sicherheitslücke in der Anwendung Code dass behandelt diese Daten.

Zum Beispiel: Im Moment tippe ich eine "SQL Injection" in einen Textbereich auf einer Website! Und ich kann so etwas wie '- DROP TABLE Users; genau hier! Ist meine Antwort ein SQL-Injection-Angriff? Natürlich nicht.

Nun könnten Sie argumentieren, dass Sie versuchen, versuchte SQL-Injection-Angriffe zu erkennen. Aber jetzt müssen Sie die Absicht einer Eingabe bestimmen. Wenn ich einen bloßen Apostroph in ein Feld eingebe, ist das ein Tippfehler oder ein versuchter SQL-Injection-Angriff? Können Sie 100% meiner Absichten erkennen? Natürlich nicht.

Grundsätzlich bedeutet der Versuch, mögliche Angriffe zu identifizieren, dass Ihre Erkennungsrate niemals 100% betragen kann.

Da eine SQL-Injection-Schwachstelle nur im Code und nicht in Daten vorhanden ist, unterliegt jede Analyse, bei der nur Daten berücksichtigt werden, bestenfalls einer sehr hohen Falsch-Positiv-Rate. Jede von Ihnen entwickelte Lösung, die möglicherweise dem gesamten tatsächlichen Angriffsverkehr entspricht, würde auch eine sehr große Menge von legitim Verkehr auf dieser Website und vielen anderen als "Angriffe" interpretieren, wenn kein solcher Angriff beabsichtigt war.

23
Daniel Pryden

Erstens gibt es einige böse Dinge, die Sie mit SQL-Injektionen tun können, für die die Verwendung des Schlüsselworts SELECT nicht erforderlich ist, wie das berüchtigte universelle Passwort ' OR '1' = '1 oder der gemeinsame Benutzername Robert'); DROP TABLE Students;-- . Außerdem ist "select" ein sehr verbreitetes Wort in der englischen Sprache, das in allen möglichen Kontexten auf völlig harmlose Weise vorkommen kann. Wenn Sie also eine Eingabe filtern, die mit /select/i Sie werden eine Menge falsch positiver Ergebnisse erhalten (16 falsch positive Ergebnisse und zählen beispielsweise nur auf der Website, die Sie gerade lesen).

Wenn Sie Eingaben bereinigen möchten, bevor Sie Daten an Ihre Datenbank senden, dann PHP hat eine praktische Funktion für diesen Zweck (dies sind die für mySQL, alle anderen Datenbank-APIs sollten eine ähnliche Funktion bereitstellen, die auf diese bestimmte Datenbank zugeschnitten ist Syntax).

Wenn Sie jedoch versuchen, sich vor SQL Injections zu schützen, indem Sie bestimmte Eingaben blockieren, kämpfen Sie an der falschen Front. Es wäre viel klüger, sich gegen SQL-Injektionen zu verteidigen, indem Sie aufhören, SQL-Anweisungen durch Verkettung von Zeichenfolgen zu erstellen. Übliche alternative Möglichkeiten zur Interaktion mit Datenbanken, die das unbeabsichtigte Schreiben von SQL-Injektionen erschweren, sind:

  • Verwenden Sie einen ORM-Wrapper, der SQL-Abfragen für Sie schreibt
  • Verwenden Sie parametrisierte Abfragen (auch als vorbereitete Anweisungen bezeichnet).
  • Verwenden Sie eine Programmiersprache, in der SQL Teil der Sprachsyntax ist
  • Verwenden Sie gespeicherte Prozeduren
9
Philipp