Formularabsicherung, mache ich das richtig?

Leider muß ich nochmal ein Thema eröffnen, weil ich mir nicht sicher bin, ob ich meine Formulare richtig absichere.

Also ein Formular wird vom Skript an den Client geschickt und von dort wieder zurück. Dazwischen kann ein Angreifer ein Formular beliebig manipulieren. Dagegen soll es helfen, eine geheime Variable mitzuschicken, anhand derer man (also das Skript) überprüft, ob das zurückbekommene Formular auch das zuvor gesendete ist. Der eigentliche Trick dabei ist wohl keine Konstanten zu verwenden, weil ein Angreifer die dann einfach wieder einsetzen könnte.

Nun ist es ja so, daß ein PHP-Skript sich schon beim zweiten Aufruf nicht mehr an Variablen aus dem ersten Aufruf erinnert. Den über das Formular gesendeten Wert bekommt das Skript per POST-Variable zurück. Der Teil ist kein Problem. Außer natürlich, falls es einem Angreifer schon ausreichen würde, den Wert auszulesen. Nur der Wert mit dem das Skript vergleichen muß, der ist futsch. Darum habe ich das Problem so gelöst, daß eine Variable gesendet wird, die zugleich eine SESSION-Variable ist.

Einerseits funktioniert das so. Aber andererseits könnte ich mir auch vorstellen, daß sich nun dem Fachmann die Zehennägel hochrollen, weil auch eine Sitzung angegriffen werden kann. Übermittle ich so einem Angreifer die Daten, die zu einem Angriff benötigt werden?

Falls meine Lösung nichts taugt, wie speichere ich die Sicherheitsvariablen dann (mal wieder in einer Datenbanktabelle?) und wann sollte ich die Werte ändern?
Ranma

Endlich habe ich mal etwas einfach so richtig gemacht! Aus dem Link zur Wikipedia habe ich dann gleich noch gelernt, daß ich den Referrer-Header nicht für Sicherheitsüberprüfungen verwenden soll, womit ich allerdings meine GET-Variablen abzusichern dachte.

Zwar verstehe ich nicht so ganz, warum man bei XSRF zwischen Angreifer und User unterscheidet, obwohl man garnicht wissen kann, ob ein Angreifer sein Formular jemand anderem unterschiebt oder es gleich selbst sendet. Der Effekt sollte der gleiche sein. Aber wenn das üblicherweise mit SESSION-Variablen gemacht wird, dann funktioniert das sicher und es ist alles gut.
Ranma

Ja, der User schickt seine Cookies mit. Genau darin, das habe ich jetzt nochmal nachgelesen, findet man die Session-ID. Falls jemand meine Session-ID will, dann muß er meinen Cookie verwenden. Obwohl ich nicht verstanden habe, wie man eine Session hijacked, soll das relativ einfach sein. (Auch betreffs des Absicherns von Formularen hatte ich mir nur gemerkt, daß man das machen muß.) Wenn man einfach an eine Session-ID kommt, dann befürchtete ich, daß man genauso einfach an die Session-Variablen kommt.

Ich finde es halt merkwürdig und rätselhaft, daß sich PHP einerseits keine Variablen merken kann, andererseits offensichtlich für den Session-Array einen Speicherplatz hat, mit dem das doch geht.

Übrigens habe ich mir auch zum Session-Hijacking nur gemerkt, daß man dagegen mit dem Regenerieren der Session-ID vorgehen muß. Dafür suche ich noch die richtige Stelle in meinem Skript. Komischerweise dürfen die übrigen Session-Variablen gleich bleiben. Wenn man welche gefunden hat, dann müßte man daran die Session zuordnen können? (Jedenfalls war noch irgendetwas mit Variablennamen so wählen, daß sie nicht erraten werden können....)

Zirka drei Viertel der Zeit, die ich auf mein Skript verwende, suche ich nach Fehlern. Ich ahne nun, daß mich die Sicherheit schließlich nochmal so lange beschäftigen wird....
Ranma

session_id()?session_regenerate_id():session_start();

ist eigentlich alles, was notwendig ist?
Wieso sind die Beispiele so lang?
Anscheinend wird die vorherige Session nur vernichtet, wenn noch ein Parameter eingefügt wird: session_regenerate_id(true);
Ohne den Parameter bleiben die Session-Variablen erhalten, liegt das an der Erhaltung der vorherigen Session und verschwinden die Session-Variablen durch den Parameter TRUE?
Oder bleiben die Session-Variablen auf jeden Fall erhalten? Aber in dem Fall, warum bräuchte man dann die Option eine vorherige Session zu erhalten?

Völlig verwirrt bin ich, wenn ich lese, daß manche sogar Sessions in Datenbanken abspeichern. Wenn das Erneuern von Sessions gut ist, dann muß das Abspeichern schlecht sein. Also wieso würde man so etwas tun?

Gegen XSS sollten htmlentities() und die Überprüfung jeder Eingabe mittels Regulären Ausdrücken helfen. Die Schwierigkeit dabei ist eigentlich nur an obskure Eingabewege zu denken. In meiner Recherche für meine Sprachweiche habe ich ein Beispiel gefunden, das Schadcode über $_SERVER[HTTP_ACCEPT_LANGUAGE] einschleust. Darauf wäre ich nie gekommen, wenn ich nicht zufällig das Beispiel entdeckt hätte!!
Ranma

So weit scheinen erstmal alle Fragen zur Sicherheit geklärt zu sein. Danke dafür. Vielleicht eines noch:

Manche Angriffe funktionieren wohl über JavaScript. Mit JavaScript (von dem ich eigentlich die Finger lasse, weil es zu kompliziert ist) kann man noch weitere nervige Sachen machen wie eine Netzseite in die Bookmark-Liste aufzunehmen oder sie sogar zur Voreinstellung zu machen. Trotzdem lassen sehr viele Leute JavaScript eingeschaltet. Wenn sie sowieso alles mit sich machen lassen... Gibt es vielleicht einen JavaScript-Befehl, um JavaScript abzuschalten?
Ranma