Frage:
Wie kann man ein $ _GET in PHP richtig sichern?
Digital fire
2012-08-02 19:02:50 UTC
view on stackexchange narkive permalink

Ich habe ein SQLi auf einer Buddies-Website gefunden. Er meldete es seinen Vorgesetzten und sie erlaubten mir, zusätzliche Tests durchzuführen und die Site zu patchen. Nach Überprüfung der Site war der anfällige Code ein $ _GET. Ich habe einfach intval () hinzugefügt, um die Variable zu überprüfen, ob es sich um eine Ganzzahl handelt. Ich reran sqlmap, w3af und ein paar andere Scanner. Die Löcher schienen geflickt zu sein. War das der richtige Patch? Wenn nicht, wie kann ich ein $ _GET in PHP ordnungsgemäß sichern?

Siehe auch: http://stackoverflow.com/questions/60174/best-way-to-prevent-sql-injection-in-php
Einer antworten:
rook
2012-08-02 19:11:41 UTC
view on stackexchange narkive permalink

Es spielt keine Rolle, ob es sich um $ _GET, $ _POST, $ _REQUEST, $ _FILE oder sogar $ _SERVER handelt. Es ist alles Benutzereingabe und eine mögliche Quelle für einen Angriff. Entscheidend ist, wie die Benutzereingaben verwendet werden. Im Fall von SQL Injection funktioniert das Umwandeln in ein int wie intval () gut. Sie sollten jedoch parametrisierte Abfragen mit einer Bibliothek wie sqli, adodb oder pdo verwenden.

Aber SQL-Injection ist nur ein Problem in den owasp Top 10 und nur ein Problem unter den Tausenden Schwachstellentypen, die von verfolgt werden CWE-System. Es gibt keinen Zauberstab, um jede Verwundbarkeit zu stoppen.

+1, um zufällige Filtermethoden zu überspringen und direkt zur eigentlichen Lösung zu gelangen: parametrisierte Abfragen.
Parametrisierte Abfragen sind nicht in allen Fällen eine echte Lösung. Sie müssen davon ausgehen, dass der Angreifer möglicherweise die Remote-Shell erhält und trotzdem Abfragen ausführen kann. Der SQL-Identitätswechsel ist eine echte Lösung mit parametrisierten Abfragen.
@Andrew Smith Tiefenverteidigung ist eine Sache, aber ich denke, Sie haben mich hier verloren. Vielleicht sollten Sie eine Frage zum SQL-Identitätswechsel als offene Debatte mit security.se stellen.
@Andrew Smith Es ist nicht einfach, eine Shell durch SQL-Injektion zu erhalten. Unter MySQL können Sie keine Abfragen stapeln, und Sie haben nicht MS-SQLs "xp_cmdshell ()". MySQLs "into outfile" kann in einigen Fällen zu einer Shell führen, aber das mysql-Benutzerkonto benötigt "file_priv".
Parametrisierte Abfragen sind eine Möglichkeit, einen Kompromiss zu verhindern. SQL-Abfragen sind jedoch nur ein Ort, an dem eine Logikschicht Daten schreiben kann (Protokolle, HTML, andere Datenbanken, Dateien ...). Das Problem ist, dass gebundene Parameter datenbankspezifisch sind - und nur über bestimmte APIs. Ich schlage nicht vor, dass alle Daten in einem transport- / speicherneutralen Format codiert werden sollten - vielmehr ist das explizite Entweichen der dem Ziel entsprechenden Ausgabe eine generische Lösung für Injection-Schwachstellen. Als architektonischer Ansatz bietet es ein konsistentes Muster für die Implementierung von Code.
@Rook Oh ja, aber es ist einfach, eine PHP-Shell zu erhalten, und dann ist es einfach, Abfragen auszuführen und die Daten zu kompromittieren, und PDO schützt die Datenbank nicht davor.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...