Verbringen Sie nicht viel Zeit mit Problemumgehungen oder halben Korrekturen. Jede Minute, die Sie damit verbringen, die hier vorgeschlagenen Vorschläge zu implementieren, ist eine Minute, die Sie mit der Implementierung vorbereiteter Anweisungen hätten verbringen können. Dies ist die einzig wahre Lösung.

Wenn Sie eine SQLi-Sicherheitsanfälligkeit haben, wird der Angreifer wahrscheinlich am Ende gewinnen, egal was Sie tun, um sie zu verlangsamen. Beachten Sie also, dass Sie zwar Verbesserungen vornehmen können, aber am Ende ein verlorenes Spiel spielen, es sei denn, Sie beheben die Hauptursache des Problems.

Was Sie bisher versucht haben: Das Ausblenden von Fehlermeldungen ist a guter Start. Ich würde Ihnen empfehlen, noch strengere Berechtigungen anzuwenden (siehe unten). Es ist fraglich, ob das Ändern von Tabellennamen hilft, aber wahrscheinlich tut es nicht weh.

Ok, was ist mit diesen Berechtigungen? Beschränken Sie die Möglichkeiten des Datenbankbenutzers so weit wie möglich auf Tabellen- oder sogar Spaltenebene. Sie können sogar mehrere Datenbankbenutzer erstellen, um die Dinge noch mehr zu sperren. Verwenden Sie beispielsweise nur einen Datenbankbenutzer mit Schreibberechtigung, wenn Sie tatsächlich schreiben. Stellen Sie nur dann eine Verbindung mit einem Benutzer her, der das Recht hat, die Kennwortspalte zu lesen, wenn Sie die Kennwortspalte tatsächlich lesen müssen. Auf diese Weise kann eine Injection-Sicherheitsanfälligkeit in einer anderen Abfrage nicht zum Durchsickern von Kennwörtern genutzt werden.

Eine weitere Option ist die Verwendung einer WAF (Web Application Firewall), z. B. mod_security für Apache. Sie können es so konfigurieren, dass Anforderungen blockiert werden, die verdächtig aussehen. Kein WAF ist jedoch perfekt. Die Konfiguration erfordert Zeit und Energie. Sie sollten diese Zeit wahrscheinlich besser nutzen, um vorbereitete Anweisungen zu implementieren.

Lassen Sie sich auch hier nicht davon in ein falsches Sicherheitsgefühl locken. Es gibt keinen Ersatz für die Behebung der Grundursache des Problems.

Der einzig richtige Weg ist die Verwendung vorbereiteter Anweisungen.

1. Wenn Sie Fehlermeldungen verschleiern, ist dies etwas schwieriger, kann Angreifer jedoch nicht aufhalten.
2. Sie können Die Rechte einschränken, aber alle dem Benutzer gewährten Rechte können vom Angreifer erlangt werden. In einigen Fällen ist es auch möglich, Shell-Befehle über eine SQL-Injection auszuführen.
3. Das Umbenennen von Tabellen hilft Ihnen nicht weiter. Das Tool sqlmap erzwingt die Tabellennamen für Sie char für char. Das braucht nicht viel Zeit.
ol>

Sie können auch die Anzahl der Anrufe einschränken, um es Angreifern zu erschweren oder Warnungen bei verdächtigen Anrufen zu erstellen und dieses Handbuch zu beenden. Die einzig richtige Methode zur Behebung dieses Problems ist jedoch die Verwendung vorbereiteter Anweisungen. Durchsuchen Sie einfach Ihren Quellcode und werfen Sie einen Blick auf SQL-Anweisungen mit dynamischem Inhalt und ersetzen Sie diese.

Wir wissen, aber wir haben nicht genügend Entwickler / Tester, um es 100% sicher zu machen.

Dies ist das eigentliche Problem . Solange Sie nicht mehr Mitarbeiter einstellen oder Prioritäten neu zuweisen, sind Sie nicht sicher. Das Stoppen von 99,9% der Angreifer bedeutet, dass Ihre Daten kompromittiert wurden. Pflasterlösungen sind eine schlechte Sache und funktionieren nicht . Verschwenden Sie keine Zeit damit, Ihr SQL-Zugriffsmuster zu überarbeiten, während Sie möglicherweise tatsächliche Probleme beheben.

