Warum hat der Schutz vor SQL-Injection keine hohe Priorität?

Beim Stack Overflow sehe ich eine Menge PHP-Code in Fragen und Antworten, die MySQL-Abfragen enthalten, die für SQL-Injection-Angriffe sehr anfällig sind, obwohl grundlegende Problemumgehungen seit mehr als einem Jahrzehnt weit verbreitet sind.

Gibt es einen Grund, warum diese Arten von Code-Snippets heute noch verwendet werden?

Ich denke, es liegt hauptsächlich an a) Unwissenheit b) Faulheit. Anfänger wissen normalerweise nicht viel über SQL Injection, und selbst wenn sie davon hören, ignorieren sie es, weil es so viel einfacher und einfacher ist, auf diese Weise zu programmieren.

Mit PHP ist es für Leute, die nur sehr wenig wissen, sehr, sehr einfach, nützliche dynamische Webseiten zu erstellen. Dies bedeutet, dass PHP viele Anfänger anzieht, die etwas Nützliches erstellen, aus anderen nützlichen Beispielen lernen und sich umdrehen, um anderen beizubringen, wie man diese coole, nützliche Sache macht. Das Ergebnis ist eine Menge schlechter Code und eine Menge Programmierer, die es nicht besser wissen.

Es macht die Sache nur noch schlimmer, dass ein großer Teil der kompetenten Programmierer nichts mit PHP zu tun haben möchte. Dies reduziert die Basis erfahrener Leute, die bereit sind, andere besser zu unterrichten. Aber warum vermeiden sie PHP? Gut für eine Kombination von Faktoren. Zum Teil mögen sie es nicht, mit den Sprachwarzen umzugehen. Zum Teil liegt es daran, dass sie es vorziehen, mit gutem Code zu arbeiten, und es gibt nicht viele gute PHP-Programme.

Diese exakte Konstellation von Problemen verursachte Perl. Als leuchtendes Beispiel sei der Fall von Matt Wright genannt, einem begeisterten Teenager, der bereits in den 90er Jahren viele nützliche, gut dokumentierte und einfach zu installierende CGI-Skripte zur Verfügung stellte. Leider verstand er nichts von Sicherheit und die Leute, die seine Sachen benutzen wollten, auch nicht. Das Ergebnis war das Matt Wright Script Archives, das eine endlose Reihe von Sicherheitsproblemen für frühe CGI-Skripte darstellte. Trotz Bemühungen wie http://www.scriptarchive.com/nms.html verbesserte sich das Problem für Perl erst, als Shared Hosting-Anbieter PHP komfortabler machten als alles andere. Dies führte zu dem Problem, von Perl auf PHP umzusteigen.

Leider gibt es Unmengen von mehr als schlechten PHP-Tutorials, und einige ältere PHP-Bücher haben es ebenfalls vermasselt, die Leute anzuweisen, richtigen Code zu schreiben (ohne register_globals usw.).

magic_quotes_gpcDa es in der Vergangenheit aktiviert wurde , war es den Leuten außerdem egal, ob sie entkommen konnten, weil "es einfach funktionierte".

Persönlich glaube ich, dass PHP einfach zu bedienen ist, also ist es natürlich leicht zu missbrauchen.

Als Mensch und Programmierer fällt es mir bemerkenswert leicht, Fehler zu machen und bestimmte Dinge zu übersehen, besonders wenn ich unter Zeitdruck stehe.

Es ist leicht und vielleicht zu verlockend, eine bestimmte Sprache dafür verantwortlich zu machen, dass sie zu leicht zugänglich ist. Aber das würde das größere Problem der menschlichen Fehlbarkeit beschönigen, unabhängig von der Sprache, in der programmiert wird.

Zugegeben, wir haben seit der Assemblersprache einen langen Weg zurückgelegt, und ich denke, dass ich in einer moderneren Sprache wie PHP, Python, Ruby oder Java viel produktiver programmieren würde.

Tatsächlich haben PHP (und andere Skriptsprachen) die Eintrittsbarriere gesenkt. Das könnte bedeuten, dass immer mehr Programmieranfänger zuerst PHP ausprobieren. Das bedeutet aber sicherlich nicht, dass alle PHP-Programmierer weniger qualifiziert sind oder weniger in der Lage sind, aus ihren Fehlern zu lernen als Programmierer anderer Sprachen.

