nicht angemeldet
Tach!
wie kann man am besten seine eigene Seite vor einem Hack schützen.
Das ist so eine Frage des Typs "Ist das sicher?" Diese kann man nicht beantworten ohne die Gegenfrage: "Sicher wovor?" Ist ein Haus sicher, wenn die Tür abgeschlossen ist? Ja und nein. Es kann sicherlich nicht auf einfache Weise durch diese Tür betreten werden, aber es lässt sich ein Fenster einwerfen, durch das man hineinkommt. Willst du das Haus sicher bekommen, musst du dich über die möglichen Einbruchsszenarian informieren und dagegen Gegenmaßnahmen erstellen. Und du darfst kein Szenario übersehen.
Mit Software funktioniert das prinzipiell nicht anders. Gegen Lücken im nicht von dir geschriebenen Code kannst du meist nicht viel ausrichten, außer aktuelle Versionen installieren und ein Auge auf den diversen Informationsquellen haben, die über Lücken und deren Gegenmaßnahmen berichten. Bei deinen eigenen Code fängt es wie beim Haus dabei an, die möglichen Szenarien zu kennen, die genutzt werden können. Dazu darf man ruhig auch selbst mal versuchen, die Lücken im eigenen Code herauszufordern. Das ist ein sehr wichtiges Prinzip: Wenn du deinen Gegner aufhalten willst, musst du wissen, was der alles kann oder könnte. Und man kann sehr viele Dinge (an seinen eigenen Testgeräten und -installationen) ausprobieren, ohne gleich kriminell zu werden. Also hab keine Angst davor.
Bei SQL mache ich bereits überall real_escape_string, aber wie sieht es bei PHP aus, wenn zum Beispiel der User eine Suchmaske hat, und die Variable dann an das PHP Skript übergeben wird.
Kontextwechsel beim Ausgeben beachten, hat Auge ja schon erwähnt. Das dient dazu, dass Code nicht als Code interpretiert wird, sondern als harmlose Zeichen ausgegeben werden.
Benutzereingaben landen schon seit einer Weile nur noch in wohldefinierten Variablen ($_GET/$_POST/...). Das automatische Anlegen von Variablen ist nur in Versionen kleiner 5.4 enthalten, und da schon seit langem nicht mehr per Default aktiviert. Aber auch das war kein großes Thema, solange man sich an den Grundsatz hielt, Variablen vor dem ersten Lesen erstmal einen initialen Wert zuzuweisen.
Man sollte sich auch nicht zu sehr auf "Benutzereingabe" versteifen. Daten können auch aus anderen Quellen kommend ungewünschten Inhalt haben. Man sollte lieber sämtlichen Daten misstrauen, die man nicht als konstanten Wert im Script stehen hat. Und das heißt ganz allgemein gesagt, dass man die Daten auf den eingehaltenen erwarteten Wertebereich prüft, bevor man irgenwelche Aktionen basierend auf ihrem Inhalt anstellt. Um nur mal zwei Beispiele zu nennenm die mir spontan einfallen:
Öffnen Datei x, wenn x sich aus einer andere Quelle ergibt? Prüfen ob der Pfad nach Auflösung aller relativen Bestandteile auf das Verzeichnis zeigt, in dem die Anwendung lesen darf.
Einladen des Teils y in die Ausgabe? Erstmal schauen, ob y in der Liste der erlaubten Teile steht.
dedlfix.
Auge