nicht angemeldet
Hi Thomas!
Was ich mich aber schon laenger frage:
Inwiefern ist dieses Beispiel heute noch praxisrelevant?
Oh - mehr denn je!
Vor allem durch die vielen billigen rootserver Angebote wächst die Zahl der Hobby-Admins, und entsprechend dramatisch sinkt das durchschnittliche Sicherheits-Niveau der Server, das heißt sie werden als Angriffsziele immer interessanter...
Auf einem gut gewarteten und sicher konfigurierten System ist es normalerweise nicht so schlimm wenn ein PHP-Script Sicherheitslücken enthält, weil das normalerweise nicht reichen sollte um wirklich Zugriff auf den Server zu bekommen (Wobei unberechtigter Zugriff und Manipulation von Daten schon mehr als schlimm genug sein kann, nur sind die meisten Angriffe heute nicht so gezielt).
Wenn allerdings Hein Blöd sich nen Root-Server (billiger, geiler, veralteter...) mietet, schön für 19,95 im Monat, darauf findet er dann ein schön altes Suse 8.0 welches im originalen Zustand schon zig böse Sicherheitslücken enthält, ein bisschen mit Confixx rumspielt und dann getreu dem Motte "never change a running system" nichts mehr anfasst um bloß nichts kaputt zu machen, dann natürlich postnuke installiert, am besten noch ne schön alte Version von irgendner Computerbild-CD oder einem veralteten Software-Archiv...
...dann wäre es für das kleine, pickelige, 12-jährige Script-kiddie schon fast unhöflich diese ach so nette Einladung den Server zu übernehmen auszuschlagen...
Aber selbst wenn Dein Server von nem Profi gewartet wird (wovon man im shared hosting auch nicht immer ausgehen kann...), schützt dieser Dich nicht vor Datenverlusten/Manipulationen durch eigene Blödheit.
Gut, bin jetzt ein bisschen vom Thema abgekommen ;-)
SQL-Injection ist eines von vielen Angriffsszenarien, aber Vergleichbares gilt für alle Funktionen die Code in der Shell ausführen(exec() & co.), hierfür gibt es escapeshellarg() und escapeshellcmd() zum escapen, natürlich sollte man nach Möglichkeit gar keine Parameter direkt übergeben, und wenn nur nach ordentlicher Prüfung/Validierung, und natürlich escaped.
Und genauso gilt dasselbe für Funktionen die PHP-Code ausführen, wie include()...
Die ganzen Leute die glauben include() sei der Ersatz für Frames, ich wette die Hälfte von denen reißen sich damit riesige Sicherheitslücken in Ihren Server. Und wenn der dann schlecht konfiguriert/gewartet ist...
AFAIK wuerde bei einem solchen String:
"SELECT * FROM blahr WHERE y = "x"; delete * from geheim where "a" = "a";
der von PHP an MySQL uebergeben wird, doch (wenn ueberhaupt)
nur das erste Statement, also der SELECT-Teil, von MySQL
ausgefuehrt.
(Konkret: PHP 4.3.x, MySQL 3.23.x)
Oder habe ich da etwas falsch im Kopf?
Das stimmt schon, aber man kann auch durch entsprechende Manipulation bei SELECT an Daten kommen die man eigentlich nicht zu Gesicht bekommen dürfte.
So richtig gefaehrlich wird es IMHO doch erst,
wenn man Angaben von der Benutzerseite
direkt in DELETE-Statements einbaut.
Ja, DELETE, UPDATE, kann alles Schaden anrichten wenn man nicht aufpasst. Aber wie gesagt kann auch SELECT Schaden anrichten, wenn auch nicht in Form von Datenverlust, aber eine sensitive Information in falschen Händen kann auch schlimmer sein als verlorene Daten...
Viele Grüße
Andreas