nicht angemeldet
Ja, sollst du.
Oh, je...
Niemand hat gesagt, dass es einfach wird. Aber ab PHP Version 4.3 gibts auch keine Arrays $HTTP_POST_VARS (usw.) mehr - die Umstellung betrifft also einige Skripte (aber bei denen kann man mit Suchen/Ersetzen einfach umstellen).
Auch du kannst mit Suchen/Ersetzen die im Skript verwendeten Variablen in PHP-kompatible Versionen wandeln. Aber du mußt etwas aufpassen und den jeweiligen Kontext der Operation betrachten. Ausgaben funktionieren beispielsweise auf die alte Art so:
echo "Sie haben $eingabe eingegeben!";
Wenn du $eingabe durch $_POST['eingabe'] ersetzt (so simpel ist das im Prinzip), dann wird diese Zeile eine Fehlermeldung ausgeben. Denn Arrays kann man nicht einfach so innerhalb von Strings ansprechen, sondern muß z.B. geschweifte Klammern drumherumsetzen.
echo "Sie haben $_POST['eingabe'] eingegeben!"; ist falsch
echo "Sie haben {$_POST['eingabe']} eingegeben!"; ist richtig.
echo "Sie haben ".$_POST['eingabe']." eingegeben!"; ist auch richtig
Die letzte Variante benutzt schlichte Stringverkettung für die Ausgabe.
Das Problem ist immer, dass mit register_globals=on der Benutzer Variablen im Skript erzeugen kann, die später unter Umständen nicht initialisiert werden, und dann vorbelegt durch den Angreifer im weiteren Verlauf des Skriptes verwendet werden...
da heißt, er schickt im query-String eine variabel=wert mit?
aber dann muß er doch meine Variablennamen kennen, oder? bzw. 'wird nicht initialisiert' hieße für mich jetzt eine Fehlermeldung, aber die Variable wird im Script doch gar nicht wieder aufgerufen.
Richtig, die Variablennamen müßte er kennen. Aber er kann ja auch gut raten. Meist sind die Namen doch hinreichend trivial gewählt, oder sie tauchen in Formularen und URL-Zeilen auf - daran kann man ja mal testweise herummanipulieren.
"Nicht initialisiert" bedeutet, dass du mitten im Skript plötzlich den Wert einer Variablen benutzt, ohne ihn ihr vorher zugewiesen zu haben. Wenn du das Mörderskript, was ich im Link auseinandergenommen habe, mal genauer durchsiehst: Ganz am Anfang wird eine mySQL-Abfrage durchgeführt, und wenn die Erfolg hat, werden gewisse Variablen auf Startwerte gesetzt. Wenn aber mySQL gerade nicht antwortet, dann werden die Startwerte nicht gesetzt, und eingeschmuggelte Werte wären wirksam.
Bei der Prüfung auf Sicherheit geht es nicht darum, was ein durchschnittlich dummer Benutzer am System anrichten kann, sondern was ein maximal informierter Angreifer anrichten könnte. Ein Skript ist sicher, wenn sich damit nichts außer dem _gewünschten_ Zweck anstellen läßt. Es ist nun leider ziemlich aufwendig, zu beweisen, dass ein Skript sicher ist, deshalb ist leichter zu prüfen, ob möglicherweise undefinierte Systemzustände erreicht werden können, wenn man alle unglücklichen Umstände, die ja theoretisch eintreten können, auch wirklich eintreten. Und wenn man dann in Programmbereiche vorstoßen kann, zu denen man eigentlich gar nicht kommen dürfte, dann ist das Skript unsicher.
- Sven Rautenberg