Direktaufruf unzugänglich machen
-
Hi,
Ich möchte verhindern, dass bestimmte Seiten direkt aufgerufen werden (z.B. so: www.MeineWebseite.de/KeinIndex.html)Ich hatte überlegt, per PHP nach $_POST und $_GET Variablen zu schauen, aber, zumindest die $_GET Variablen kann man relativ einfach manipulieren.
Gibt es da einen gänigen, sicheren Weg?
Hatte vielleicht daran gedacht, die vorherige Seite zu überprüfen (also von welcher Seite wurde der User weitergeleitet) und je nach dem darauf zu reagieren, aber da könnte man(ein böser User) auch schon wieder spöckes mit treiben.
Cookies wären auch eine Möglichkeit, aber die kann man auch manipulieren^^Danköö
P.S. Man kann das auch im Apache mehr oder weniger einstellen, aber ich wollte es Server unabhänig gestalten
-
Hallo,
Pille456 schrieb:
zumindest die $_GET Variablen kann man relativ einfach manipulieren.
$_POST ist ganz genau so unsicher
Pille456 schrieb:
Gibt es da einen gänigen, sicheren Weg?
Serverauthentifizierung wäre eine Möglichkeit. Da du das aber ausschließt, bleibt dir nur, ein eigenes Authentifizierungssystem zu entwickeln.
Pille456 schrieb:
Hatte vielleicht daran gedacht, die vorherige Seite zu überprüfen (also von welcher Seite wurde der User weitergeleitet) und je nach dem darauf zu reagieren, aber da könnte man(ein böser User) auch schon wieder spöckes mit treiben.
Vergiss das lieber gleich wieder. Nicht nur, dass man leicht den "Referer" fälschen kann, nein, viele Browser (z.B. Opera) bieten noch eine einfache Option, des Datenschutzes halber gar keinen mehr zu senden! Solche Benutzer würden sich überhaupt nicht anmelden können!
Pille456 schrieb:
Cookies wären auch eine Möglichkeit, aber die kann man auch manipulieren^^
Um Cookies kommst du bei einer Autorisierung nicht herum. Du musst halt den Inhalt der Cookies so verschleiern, dass der Benutzer ihn eben nicht mehr ändern kann (sieh dir dazu mal das PHP-Modul mcrypt an ;)). Als sicher gilt z.B. der Blowfish-Algorithmus.
Generell wird meist eine Mischung aus Session- und Cookiesystem gemacht. Die Benutzerdaten werden folglich am Server gespeichert - So kann ein böswilliger Angreifer sie nicht ermitteln -, wohingegen die Session-ID aus einem Cookie stammt, dass z.B. mit oben genanntem Verschlüsselungsalgorithmus verschlüsselt wird.
Dann gibt es noch zwei verschiedene Systeme, die Authentifizierung von Abfrage zu Abfrage aufrecht zu erhalten:
- 1. ein Ticketsystem. Du generierst bei jeder Abfrage eine neue Folge einer Sequenz und speicherst diese in der Session sowie in dem Cookie des Anwenders. Gleichzeitig prüfst du bei jeder Abfrage, ob die vom Benutzer übertragene Folge gleich derjenigen ist, die du beim letzten Zugriff in der Session gesichert hast. Ist sie gleich, wird der Benutzer authentifiziert. Andernfalls verweigerst du den Zugriff.
- 2. und performancetechnisch sinnvoller, jedoch nicht ganz so sicher, ist ein Zeitsystem: Nach dem Login setzt du das Cookie einfach auf ein bestimmtes Verfallsdatum, nach welchem der Login ungültig wird.
Das Thema ist allerdings äußerst kompliziert! Für deine Zwecke dürfte eine serverseitige Authentifizierung nicht nut leichter einzurichten sondern auch sicherheitstechnisch die bessere Wahl sein. Ansonsten - falls dich das Thema interessiert - schau dir doch mal dieses Buch hier an:
PHP-Sicherheit | ISBN: 3898644502Willst du hingegen ganze Verzeichnisse schützen oder Dateien, die nicht durch den PHP-Parser gejagt werden, so wirst du um eine serverabhängige Lösung nicht herum kommen (unter Apache: Stichwort .htaccess)
-
Das mit dem verfallenden Cookie wollte ich aufjedenfall einbauen. Doof ist nur, dass wenn der User ganz rechtmäßig surft er nach z.B. 30min gekickt wird. Damit das nicht passiert müsste ich bei jeder Skript ausführung/Seiten wechsel etc. den Cookie ändern, damit die Zeit wieder zurück gesetzt wird. Das heißt, wenn es keine einheitliche Schnittstelle (einen Codeteil der IMMER ausgeführt wird) gibt, was ich auch bezweifel, gibt es unübersichtlichen Code oder ein User unter Zeitdruck.
Zum Direktaufruf:
Das Problem mit den Cookies wäre, dass ich 3Seiten haben, die hintereinander abgerufen werden müssen. Wenn ich mich nun aber einloggen, dann kann ich ja alle 3 Seiten direkt aufrufen. Das hieße dann, dass ich für jede Seite einen Cookie anlegen müsste bzw. bei jeder Seite die Cookieinformationen ändern müsste (dasselbe natürlich dann auch Serverseitig) oder ?
-
Pille456 schrieb:
Das heißt, wenn es keine einheitliche Schnittstelle (einen Codeteil der IMMER ausgeführt wird) gibt, was ich auch bezweifel, gibt es unübersichtlichen Code
Das verstehe ich jetzt nicht. Du packst das in deine Funktionsbibliothek, die in jedem Skript eingebunden wird, und rufst dann einfach nur noch die Funktion aus jedem Skript auf. Wo ist das Problem?
Pille456 schrieb:
Das Problem mit den Cookies wäre, dass ich 3Seiten haben, die hintereinander abgerufen werden müssen.
Das hat aber mit Benutzerauthentifizierung nichts mehr zu tun, sondern vielmehr sicherstellung einer korrekten Reihenfolge. Du speicherst einfach in jeder Seite einen Wert, der angibt, dass der Benutzer sie besucht hat. In der nächsten prüfst du, ob der Wert korrekt gesetzt ist, und falls nicht, brichst du halt die Skriptausführung ab. Natürlich kannst du hierfür eine eigene Authentfizierungsmethode schreiben ... Aber das wäre, denke ich, etwas übertrieben. Denn prüfen, ob die übertragenen Daten valide sind, musst du ohnehin. Und das sind sie nicht, wenn der Benutzer eine Seite auslässt
-
árn[y]ék schrieb:
Das verstehe ich jetzt nicht. Du packst das in deine Funktionsbibliothek, die in jedem Skript eingebunden wird, und rufst dann einfach nur noch die Funktion aus jedem Skript auf. Wo ist das Problem?
Wie reagiere ich denn auf z.B. Auswahlen in einem DropDown Menü?
Ok, auf dem onChagne="" Ereigniss - aber wenn ich da schon eine Funktion (JavaScript) drauf liegen habe - was dann?Naja der User muss ja auch passend dazu sein - die Daten werde ja gespeichert
Aber mit den Cookies werd ich das schon hibekommen, ist nur die Frage inwiefern sich der Aufwand gegenüber dem Nutzen auszahlt.
-
Pille456 schrieb:
Ok, auf dem onChagne="" Ereigniss - aber wenn ich da schon eine Funktion (JavaScript) drauf liegen habe - was dann?
onchange (kleingeschrieben laut XML-Standard) hat mit PHP absolut gar nichts am Hut
onchange (bzw. alle on*-Attrribute) nützen ausschließlich für clientseitige Skriptsprachen (JavaScript, VBScript etc.).In PHP greifst du - nachdem das Skript abgesendet wurde - auf alle Elemente deines HTML-Form-Tags über die superglobale Variable $_POST zu (vorausgesetzt, deine Übertragungsmethode ist POST, was sie auch sein sollte).
-
Aber wie soll ich dann per PHP schauen, ob sich etwas geändert hat bzw. der User noch "da" ist?
Dann muss ich das mit JS machen oder sehe ich dasfalsch?
-
Pille456 schrieb:
Aber wie soll ich dann per PHP schauen, ob sich etwas geändert hat bzw. der User noch "da" ist?
Dann muss ich das mit JS machen oder sehe ich dasfalsch?Vergiss mal ganz schnell JavaScript, wenn es um Sicherheitsaspekte geht!
Wo genau ist dein Problem? Gucken, ob der Benutzer noch "da" ist, tust du doch implizit, wenn du ihn authentifizierst!?
-
ALso ich meinte das so:
Wenn du z.B. bei amazon.de surfst und sachen suchst und dabei eingeloggt bist, dann kannst du natürlich auch ohen weiter Anmeldung was kaufen - bist ja schon eingeloggt.
Wenn du nun aber 30min nichts auf der amazon Seite gemacht hast, dann wirst du automatisch ausgeloggt.
Ich denke amazon macht das mit cookies (kann man ja leicht nachsehen), aber wie (bzw. ehr wo und wann) ändert amazon das Verfallstdatum des Cookies beim Surfen?
-
Mein momentaner Amazon-Cookie ist noch bis zum 3.7. gültig. Die Cookies scheinen dort also eine Laufzeit von etwa einer Woche zu besitzen. Vermutlich wird das Cookie irgendwann dann erneuert, wenn eine bestimmte Zeitspanne vor dem Verfallsdatum erreicht ist. Zudem legt Amazon allerdings auch zwei weitere Cookies bei mir an, die jeweils bis 2036 gültig sind.
Wie genau die Authentifizierung bei Amazon funktioniert, wird dir letztendlich niemand sagen können.
-
Na dann nehme ich alles zurück!
Ich bastel dann mal an den Cookies rum, danke für die Anregungen