Sicheres PHP

[cloidnerux]

Aber wo ist das Sicherheitsrisiko, wenn man das Passwort in die Session speichert?

Das die Session relativ unsicher gegen angriffe ist.
Und wenn du das Passwort in die Session einträgst, und jemand liest sie aus, dann aht er das Passwort.
Wenn das ganze jezt z.B bei einem InternetShop wäre, könnte sich der Hacker/Cracker als der Nutzer anmelden, auf seinen namen Sachen bestellen und zu sihc liefern lassen, auf kosten den Users -> ganz schlecht.
Desswegen sollte man die Passörter nur verschlüsselt abspeichern als md5 oder so.

[Dominik]

naja md5 ist wohl nicht das wahre .... es sei den die user haben ein gescheites pw

aber passwörter wie "computer" kann man ja schon knacken bzw besser gesagt vergleichen und ausgeben

[Dubbel]

Das Passwort läuft ständig - eventuell unverschlüsselt - über die Leitung?
Es liegt unverschlüsselt auf der Festplatte?

Aber es liegt ja auf der Festplatte des Servers. Die Session ist ja nur der Code, der berechtigt, diese Datei zu öffnen. "In" ihr wird ja quasi nichts gespeichert...nur in der dazugehörigen Datei auf dem Server eben...

Und wenn du das Passwort in die Session einträgst, und jemand liest sie aus, dann aht er das Passwort.
Wenn das ganze jezt z.B bei einem InternetShop wäre, könnte sich der Hacker/Cracker als der Nutzer anmelden, auf seinen namen Sachen bestellen und zu sihc liefern lassen, auf kosten den Users -> ganz schlecht.

Ob nun jemand die Sessionid für die Datei auf dem Server hat, in der ein Code gespeichert ist, der vollen Zugriff gewährt, oder in der das Passwort gespeichert ist, das vollen Zugriff gewährt, ist doch egal?!

Desswegen sollte man die Passörter nur verschlüsselt abspeichern als md5 oder so.

Das auf jeden Fall. Besser vielleicht crypt oder wenigstens md5 mit salt.

[Dominik]

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

Web-spezifische Maßnahmen
Es sollte sicher gestellt werden, dass die entsprechende Webanwendung nicht anfällig für Cross-Site Scripting ist, da dies vermutlich eine der Hauptmethoden von Angreifern ist, um per Javascript das Objekt document.cookie auszulesen und somit die Sitzung zu kapern.

Sagen wir du hast irgent wo kein htmlsepzialchars drinnn dann kann er ein js ausführen und liest so deine sessionid aus , und verändert deine und geht mit dieser bei dir rein , wenn du da nun das pw in einer session drin hast, hast du verloren wenn nur ein code drin ist kann er ja damit nix anfangen bzw kann er nur schaden wärend einer sitzung anstellen

m,fg

[Dubbel]

Sagen wir du hast irgent wo kein htmlsepzialchars drinnn dann kann er ein js ausführen und liest so deine sessionid aus , und verändert deine und geht mit dieser bei dir rein , wenn du da nun das pw in einer session drin hast, hast du verloren wenn nur ein code drin ist kann er ja damit nix anfangen bzw kann er nur schaden wärend einer sitzung anstellen

Er kann aber die Dateien, die mit der Session verknüpft ist, nicht auslesen. Und wenn er die Session hat, kommt er auf jeden Fall rein, egal ob ja jetzt ein Code den Zugang freigibt oder ein Passwort. Natürlich sollte man jede Session auf ihre Gültigkeitsdauer kontrollieren usw..

[hackmack]

Man könnte die Session aber aber auch wieder mit der IP verknüpfen. So wird beim Aufrufen der Seite mit der jeweiligen Session-ID geprüft, ob in der Session die gleiche IP gespeichert ist mit der die Anfrage kommt.

[Dominik]

das ist klar nur ist das ne zusätzliche sicherheit wenn er drin ist ud sowas wie $_SESSION auslesen kann (lücke) hat er eben das pw

mfg

[cloidnerux]

Er kann ein Script einschleusen, das die Sesion auslesen kann. Wenn dort das PW drinn steht, kanne r sihc als der Nutzer anmelden und schaden anrichten, egal wo er ist.
Wenn das Passwort in einer Datenabnk verschlüsselt auf dem Server liegt, nutz ihm das nicht viel, denn jezt muss er es entschlüsseln.
Wenn das passwort nciht gerade "aaaaaaaa" ist, dauert das Entschlüsseln 1-60 Tage, bei einem 8 Stelligen PW.
Da man durch md5, crypt oder sontige hoffentlch cniht auf die Passwortlänge schließen kann, muss er einen Suchlauf von Passwortlänge 1 beginnen.
Bis er dann mal bei 8 Stellen ankommt, sind 100 Tage vergangen->vlg. es lohnt sich nicht.

[Dubbel]

Er kann ein Script einschleusen, das die Sesion auslesen kann.

Als Nutzer anmelden könnte er sich dann aber doch auch, wenn in der Session nur ein generierter Code steht.

Wenn dort das PW drinn steht, kanne r sihc als der Nutzer anmelden und schaden anrichten, egal wo er ist.

Die Session verschlüsselt ja nicht die Daten in sich selbst, sondern ist nur ein von PHP generierter Code, der dem PHP-Script den Zugriff auf eine Datei auf dem Server ermöglicht. In der Session steht nichts, da kann man nichts auslesen, wenn man nicht ein PHP-Script auf dem gleichen Server ausführen kann (wenn man das kann, hat man eh keine Chance mehr).

Wenn das Passwort in einer Datenabnk verschlüsselt auf dem Server liegt, nutz ihm das nicht viel, denn jezt muss er es entschlüsseln.
Wenn das passwort nciht gerade "aaaaaaaa" ist, dauert das Entschlüsseln 1-60 Tage, bei einem 8 Stelligen PW.
Da man durch md5, crypt oder sontige hoffentlch cniht auf die Passwortlänge schließen kann, muss er einen Suchlauf von Passwortlänge 1 beginnen.
Bis er dann mal bei 8 Stellen ankommt, sind 100 Tage vergangen->vlg. es lohnt sich nicht.

Das Passwort liegt ja verschlüsselt auf dem Server. Ich habe es ja erst nach einer (zugegebenermaßen normalen) md5-Verschlüsselung in die Datei geschrieben, die durch die Session aufgerufen werden kann (wenn man das so ausdrückt, klingt dass nicht so, als könnte man in einer Session Daten so wie in einem Cookie speichern).

Aber ich denke diese Diskussion kann noch ewig weitergehen, da man nie alle Sicherheitsrisiken absolut ausschalten kann. ^^

[hackmack]

das ist klar nur ist das ne zusätzliche sicherheit wenn er drin ist ud sowas wie $_SESSION auslesen kann (lücke) hat er eben das pw

mfg

hmmm...dazu müsste der user doch eigentlich eigenen php-code einschleußen können, um eine $_SESSION Variable auslesen zu können. Wenn man nicht gerade etwas wie eval verwendet, sollte doch sowas eigentlich nicht möglich sein, oder doch?