Bereits sehr gute Antworten auf diese Frage, ich möchte jedoch noch einige weitere erwähnen:

• Sichere Codierung (die von vielen bereits erwähnt wurde)
  • Benutzer entkommen Eingabe
  • Parametrisierte Abfragen (vorbereitete Anweisungen, vordefinierte Abfragen, bei denen Sie nur Variablen binden)
  • Defensiver Code
• Überwachung auf Angriffe
  • Network Intrusion Detection System (NIDS)
  • Host Intrusion Detection System (HIDS)
  • Application Intrusion Detection System (AppIDS)
• Blockieren von Angriffen
  • Anwendungsfirewall
  • Datenbankfirewall
  • Webanwendungsfirewall
    • Apache ModSecurity
    • Cisco Application Velocity System (AVS)

Dies dient nur der Prävention und ich habe SQL Server Hardening berücksichtigt. Es gibt jedoch viele Ähnlichkeiten.

Zusätzliche Schutzmaßnahmen für den Fall, dass Sie bereits anfällig für Injektionen sind, sind:

• Ausführen Ihrer Anwendung mit der geringsten Anzahl an erforderlichen Zuschüssen
  • Gewähren Sie speziell nur Zugriff für die Datenbank und Tabellen, die Sie benötigen
  • Stellen Sie sicher, dass Sie nur die erforderlichen Berechtigungen erteilen (normalerweise auswählen, einfügen, aktualisieren)

Vorbereitete Anweisungen, parametrisierte Abfragen, die allen Benutzereingaben entgehen, für einen guten Einstieg siehe http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet.

Die Schlüsselverteidigung besteht darin, nur APIs zu verwenden, die Datenbankabfragen sicher entgehen. Diese werden im Allgemeinen als parametrisierte oder vorbereitete Anweisungen bezeichnet. Diese können nicht in allen Fällen verwendet werden (z. B. wenn zur Laufzeit ein SQL-Bezeichner wie der Tabellen- oder Spaltenname angegeben wird), sind jedoch nach Möglichkeit der beste Ansatz (in den meisten Fällen).

Hinweis - Dies kann dazu führen, dass schädliche Daten in die Datenbank aufgenommen werden. Beachten Sie dies, wenn Sie diese Daten an anderer Stelle in der Anwendung verwenden.

Die zweite Verteidigung besteht darin, einen Fluchtansatz zu wählen . Dies ist der Ansatz "Ersetzen Sie ein einfaches Anführungszeichen durch zwei Anführungszeichen". Wenn Sie diesen Weg gehen müssen, müssen Sie jedem potenziell schädlichen Zeichen entkommen, was in einigen Fällen mehr als einfache Anführungszeichen bedeutet. Ich würde empfehlen, wenn möglich eine übergeordnete Bibliothek wie OWASP ESAPI zu verwenden, um dies für Sie zu tun, oder das OWASP SQL Injection Cheat Sheet (siehe oben) genau zu lesen.

• Hier finden Sie einige SQL-Injection-Ressourcen
• Hier sind einige SQL-Injection-Angriffe anhand eines Beispiels
• Im Folgenden finden Sie einige Grundlagen zum Schutz Ihrer Anwendung vor SQL-Injection

Der Hauptschritt zum Schutz von Webanwendungen vor SQL-Injection besteht darin, alle Benutzer ordnungsgemäß zu bereinigen Eingabe (insbesondere Eingabe, die in SQL-Abfragen verwendet wird). In einigen Sprachen / Frameworks gibt es Standardmethoden für den Umgang mit diesen Werten - beispielsweise mithilfe von parametrisierten Abfragen, anstatt die Abfrage durch Verknüpfen von Zeichenfolgenwerten zu erstellen.

Von Seiten der Webentwickler sollte die Aufmerksamkeit auf das gelenkt werden, was Weber bereits erwähnt hat.

Zusätzlich könnte eine Datenbank-Firewall wie GreenSQL eingerichtet werden: http://www.greensql.net/. Es funktioniert wie ein Proxy zwischen Ihrer Anwendung und Benutzereingaben, überwacht, was durchlaufen werden soll usw. Dies ist jedoch mit Kosten für eine längere Antwortzeit verbunden.

Ich unterrichte IT-Sicherheit an Fachhochschulen. Oft haben Schüler Verwirrung über die Begriffe, die für die SQL-Injection verwendet werden. Lassen Sie mich daher versuchen, dies zu klären.

Im Kontext einer Webanwendung wie Facebook ist

SQL-Injection der Zeitpunkt, an dem die Ein normaler Webbenutzer gibt SQL-Code in Datenfelder ein, z. B.

  'OR' 1 '=' 1 in die Textfelder eines Anmeldeformulars.  

Die beste Person Um die SQL-Injektion zu verhindern, ist der Webentwickler, auch bekannt als die Person, die für das Schreiben von Code für die Webanwendung zum Lesen / Schreiben von Daten in die Datenbank verantwortlich ist.

Die einfachste Möglichkeit, die SQL-Injektion durch den Webentwickler zu verhindern, ist die Verwendung parametrisierte Abfragen.

Vorbereitete Anweisungen und parametrisierte Abfragen bedeuten dasselbe.

Ich werde ab diesem Punkt parametrisierte Abfragen verwenden.

Parametrisierte Abfragen beziehen sich auf die Art und Weise, wie SQL-Code zuerst definiert und dann die Daten in die entsprechenden Parameter eingefügt werden.

ZB in .Net

  Aktualisieren Sie "Benutzer" name` = @name wobei ʻid` = @id  

die Parameter @name und @id sind die Daten. Der Rest ist der SQL-Code.

Beachten Sie, dass die parametrisierten Abfragen normalerweise , aber nicht immer im Webanwendungscode ausgeführt werden.

Es gibt zwei häufig verwendete Abfragen Möglichkeiten zum Schreiben parametrisierter Abfragen.

1. Im Webanwendungscode abhängig von der verwendeten Sprache
2. In der Datenbank mit gespeicherten Prozeduren
ol>

Also in gewissem Sinne ja Gespeicherte Prozeduren sind eine Form parametrisierter Abfragen.

Es gibt andere Möglichkeiten, die SQL-Injection zu verhindern, indem Sonderzeichen wie einfache Anführungszeichen maskiert werden. In PHP können Sie beispielsweise mysql_real_escape_string verwenden, bei dem im Grunde nur Schrägstriche vor den einfachen Anführungszeichen stehen.

Dies ist nicht ideal, da in bestimmten Datenbanken wie MySQL Probleme mit% und dem Unterstrich für den LIKE-Operator auftreten. Weitere Informationen finden Sie in diesem PDF.

Kurz gesagt, alle vorgeschlagenen Optionen haben mit der Bereinigung (Bereinigung) von Benutzereingaben zu tun, um den SQL-Code zu bereinigen.

Am besten verwenden Sie parametrisierte Abfragen in Abhängigkeit von der verwendeten Programmiersprache.

Ende der Geschichte.

Verwenden Sie anständige Datenzugriffs-APIs, mit denen Sie auf einfache Weise sicher und sicher das Richtige tun können.

Hier ist ActiveRecord v3:

  # basic usage @ user = User. where (: username = > 'joe@example.com'). first # mit einem SQL-String-Fragment, jedoch unter Verwendung der Parameter @ projects = @ user.projects.where ('status =?', params [: status])