Geschützen Bereich schützen...

[Hans Wurst]

Hallo,
ich bräuchte mal wieder Hilfe/Beratung.

Es geht um einen geschützen Bereich eines eShops, in diesem können die Kunden ihre Bestellungen + Lieferdetails (sensible Daten) einsehen.

Nur eingeloggte Kunden dürfen diese Seiten einsehen, d.h. ein direktaufruf der Seite in der Adressleiste soll den Kunden sofort zu der Loginseite umleiten.

Wie soll ich hier am besten vorhen?
Mit Sessions? Cookies?

Mein Ansatz war mit SessionID zu arbeiten, aber irgendwie scheint mir das nicht sicher genug zu sein.

Es ist wirklich wichtig das dieser Bereich gut geschützt ist, für jede Anregung/Vorschlag wäre ich dankbar.

Gruss
Hans Wurst

[ChrisB]

Hi,

Es geht um einen geschützen Bereich eines eShops, in diesem können die Kunden ihre Bestellungen + Lieferdetails (sensible Daten) einsehen.

Nur eingeloggte Kunden dürfen diese Seiten einsehen, d.h. ein direktaufruf der Seite in der Adressleiste soll den Kunden sofort zu der Loginseite umleiten.

Wie soll ich hier am besten vorhen?

Wenn man solche Systeme umsetzt, sollte man wegen sowas eigentlich gar nicht mehr fragen müssen.

Mit Sessions? Cookies?

Mein Ansatz war mit SessionID zu arbeiten, aber irgendwie scheint mir das nicht sicher genug zu sein.

Prüfe, ob der Kunde berechtigt ist, die entsprechenden Daten einzusehen, bevor du sie ihm anzeigst.

MfG ChrisB

[Hans Wurst]

Wenn man solche Systeme umsetzt, sollte man wegen sowas eigentlich gar nicht mehr fragen müssen.

Tja, einmal ist immer das erste mal.
Möchte nur ungern alles neumachen, falls mein Ansatz falsch ist.

Prüfe, ob der Kunde berechtigt ist, die entsprechenden Daten einzusehen, bevor du sie ihm anzeigst.

Soweit habe ich schon vorgedacht, es geht hier um Sicherheit.

Danke trotzdem

[ChrisB]

Hi,

Prüfe, ob der Kunde berechtigt ist, die entsprechenden Daten einzusehen, bevor du sie ihm anzeigst.
Soweit habe ich schon vorgedacht, es geht hier um Sicherheit.

Gut - und welche potentiellen Risiken siehst du, welche Vor- und Nachteile bei welchem Lösungsansatz?

MfG ChrisB

[Bademeister]

Hi Hans Wurst.

Es geht um einen geschützen Bereich eines eShops, in diesem können die Kunden ihre Bestellungen + Lieferdetails (sensible Daten) einsehen.

Nur eingeloggte Kunden dürfen diese Seiten einsehen, d.h. ein direktaufruf der Seite in der Adressleiste soll den Kunden sofort zu der Loginseite umleiten.

"Ein Direktaufruf der Seite in der Adressleiste" - ich ahne, was das bedeuten soll - ist als Kriterium uninterssant. Wenn etwa ueber ein PHP-Session-System der Login verwaltet wird, kann man auch als eingeloggter User "einen Direktaufruf der Seite in der Adressleiste" machen. Und wirklich unterscheiden kannst Du es ohnehin nicht (der HTTP-Referrer spielt hoffentlich bei Deinen Login-Geschichten keine Rolle).

Wie soll ich hier am besten vorhen?

Es sind hier voellig verschiedene Fragen, die im Raum stehen.

Erste Frage: Wie und wodurch willst Du einen eingeloggten User identifizieren?
*Dann erst* die zweite, von Dir schon beantwortete, Frage: Was willst Du tun, wenn ein nicht eingeloggter User die Seite aufruft?

Mein Ansatz war mit SessionID zu arbeiten, aber irgendwie scheint mir das nicht sicher genug zu sein.

Schein ist bei Sicherheitsfragen immer schlecht. Warum ist es Dir nicht sicher genug? Ist Dir eine Session-ID nicht lang genug oder hast Du konzeptionelle Bedenken? PHP-Sessions sind ein probates Mittel, um User ueber mehrere Requests hinweg zu identifizieren.

Es ist wirklich wichtig das dieser Bereich gut geschützt ist, für jede Anregung/Vorschlag wäre ich dankbar.

Da waere es mal interessant zu wissen, wie Dein Login-System aussieht. Kannste mal Code posten?

Gruss

zurueck,
der Bademeister