Bei der Codelösung ist die Verwendung vorbereiteter Anweisungen, wie viele hier vorschlagen, der einfachste Weg, SQL sicher zu verwenden.

Es ist viel einfacher als die Verwendung von PHP, um die Argumente selbst zu bereinigen, und kostet viel weniger Zeit. Durchsuchen Sie einfach Ihre gesamte Codebasis nach allem, was mit SQL zu tun hat, und korrigieren Sie es.

Löschen Sie das gesamte SQL für immer aus Ihrem Code.

Die beste Lösung für dieses Problem besteht darin, den gesamten SQL-Code als Literalzeichenfolgen aus Ihrem Code zu löschen und ihn nie wieder einzuführen. Verwenden Sie stattdessen ORM -Software wie Hibernate oder Entity Framework. Diese Software ist ohnehin viel besser zu verwenden als Raw SQL und parametrisiert Ihr SQL automatisch, wenn es schließlich in die Datenbank gelangt. Wenn es Ihnen möglich ist, haben Sie diese Richtlinie.

Wenn Sie nicht die Zeit haben, diese Pakete zu lernen und zu implementieren, oder sie aus einem anderen Grund nicht verwenden können, ist die Antwort von trietend die nächstbeste vorbereitete Aussagen. Auf diese Weise können Sie sich vor SQL-Injection schützen. Das heißt, bis Sie Druck auf Ihre Entwickler ausüben, schnelle Lösungen zu liefern. Zu diesem Zeitpunkt vergessen sie möglicherweise erneut, eine einzelne Variable zu parametrisieren, sodass Sie wieder dort sind, wo Sie begonnen haben.

Wir wissen, aber wir haben nicht genügend Entwickler / Tester, um es 100% sicher zu machen.

Es ist nicht ganz klar, was Sie mit dieser Aussage meinen, wie vorbereitet Anweisungen sind in jeder gängigen Web-Sprache (PHP, Python, Java, node.js usw.) trivial und mehr oder weniger eine 100% ige wirksame Maßnahme gegen SQL-Injection.

Meinen Sie, Sie vergeben Unteraufträge Entwicklung und können es sich nicht leisten, den Code, den sie für Sie im Vertrag schreiben, einer Qualitätssicherung zu unterziehen? Sie können es sich nicht leisten, dies nicht zu tun: Sie sind hier immer noch die verantwortliche Partei.

Meinen Sie, dass Ihre Entwickler zu beschäftigt sind, Funktionen zu implementieren, um einige Stunden für die Aktualisierung der Codebasis zu benötigen? Alles andere als vorbereitete Anweisungen dauert länger und kostet mehr (z. B. ORM, Verschleierung, fein abgestimmte Berechtigungen usw.).

Meinen Sie, Ihre Entwickler sind nicht kompetent genug, um diese einfache Aufgabe auszuführen? Das ist ein viel größeres Problem (oder genauer gesagt, die SQL-Injection sollte zu diesem Zeitpunkt nicht Ihr größtes Problem sein) code> include s, die selbst kompetente Entwickler für immer brauchen werden, um eine ansonsten einfache Aufgabe von wenigen Stunden auszuführen? Ebenso größeres Problem.

Was auch immer es ist, die Lösung besteht darin, vorbereitete Aussagen zu verwenden, etwa gestern.

Sobald der erste Ratschlag für "vorbereitete Anweisungen" implementiert wurde, würde ich empfehlen, etwas über SQL-Injection zu lesen. Die Frage "Wie verhindere ich die SQL-Injection?" Ist eine ziemlich breite Frage! Sicherheit ist ein Thema, mit dem Sie (und nicht Ihr gesamtes Entwicklerteam) vertraut sein müssen, um das Risiko von Kompromissen zu verringern. Ein Loch untergräbt alle anderen Anstrengungen.

