unbefugten Zugriff durch URL-Manipulation verhindern

[GoaSkin]

Sobald man ein Web erstellt, bei dem mehrere Benutzer unterschiedlich eingeschränkten Zugriff haben sollen, hat man das Problem, dass ein eingeloggter Benutzer versuchen könnte, durch die Manipulation von Parametern in der URL versuchen könnte, an Daten zu erlangen, die nicht für ihn bestimmt sind. Je komplexer das Web wird, desto schwieriger wird es, über die eigenen Skripte sicherzustellen, dass jemand im Falle einer manipulierten URL keine Daten angezeigt bekommt, die nicht für ihn bestimmt sind.

Bei diversen Tipps zum Apache-Webserver wird empfohlen, das MOD_REWRITE einzusetzen und darüber dafür zu sorgen, dass der Benutzer im Falle eines Direkt-Zugriffs immer auf die Startseite umgelenkt wird.

Doch diese Methode ist auch nicht wirklich sicher, da ein Angreifer z.B. sich eine eigene Webseite mit dem entsprechenden Link basteln könnte oder anderweitig dafür sorgen könnte, dass ein URL-Aufruf mit dem richtigen Referer stattfindet, um diese Kontrolle zu umgehen.

Sinnvoll wäre z.B. ein Apache-Modul, dass überprüft, ob die Referer-URL zuvor wirklich von der gleichen IP-Adresse aufgerufen wird. Gibt es ein solches Modul oder etwas Vergleichbares?

[flashpixx]

Hypertext Transfer Protocol

HTTP ist ein zustandsloses Protokoll.

Referrer

Der Referrer ist ein optionaler Teil der an den Webserver geschickten HTTP-Anfrage

[GoaSkin]

Hypertext Transfer Protocol

Referrer

Und?

Deshalb sendet der Browser trotzdem eine REFERER-URL mit, wenn der Benutzer einen Link geklickt hat, den der Benutzer zuvor wirklich auch besucht hat.

Von daher ist es technisch prinzipiell kein Problem, anhand des Logs zu überprüfen, ob der Benutzer mit der selben IP-Adresse zuvor die Seite schon einmal aufgerufen hat, die er als REFERER übergibt.

[flashpixx]

Deshalb sendet der Browser trotzdem eine REFERER-URL mit, wenn der Benutzer einen Link geklickt hat, den der Benutzer zuvor wirklich auch besucht hat.

Das wäre mir neu, wenn ich den Referrer in meinem Browser abschalte wird auch keiner gesendet.

Von daher ist es technisch prinzipiell kein Problem, anhand des Logs zu überprüfen, ob der Benutzer mit der selben IP-Adresse zuvor die Seite schon einmal aufgerufen hat, die er als REFERER übergibt.

Nein, Du irrst. HTTP ist zustandslos und daran ändert sich auch nichts. Eine IP zu Identifizierung reicht nicht aus, wenn z.B. der User über einen Proxy / NAT kommt, dann siehst Du nur die IP des Proxy / NAT im Log. Damit kannst Du nicht mehr die Zuordnung von User zu IP machen.

[SilentDemise]

Es ist auch nicht wirklich elegant, applications probleme über Infrastruktur lösen zu wollen.

Alle anderen machen es doch auch so, dass beim aufruf einer URL die Authentifizierung und die Authorisierung geprüft werden(achtung unterschied!), warum du nicht? wie flashpixx sagt ist der referrer optional, ich würde sogar noch weiter gehen:

wenn du es darüber abfackeln willst, würde mir der fiddler erlauben über manipulierte pakete problemlos deine geschützten Bereiche zu lesen, das ist doch nun wirklich nicht in deinem Interesse, oder? ;-)

[Crash2001]

Dafür gibt es doch Benutzergruppen auf entsprechenden Portalen. Anhand der zugeordneten Gruppe wird vom System bei jedem Aufruf entschieden, ob der User Zugriff auf die Seite haben darf, oder ob nicht. Zusätzlich gibt es dann eventuell noch spezielle Berechtigungen (z.B. wenn man selber der Autor ist). Bei manchen Systemen ist es auch möglich, gleichzeitig Mitglied von mehreren Gruppen zu sein (wenn es in einer Baumstruktur angeordnet ist z.B., jedoch man nicht Rechte für alles haben soll, jedoch für mehrere Bereiche).

Fehlt dir an dem System irgend etwas? Ist es dir zu kompliziert zu überprüfen? (Ist doch nur ein "Baustein", der in jeder Datei einfach eingebunden wird.)

Ich verstehe den Sinn, den Zugriff per URL-Manipulationen zu verhindern hier nicht so ganz, da es doch vollkommen ausreichend ist so. Am besten halt noch mit z.B. per SSL verschlüsselter Kommunikation mit dem Server.

[Systemlord]

Wenn man die URL-Parameter per POST und nicht per GET überträgt, werden sie nicht in der Adresszeile angezeigt und können somit auch nicht manipuliert werden. Abgesehen davon sollte man solche Informationen am besten in einem Session-Objekt o.ä. speichern an das man nur herankommt, wenn man im Speicher herumpfuscht.

[SilentDemise]

POST wird nur nicht in der Adresszeile angezeigt, die Daten stehen aber im Klartext im HTTP Traffic

[Systemlord]

POST wird nur nicht in der Adresszeile angezeigt, die Daten stehen aber im Klartext im HTTP Traffic

Das stimmt. Aber sie lassen sich nicht so einfach manipulieren, wie GET-Variablen. Am sichersten ist aber wie gesagt das Session-Objekt, in dem solche Dinge wie die Benutzer-ID abgelegt werden. Die Benutzergruppe und die einzelnen Berechtigungen sollten am besten eh erst beim Zugriff auf die jeweilige Seite geprüft werden.

[flashpixx]

Aber sie lassen sich nicht so einfach manipulieren, wie GET-Variablen.

Also mit einem Telnetclient kann man das sehr einfach manipulieren: HTTP Post per Telnet

Aber worum soll jetzt hier in dem Thread bitte gehen? Dadurch, dass HTTP nun mal zustandslos ist, habe ich keine Möglichkeit den Benutzer über mehrere Seiten zu identifizieren, d.h. ich brauche eine passende Möglichkeit dafür, wozu man eigentlich Sessions benutzt wie sie z.B. durch PHP zur Verfügung gestellt werden. IP, Referrer, etc sind eben nicht ausreichend.