Zur Navigation

Formularabsicherung, mache ich das richtig?

1 Ranma (Gast)

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

17.05.2015 04:14

2 Jörg

Dir geht es vermutlich um eine Absicherung des Formulars gegen XSRF (Cross-Site-Request-Forgery)?

Darum habe ich das Problem so gelöst, daß eine Variable gesendet wird, die zugleich eine SESSION-Variable ist.

Ja, das ist ein sinnvolles Vorgehen.

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?

Nein, die Session wird ja serverseitig gespeichert. Auch die Übertragung des Formulars und die Rückübertragung der Formulardaten verläuft bei einem XSRF-Angriff ausschließlich zwischen Server und User - der Angreifer ist hier vollkommen außen vor. Der Angriff besteht lediglich darin, den User dazu zu bringen, das Formular des Angreifers zu verwenden, welches z.B. in einem Iframe versteckt ist und über ein JavaScript automatisch an dein Formular-Script abgesendet wird. Da der User seine Cookies mitsendet, werden die übertragenen Daten von einem ungesicherten Formular-Script akzeptiert. Wenn dein Original-Formular noch ein in der Session gespeichertes Token mitsendet, welches der Angreifer nicht rekonstruieren kann, kann er das Formular nicht vollständig nachbauen, womit ein XSRF-Angriff nicht mehr praktikabel ist.

18.05.2015 09:41 | geändert: 18.05.2015 09:47

3 Ranma (Gast)

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

19.05.2015 01:21

4 Jörg

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.

Nein. Der User schickt seine Cookies mit, mit welchen er sich gegenüber dem Server authentifiziert. Wenn es sich bei dem User um einen eingeloggten Admin handelt, kann man über eine XSRF-Attacke leicht Vollzugriff auf das Forum, CMS o.ä. erlangen.

19.05.2015 09:20

5 Ranma (Gast)

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

11.06.2015 07:28

6 Jörg

Obwohl ich nicht verstanden habe, wie man eine Session hijacked, soll das relativ einfach sein.

Nur zur Klarstellung: das hat mit XSRF nichts mehr zu tun (bei welchem der Session-Cookie eben nicht gehijacked wird, sondern eine Art Social Engineering zum Einsatz kommt)

Die Session-Hijacking-Methoden sind in diesem Wikipedia-Artikel angerissen:

https://de.wikipedia.org/wiki/Session_Hijacking

Also Man-in-the-middle-Angriff und Cross-Site-Scripting sind hier die Stichworte

Ü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

Im Manual findet sich ein Code-Beispiel:

http://php.net/manual/de/function.session-regenerate-id.php

Also nach session_start()

Viel wichtiger noch ist das Absichern der gesamten Website gegen Cross-Site-Scripting.

Komischerweise dürfen die übrigen Session-Variablen gleich bleiben. Wenn man welche gefunden hat, dann müßte man daran die Session zuordnen können?

Nein. Abgesehen davon: wie soll man die "finden"? die Session-Variablen sind serverseitig gespeichert.

11.06.2015 09:55 | geändert: 11.06.2015 09:59

7 Ranma (Gast)

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

13.06.2015 04:35

8 Jörg

warum bräuchte man dann die Option eine vorherige Session zu erhalten?

Wenn man nur die ID erneuern möchte, weil nur diese von einem Angreifer abgegriffen werden kann, und darüber eine Session gekapert werden kann.

Wenn das Erneuern von Sessions gut ist, dann muß das Abspeichern schlecht sein.

Notwendig zur Abwehr von Session-Hijacking ist nur die Erneuerung der Session-ID.

13.06.2015 17:09

9 Ranma (Gast)

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

18.06.2015 02:49

10 Jörg

Nicht, dass ich wüsste.

Du könntest allenfalls eine JavaScript-Weiterleitung auf eine andere Seite einbauen, auf der du erklärst, dass deine Website nur mit deaktiviertem JavaScript genutzt werden kann, und wie man JavaScript in verschiedenen Browsern deaktivieren kann - dem vermutlich aber nicht allzu viele nachkommen werden :)

18.06.2015 17:05