Besuchen Sie das Open Web Application Security Project (OWASP) hier: https://www.owasp.org/index.php/SQL_Injection

Insbesondere das Zusätzliches Material:

• Spickzettel zur Verhinderung von SQL-Injektionen

• Leitfaden zum Vermeiden von Sicherheitsanfälligkeiten in SQL Injection

und

• Überprüfen von Code auf Sicherheitsanfälligkeiten in SQL Injection

Eine Notlösung wäre die Untersuchung einer Webanwendungs-Firewall (WAF). Es gibt einige Unternehmen, die dies als Service anbieten, und einige Cloud-Anbieter, die ebenfalls Angebote anbieten. CloudFlare scheint einen anzubieten, ich habe Incapsula von einem Client verwenden lassen, und ich weiß, dass das AWS WAF-Angebot einige verwaltete Regelsätze für die SQL-Injection enthält.

Auf diese Weise wird der gesamte Datenverkehr an / über die WAF gesendet (entweder indem er auf Servern eingeschlossen wird oder indem DNS so eingestellt wird, dass er wie bei einem CDN auf die WAF verweist), und es wird nach Dingen gesucht das sieht aus wie SQL-Injection-Versuche in den Parametern. Es fängt nicht alle Angriffe ab und blockiert möglicherweise legitimen Datenverkehr, ist jedoch eine verfügbare Bandaid-Korrektur.

Mit "nicht genügend Entwickler" meine ich, dass einige einflussreiche Personen in Ihrem Unternehmen der Meinung sind, dass es höhere Prioritäten gibt. Alle Ressourcen, die Sie haben, werden für diese Dinge verwendet. Die Behebung Ihres Sicherheitsproblems geht also in einer Kosten-Nutzen-Analyse gegen andere Dinge verloren.

Ihre Aufgabe hier ist es, ihre Meinung zu ändern und das Update zu implementieren. Quantifizieren Sie, worum es geht - was wäre der Geld- und Reputationsschaden eines weiteren Verstoßes? In Ihrem Land gibt es möglicherweise Gesetze, nach denen Sie verpflichtet sind, Kompromisse bei den Daten Ihres Benutzers zu melden. Wäre das peinlich? Könnte es Medienberichte über die schlechten Praktiken Ihrer Organisation geben?

Stellen Sie sich die Investition zur Reparatur der Sicherheit als Versicherung vor. Wenn Sie im Nachhinein wissen, dass Ihr Gebäude zehn Jahre lang nicht niedergebrannt ist, könnten Sie argumentieren, dass Ihre Prämien eine Verschwendung waren. Aber Sie und Ihre Organisation zahlen für Versicherungen, weil Sie vor einer ungewissen Zukunft stehen. Es ist Risikomanagement.

Das Risiko hat zwei Faktoren: Wahrscheinlichkeit und Auswirkung. Die Wahrscheinlichkeit eines weiteren Verstoßes ist hoch - Sie wissen, dass dies mindestens einmal möglich ist und wurde. Wenn die möglichen Folgen ebenfalls schlimm sind, sollten Sie die Priorität für die Behebung Ihrer Sicherheitslücken erhöhen.

Wie bereits erwähnt, korrigieren Sie den Code auf der Website.

Sie können beliebige Patches an einer Wand anbringen, aber bis die Wand korrekt aufgebaut ist, sind alle Patches ein Problem für Blutungen.

Jeder andere Vorschlag, Code zu bereinigen, würde Linus Torvalds als Masterbation bezeichnen.

• Korrigieren Sie Ihren Code (von den offensichtlichsten Injektionspunkten aus) bis zum letzten IE Get params) und verwenden Sie vorbereitete Anweisungen. Wie kann ich die SQL-Injektion in PHP verhindern?

• Sie können eine WAF (IE ModSecurity ausprobieren ) vorübergehend, bis Sie in der Lage sind, Dinge zu reparieren.

• Versuchen Sie vielleicht eine Art IP-Verbot für "Personen, die die Site testen" oder das Blockieren unsicherer Abfragen.

