Kundenbereich: wie richtig schützen?

[rw1981]

Hallo zusammen,

ich hoffe Ihr könnt mir hier ein wenig helfen.

Es geht um einen geschützen Bereich auf einer Website, in den sich Kunden einloggen und dort Preisinformationen einsehen können.
Da alle Kunden unterschiedliche Preise haben, hat jeder Kunde einen anderen Login. Die Preisinformationen sind streng vertraulich.

Wie beurteilt Ihr mein Vorgehen:
a) Ich würde eine MD5-verschlüsselte Datenbank einrichten, die die Zugangsdaten der Kunden enthält.
b) Mit Hilfe von Sessions würde ich dafür sorgen, dass jeder Kunde ausschließlich die für Ihn bestimmte Seite angezeigt bekommt.


Genügt das oder muss ich noch etwas beachten?
Braucht man für so etwas https bzw. SSL-Verbindungen?


ICH DANKE EUCH FÜR EURE HILFE!!!

lg

 

[Zampano_]

AW: Kundenbereich: wie richtig schützen?

Innerhalb deines Systems reicht das wohl. Denke daran deinen DB-Zugang vor Zugriffen von aussen zu schützen indem du ihn am besten aus dem Document-Root auslagerst.

https benötigst du wenn du die Verbindung vom Server zum Client sichern möchtest und das Abfangen der übertragenen Daten verhindern willst. Ist imo an dieser Stelle nicht wirklich nötig, es sei denn der Kunde kann bei dir auch Zahlungsdaten (Kreditkarte, Kontonummer etc) angeben. Dann ist https ein "Muss".

 

[Duddle]

AW: Kundenbereich: wie richtig schützen?

b) Mit Hilfe von Sessions würde ich dafür sorgen, dass jeder Kunde ausschließlich die für Ihn bestimmte Seite angezeigt bekommt.

Session Hijacking – Wikipedia


Duddle

 

[Zampano_]

AW: Kundenbereich: wie richtig schützen?

... kommt halt darauf an wie sensibel (bzw für Dritte interessant) die Daten sind, die übertragen werden.
Cross-Site-Scripting sollte ja eh unterbunden sein indem man mit den Eingaben von "aussen" ordnungsgemäß umgeht. Stichwort htmlspecialchars() und mysql_real_escape_string() (gegen sql-injection)

Cheers

 

[Robbyn-]

AW: Kundenbereich: wie richtig schützen?

Alle wichtigen Eingaben der Benutzer sollten überprüft werden, Hacker sollten bei SQL-Injectionen und Cross Site Scripting auf Granit stoßen.

Remote Code Execution sollte auch nicht möglich sein. Als Beispiel wäre es problematisch, wenn Skripte externe Dateien über beispielsweise über require(), include(), fopen() etc. einbinden und der entsprechende Pfad von extern (z.B. bei register_globals=on) beeinflusst werden kann. Dann braucht ein Angreifer den Schadcode der zur Ausführung gelangen soll nicht auf den angegriffenen Server bringen, sondern kann ihn direkt aus dem Netz heraus einbinden.

Dann gibt es natürlich noch die Sicherheitslücken auf den Servern. Die PHP Konfiguration kann direkten Einfluß auf die verschiedensten Angriffsvarianten haben, schlecht konfigurierte Systeme ermöglichen darüberhinaus Angreifern oftmals sehr umfangreiche Möglichkeiten. Leider sind in der Grundinstallation viele "Sicherheits-Optionen" falsch gesetzt und werden vor dem produktiven Einsatz nicht kontrolliert.
Einige der wichtigsten Konfigurationseinstellungen im Überblick:

* register_globals (off seit PHP 4.2, optimale Einstellung: off)
* allow_url_fopen (on in der Grundeinstellung, optimale Einstellung: off)
* magic_quotes_gpc (on in der Grundeinstellung, optimale Einstellung: off - siehe auch magic_quotes_gpc und SQL-Injektion)
* magic_quotes_runtime (off in der Grundeinstellung, optimale Einstellung: off)
* safe_mode and open_basedir (nicht aktiv in der Grundeinstellung, kann - falls richtig konfiguriert - aktiviert helfen, Risiken zu minimieren.)


Dann gibt es leider noch den Angriff durch Dateisysteme. Da gibt es eine Reihe an Möglichkeiten durch Angriffe auf das Dateisystem Schaden anzurichten, insbesondere in Shared-Hosting-Umgebungen:

* Anzeige von Serverdaten (wie /etc/passwd, Konfigurationsdateien oder Logs)
* Angriffe auf Session-Daten (normalerweise in /tmp)
* Datei-Upload-Angriffe (z.b.bei unvalidiertem Avatar oder Dateiupload)

Da viele Provider darüberhinaus PHP mit dem Benutzerkonto "nobody" beim Apache gestartet haben, können Angriffe auf das Dateisystem oftmals den gesamten Server und nicht nur eine einzelne Präsenz betreffen.

Deswegen immer Benutzer eingaben sorgfälltig überprüfen.

SQL-Injection:

mysql_real_escape_string($variable)

oder mithilfe von mysqli ... soweit es dir natürlich möglich ist ... kannst du mithilfe von Prepared Statements SQL Injectionen besser abfangen.

Variablen immer überprüfen:

$wert = trim(htmlspecialchars(str_replace(array("\r\n", "\r", "\0"), array("\n", "\n", ''), $wert), ENT_COMPAT, 'UTF-8'));

wobei Wert deine Variable ist die du übergeben willst, bist du so immer auf der sicheren Seite.

Ich hoffe ich konnte dir damit weiterhelfen.

MfG.Robbyn

 

[saila]

AW: Kundenbereich: wie richtig schützen?

Hi,

rein md5 als Verschlüsselung zu verwenden ist nicht mehr aktuell, da es bereits Listen mit md5 Schlüsseln gibt. Auch die 32 Stellen sind immer fix und somit letztlich nicht mehr sicher. Der aktuelle Standard für einen Login ist entweder md5 + salt. Ich selbst verwende kein md5 mehr, sondern einen anderen Verschlüsselungsalgorythmus + salt. Die Session sollte ausschl. per Cookie laufen und nicht per url.

Letztenendes muss CrossSiteScripting unterbunden werden und mysql_real_escape_string als Mindestanforderung enthalten sein.

 

[rw1981]

AW: Kundenbereich: wie richtig schützen?

Hey Leute,

ich danke euch vielmals für Eure Mühe!
Ich muss das allerdings erst mal verdauen und mich durch eure Tipps wühlen bzw. einlesen.

Ich melde mich danach nochmal.

DANKE NOCHMAL und lieben Gruß