Rasmus Lerdorf hat PHP bereits 1994 in seiner ursprünglichen Form entwickelt und sich seitdem erheblich weiterentwickelt. In seiner modernsten Version unterstützt es objektorientierte Programmierung sowie hervorragende Frameworks wie Symfony. PHP als Sprache hat sich von seinen ursprünglichen Einschränkungen gelöst und bietet nun eine große Flexibilität bei der Wahl der Programmiersprache. Sie können damit ein Skript mit 9.000 Zeilen Spaghetti-Code erstellen oder es im Kontext eines modernen MVC-Frameworks wie Symfony verwenden: Sie haben die Wahl!

Ich bin der festen Überzeugung, dass Sicherheitslücken nicht auf eine einzige Sprache beschränkt sind. Es ist verlockend, alle PHP-Programmierer als weniger fähig oder anfälliger für das Schreiben von unsicherem Code abzuschreiben. Aber ich frage mich, wie viel davon sprachliche Voreingenommenheit ist und wie viel davon Tatsache?

Ich denke, ein Teil des Problems sind Leute, die einfach Code kopieren, ohne sich die Mühe machen zu lernen, was sie tun, aber meiner Meinung nach ist die Art und Weise, wie wir Porgamnming unterrichten, kaputt und es ist einer der Gründe, warum es so viel schlechten Code gibt. Wir unterrichten Syntax außerhalb des Kontexts, sodass Anfänger nicht wissen, wann sie etwas verwenden und wann nicht oder welche Probleme die Syntax lösen soll und welche Probleme sie nicht lösen soll. SO benutzen sie einen Hammer, wenn ein Schlüssel das bessere Werkzeug gewesen wäre.

Anstatt also nur Syntax zu unterrichten, organisieren Sie den Kurs wie folgt:

1. So richten Sie eine einfache Webseite ein
2. Auf diese Weise veranlassen Sie die Webseite, Daten aus einer Datenbank abzurufen
3. So senden Sie Daten von einer Webseite an eine Datenbank
4. So stellen Sie sicher, dass die richtigen Daten gesendet werden.
5. So schützen Sie Ihre Datenbank vor böswilliger Dateneingabe

Ich denke, Sie werden eine ähnliche Menge an MS SQL + ASP / ASP.NET-Beispielen finden, die genauso anfällig sind.

Ich glaube, das Problem rührt teilweise von der Tatsache her, dass Sie, wenn Sie versuchen, etwas zu lehren, z. B. Daten mit einer WHERE-Klausel zu filtern, Ihr Beispiel wirklich nicht überladen möchten, indem Sie Ihre Abfragezeichenfolge ordnungsgemäß maskieren oder einen parametrisierten Befehl verwenden.

Ich bilde seit vielen Jahren Entwickler aus und kann mich in Leute einfühlen, die schrecklichen Code in Tutorials schreiben. Manchmal ist das am einfachsten zu verstehen. Nebenbei weise ich jedoch immer auf anfälligen Code hin und mache ihn zu einem interessanten Nebenthema.

Der ursprüngliche Autor von PHP, Rasmus Lerdorf , befürwortet in seinem berüchtigten Blogeintrag die "No-Framework" -Entwicklung. Obwohl er für SQL-Abfragen PDO verwendet, besteht kein Risiko einer SQL-Injection. Immer noch ziemlich hässlich und veraltet im Vergleich zu modernen MVC-Frameworks mit ORM-Ebenen.

Sie können PHP selbst die Schuld an dieser schlechten Praxis geben. Ältere PHP-Versionen (bis ca. 2006) würden alle GET- und POST-Eingabevariablen umgehen, damit sie für die Datenbankabfrageinterpolation BY DEFAULT geeignet sind. Siehe http://php.net/manual/en/security.magicquotes.php

Verwechseln Sie nicht den Zweck eines Tutorials, das einfach etwas demonstrieren soll, mit dem, was in einer Produktionsumgebung getan werden sollte. Zum Beispiel hat der meiste Tutorial-Code, den ich geschrieben habe, wenig oder keine Fehler- / Ausnahmekontrolle. Ich versuche den Leser daran zu erinnern, dass der Code nur zeigt, wie man eine bestimmte Aufgabe ausführt, nicht wie man alle möglichen Ergebnisse abdeckt.

Als ich PHP lernte, habe ich mir einige dieser PHP + MySQL-Bücher angesehen, und ja, ich habe das Gefühl, dass es zu dieser schlechten Praxis beiträgt. Aber ich habe Sympathie, weil sie die Sprache unterrichten , nicht gute Programmierpraktiken. Wo würde es sonst enden?