tobi85: PHP vor Hack schützen

Hallo,

wie kann man am besten seine eigene Seite vor einem Hack schützen.

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.

  1. Hallo

    wie kann man am besten seine eigene Seite vor einem Hack schützen.

    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.

    Führe nichts aus, was deinem Skript übergeben wird. Alles, was über ein Formular hereinkommt, ist Text, also erstmal ungefährlich. Soll die Eingabe gespeichert werden, behandle sie, wie du es tust, dem Kontext der Speicherart entsprechend. Sollen die eingegebenen Daten ausgegeben werden, behandle sie nach dem zutreffenden Kontext. Ausgaben in HTML z.B. sind mit htmlspecialchars zu behandeln. Und das grundsätzlich. Lies dazu bitte den Artikel zum Kontextwechsel.

    Ob die eingegebenen Daten überhaupt deinen Erwartungen entsprechen, musst du natürlich nach deren Übergabe an das Skript in diesem prüfen. Du kannst z.B. überprüfen, ob ein Eingabewert eine Zahl ist [1] oder ein Wert aus einer Optionsliste gültig ist oder eine Zeichenkette eine bestimmte Länge hat/nicht übersteigt, was auch immer.

    Tschö, Auge

    --
    Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
    Wolfgang Schneidewind *prust*

    1. Beachte bitte an dieser Stelle,as alles eine Zahl ist. ↩︎

  2. 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.

  3. Hallo,

    wie kann man am besten seine eigene Seite vor einem Hack schützen.

    Nicht online gehen.

    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.

    Bei NIST sich durch die lange Trefferliste bei PHP arbeiten.

    Lese- und Schreibzugriff von PHP auf explizit erlaubte Verzeichnisse begrenzen.

    Da ich PHPfrei lebe, fällt mir aber noch suhosin ein.

    Was nütz einem sicheres PHP, wenn der Server, das Betriebssystem, die anderen Programme und Bibliotheken "Tag der offenen Tür" haben?