• Wenn Sie haben die Möglichkeit, einen temporären (sicheren) Anmeldebildschirm vor sich zu erstellen, bis dies behoben ist.

• Versuchen Sie es mit einem Drittanbieter, bis dies behoben ist, z. B. durch Cloudflare oder was auch immer

PDOs sind seit der Veröffentlichung von PHP 5.1 am 24. November 2005 verfügbar ... Entwickler müssen verstehen, dass sie Konsequenzen haben Ihre schlechten Codierungsgewohnheiten und ich persönlich denke, dass die Qualität der geleisteten Arbeit rechenschaftspflichtig sein sollte.

Auf jeden Fall sind PDOs eine einfach zu implementierende Sache. Wenn Ihre Entwickler keine bessere Qualität liefern können, würde ich eine Bereinigung vorschlagen ...

Die wichtigste Regel lautet:

Verwenden Sie Bibliotheken, Tools und APIs, die die sichere Option zur einfachsten Option machen.

Nacht sagt "Verwenden Sie einfach Ein ORM ", der eine Teilmenge dieser Regel ist.

Vorbereitete Anweisungen verstoßen gegen diese Regel, da ihre Verwendung umständlich ist und zu einem Aufblähen des Codes führt. Außerdem können sie abhängig von Ihrer Regel häufig langsamer sein als nicht vorbereitete Anweisungen Datenbank. Sie sind eine gültige Lösung, ich werde niemanden kritisieren, der sie verwendet, aber sie sind nicht unbedingt die beste und bequemste Lösung.

Und ... wir möchten, dass die sichere Option einfach und bequem ist Der Programmierer benutzt es aus Eigennutz und Faulheit. Wir möchten, dass der Programmierer wirklich alles unternimmt, um die unsichere Option zu nutzen! ...

Eine viel bessere Lösung ist eine API wie Python dbapi. Ich habe vor Jahren ein PHP-Äquivalent geschrieben, das wie folgt aussah:

  db_query ("SELECT * FROM mytable WHERE id =% s", $ id)  

Dies ist bequemer als vorbereitete Aussagen. Nur eine Zeile zum Tippen. Außerdem wird das Ergebnis in einer Form zurückgegeben, die foreach () verwenden kann, sodass es viel einfacher zu verwenden ist als fetch () und so weiter. Noch wichtiger ist, dass der hinter dieser API verborgene Code das Escape-Verfahren ordnungsgemäß handhabt. Dies macht SQL-Injektionen irrelevant. Dies behandelt ungefähr 99% der Abfragen, wenn Sie kein ORM verwenden. Dynamische Abfragen (normalerweise Suche) erfordern zwar eine spezielle Behandlung, sind aber dennoch einfach.

Wenn Sie diese Regel beachten, müssen Sie sich irgendwann fragen, warum Sie htmlspecialchars () verwenden müssen. und warum hat die Sprache keine Funktion, mit der die sichere Einstellung (dh keine XSS-Vulns) am einfachsten zu verwenden ist? Warum Oh warum? Und dann lassen Sie PHP fallen.

Zusätzlich zu all den bisher guten Antworten können Sie Ihre Datenbank so umgestalten, dass die Kennwörter in einer separaten Tabelle mit strengen Zugriffsrechten gespeichert werden, wenn Sie das spezifische Problem des Extrahierens von Benutzeranmeldeinformationen lösen möchten Ähnlich wie Unix-Systeme sie in /etc/shadow ablegen.

Um Anmeldeinformationen zu überprüfen, benötigen Sie eine gespeicherte Prozedur, die das eingegebene Kennwort (oder den Hash) als Parameter verwendet und einen Booleschen Wert zurückgibt. Mit anderen Worten, Sie verlagern die Aufgabe der Überprüfung von Anmeldeinformationen in die Datenbank, und der tatsächliche Hash verlässt die Datenbank nie.

Dies erfordert nur ein minimales Refactoring und löst Ihr unmittelbares Problem im Stammverzeichnis anstelle einer bestimmten SQL-Injection Sie sind für den nächsten anfällig.