nicht angemeldet
Hi!
- Ich bin kein "er", sondern eine "sie".
Danke, dass man es Mädchen überhaupt nicht zutraut, sich für was anderes als Puppen zu interessieren. :-)))
Spielt keine Rolle. Fehler bleiben Fehler, egal wer sie macht.
- Da ich PHP-Neuling bin und echte Probleme mit dem Thema Kontextwechsel hatte, war ich frech und habe das meiste aus einem Tutorial kopiert und meinen Ideen angepasst.
Leider legen die Tutorials ihren Fokus mehr auf das Beibrigen von Funktionalitäten der Sprache, aber selten auf eine sichere und robuste Programmierung. Der Anfänger wird sich dadurch nicht bewusst, dass er/sie/es/egal da massive Sicherheitslücken in seine Scripte einbaut.
Hast du den Artikel mittlerweile gelesen und verstanden, dass man beim Einfügen von Daten in Strings, die Code für ein bestimmtes System darstellen, diese Daten so notieren muss, dass sie Daten bleiben und nicht durch nicht beachtete Zeichen zum Code werden?
Zum Thema T_STRING Fehler hatte ich schon einen Tread geöffnet, leider aber keine Antwort bekommen, die mir wirklich weitergeholfen hätte.
Welcher Thread war das denn?
Ach ja, das mit den POST-Werten findest du in jedem Beispiel auf diversen Seiten, anhand dem du dich in PHP einarbeitest.
Ja, das macht es auch nicht besser. Für viele scheinen $_POST und $_GET irgendwelche Monster zu sein, aus denen man möglichst schnell seine Daten rausholen muss, da es sonst Unglück gäbe. Dieses Vorgehen ist jedoch ein Überbleibsel aus der Zeit des Übergangs von register_globals=on zu off. Bei on wurden die $_GET/$_POST-Werte von PHP als einfache Variablen zur Verfügung gestellt und alle schrieben ihre Scripte so, dass sie auf diese Variablen zugriffen. Die einfachste Abhilfe war bei off, faulerweise die Scripte so zu lassen und nur das Umkopieren an den Anfang zu stellen. Und so verbreitete sich eine Unsitte, die ncihts weiter bringt als zusätzliche Variablen, bei denen man sich merken muss, wie sie entstanden sind und die ihre Herkunft verharmlosen. Letzerer Punkt sollte aber weniger von Belang sein, denn der Kontextwechsel muss für alle Daten gleichsam beachtet werden, und nicht etwa nur in einer besonderen Form für Eingabewerte.
Also, was genau soll ich in mein Script noch einbringen? Welche Fehlerfälle sollte ich abdecken?
Ein DBMS ist ein System, das in der Regel auf einem separaten Server läuft, dessen mögliche Ausfälle nicht synchron sind zu denen des Webservers. Deshalb kann zum Beispiel ein Verbindungsaufbau scheitern. In solchen Fällen gibt es keine Fehlermeldung von PHP sondern die mysql(i)-Funktionen geben über den Rückgabewert (=false) bekannt, wenn etwas nicht funktioniert hat. In einem solchen Fall ist es sinnlos fortzufahren, also ob nichts passiert wäre, und munter und froh weitere Befehle gegen das nicht ansprechbare DBMS abzufeuern. Abgesehen davon, dass es nun auch seitens PHP Folgefehlermeldungen hagelt, denn "false" ist keine Ressourcenkennung, die die mysql(i)-Funktionen erwarten. Also: Werte die Rückgabewerte der verwendeten Funktionen aus. Das betrifft jedes Gebiet, nicht nur MySQL. Schau dazu im PHP-Handbuch nach, was die von dir verwendeten Funktionen im Fehlerfall zurückliefern, wie man das gegebenenfalls von positiven Werten unterscheiden kann (Beispiel strpos(): false beim Nichtfinden vs. Integer-0 beim Fund am Stringanfang), und baue Fallunterscheidungen ein.
if ($connection = mysql_connect(...)) {
// weiter im Text
} else {
// Alternativprogramm
}
Das muss man gegebenenfalls mehrfach verschachteln, je nachdem, wieviele Funktionen mit möglichem Fehler-Rückgabewert man verwendet. Zum Alternativprogramm muss man sich vor Augen halten, für wen man das Script überhaupt geschrieben hat. Einen konkretern Fehlermeldungstext auszugeben, bringt dem Anwender nämlich überhaupt nichts. Im Gegenteil könnten nun dir weniger wohl Gesonnene aus den konkreten veröffentlichen Details gezieltere Angriffe starten. Der normale Anwender kann die Ursache des Fehlers nicht beheben und es ist ihm auch egal, wenn da was im Hintergrund nicht richtig gelaufen ist. Er will einfach nur sein Ziel erreichen. Bei einem Verkaufsvorgang ist das auch für den Betreiber der Website wichtig, dem Kunden nun eine Alternative zu bieten, so dass die Bestellung doch noch abgesendet werden kann. In dem Fall könnte man die Bestelldaten vielleicht per E-Mail versenden statt sie im DBMS einzutragen (ganz abgesehen davon, dass schon der Katalog bei DBMS-Problemen nicht erreichbar sein wird).
Mit dem gezielten Beachten von möglichen Fehlerzuständen macht man sein Programm "nur" robust, die Kontextwechsel nicht zu beachten bringt mehr oder weniger schwere Sicherheitslücken in das eigenen System (z.B. Datenbank) und das des Besuchers, wenn jemandem Javascript einschleusen kann, das in Richtung des Besuchers geschickt wird.
Lo!
Auge