[Hans Wurst]

"Ein Direktaufruf der Seite in der Adressleiste" - ich ahne, was das bedeuten soll - ist als Kriterium uninterssant. Wenn etwa ueber ein PHP-Session-System der Login verwaltet wird, kann man auch als eingeloggter User "einen Direktaufruf der Seite in der Adressleiste" machen. Und wirklich unterscheiden kannst Du es ohnehin nicht (der HTTP-Referrer spielt hoffentlich bei Deinen Login-Geschichten keine Rolle).

Nein, HTTP-Referrer spielt keine Rolle.
Wenn der User eingeloggt ist und die Seite per Adresszeile aufruft, dann sollte es schon erlaubt sein, auch wenn das Frameset dann nicht mehr vorhanden ist... die Seite bleibt funktional.

Erste Frage: Wie und wodurch willst Du einen eingeloggten User identifizieren?

Genau darum gehts mir ja, ich habe noch keine Ahnung was hier der beste Weg ist.

*Dann erst* die zweite, von Dir schon beantwortete, Frage: Was willst Du tun, wenn ein nicht eingeloggter User die Seite aufruft?

Wenn Frage 1 beantwortet ist, ist Frage 2 keine Frage mehr, dann weiß ich was ich tun soll.

Schein ist bei Sicherheitsfragen immer schlecht. Warum ist es Dir nicht sicher genug? Ist Dir eine Session-ID nicht lang genug oder hast Du konzeptionelle Bedenken? PHP-Sessions sind ein probates Mittel, um User ueber mehrere Requests hinweg zu identifizieren.

Mir fehlt der Ansatz.
Was implementieren und was vergleichen?!

Da waere es mal interessant zu wissen, wie Dein Login-System aussieht. Kannste mal Code posten?

Es gibt noch keinen, das Projekt ist in der Entwiklung.
Heute/Montag wird der PHP Server zur Verfügung stehen, und dann gehts schon los. Aber bis dahin muss das Konzept ja schon stehen, das wäre nicht schlecht.

[Bademeister]

Mir fehlt der Ansatz.
Was implementieren und was vergleichen?!

Na ja, mit PHP waere das Rezept etwas folgendes:

1.: Ein User, der sich einloggen koennen soll, muss erstmal als solcher existieren. Es muessen also die User erzeugt werden (etwa durch eine Registrierung) und die Daten, die Du spaeter brauchst (zumindest Username und Passwort, ggf. Zugangsrechte u.s.w.) gespeichert sein. Das Mittel der Wahl zum Speichern sollte eine Datenbank sein.

2.: Ein User kann sich irgendwie einloggen. Dazu gibt er Usernamen und Passwort in ein Formular ein, und das empfangende Skript prueft die Eingaben durch Abgleich mit den vorhandenen Userdaten. Das kann auf einer eigenen Login-Seite sein, oder ueber ein kleines Formular, das auf jeder Seite - sofern noch nicht eingeloggt - angeboten wird, oder sonstwie. Eine Loesung, die ohne Redirects auskommt, finde ich persoenlich erheblich besser.

3.: Wenn ein User sich eingeloggt hat, dann wird dies durch Setzen eines geeigneten Feldes des $_SESSION-Arrays gespeichert. Dazu muss natuerlich die Session existieren - ob sie erst nach dem Login gestartet wird oder jeder Besucher der Seite gleich eine Session bekommt, haengt davon ab, ob Du fuer nicht eingeloggte Besucher eine Verwendung fuer die Session hast. Dies koennte zum Beispiel der Fall sein, wenn Du eine Sprachauswahl fuer die Website oder andere Einstellungen anbietest, die ueber mehrere Requests erhalten bleiben sollen.

4.: Jedes PHP-Skript, das eine Webseite ausgibt, besitzt eine Variable, deren Wert aussagt, ob die Seite fuer nicht eingeloggte Besucher zugaenglich sein soll oder nicht. Ggf. etwas detaillierter, welche Zugangsrechte zur Einsicht noetig sind. Und eine Funktion, die bei jedem Skript zu Beginn aufgerufen wird, gleicht diese Bedingungen mit dem Loginstatus in der Session ab und entscheidet, ob der User berechtigt ist, die Seite zu sehen. Wenn die Antwort "Nein" ist, dann muss es entprechend reagieren: Eine Meldung, dass der Zugang verweigert wurde, ein Redirect zu einer Login-Seite oder gleich die Ausgabe eines Login-Formulars o.ae. Und ausserdem verhindern, dass der Rest der eigentlichen Seite ausgegeben wird.

Viele Gruesse,
der Bademeister