Forum: PC-Programmierung [PHP] Erzeugen von Session Variablen nicht möglich

PHP-Session-Variablen werden immer serverseitig gespeichert.

Client-seitig sieht man nur das Session-Cookie mit einem Zufallsinhalt, 
das dazu dient, die Session zu identifizieren.

PHP erzeugt schrieb:
> Achso, das wird Serverseitig gespeichert und das was ich sehe ich nur
> das Cookie mit der ID.
> Okay, dann macht es Sinn, dass ich nichts sehe ;)

Das ist auch gut so, denn nur deswegen kannst du in der Session Sachen 
speichern, die
a) der User nicht sehen soll
b) die er nicht manipulieren darf
c) die zu groß sind, um sie mit jedem Request als Cookie hin und her zu 
schicken.

Wenn du in deiner PHP-Anwendung eine Benutzeranmeldung hast, mach dich 
schlau wie Session-Hijacking funktioniert und implementiere folgende 
Gegenmaßnahmen: (natürlich nur wenn es wichtig ist - für die 
Bauteildatenbank zu Hause brauchts das vielleicht nicht.)
* verwende https
* setze die richtigen Cookie-Attribute (mit session_set_cookie_params, 
secure und httponly)
* Bei einer erfolgreichen Anmeldung musst du das session-cookie 
erneuern, d.h. die Session-ID des Anmeldeformulars muss eine andere sein 
als die, mit der du danach angemeldet arbeitest

was aus Security-Sicht auch noch gut wäre:
* ungenutzte Sessions haben einen Timeout
* beim Abmelden werden alle Inhalte zur Session gelöscht

um zur Urpsrungsfrage zurückzukommen:

PHP erzeugt schrieb:
> Weiß jemand warum das so ist?

Das Handbuch weiß es:
https://www.php.net/manual/de/function.session-start.php

>>    Hinweis:
>>    Um Cookie-basierte Sessions zu verwenden muss session_start()
>>    aufgerufen werden, bevor irgend etwas an den Browser geschickt wird.

Du schickt schon doctype, html, head vor dem session_start.


Edit: SR wusste es auch, übersehen:

SR schrieb:
> solltest du die session starten bevor die erste Ausgabe
> erfolgt

SR schrieb:
>

1

>   header('Content-Type: text/html; charset=UTF-8');

2

>

>
> Ist auch unnötig, sollte dein Webserver schon so senden.

Wen der Webserver das mitsendet dann kündige bei dem Anbieter.

Ich will mir noch selber aussuchen in welcher charset
ich ggf. was sende.....

Ich bin da mal bei einer Datenbankpflege drüber gestolpert.. mein 
Vorgänger hat eine eigene Session kreiert und der hat die Session-IDs 
als Ordnername im Custom Verzeichnis hinterlegt.

Das sessiontimeout war dann ein Cronjob der die Session Dateien auf dem 
Server älter 1 Stunde gelöscht hat.

Sessions so lange halten … warum nicht einfach n Cookie mit Ablaufzeit 
setzen? Mit nem Session-Restart ist die Session Variable auch hin.
Ich setze bei sowas n Cookie mit der SessionId und den Rest schreib ich 
mit der ID als Identifier in ne MySQL-Datenbank. Beim Logout lösch ich 
einfach per JS das Cookie und mach n Reload 🤷‍♂️

Zum Löschen kann man einfach das Cookie mit einer abgelaufenen Zeit 
senden, dann wird es vom Browser automatisch gelöscht.

Das Charset sende ich immer nochmal im HTML-Header mit, damit hatte ich 
die wenigstens Probleme.

Versucht mal, die Sichtweise eines Angreifers immer gleich mitzudenken.
Das Cookie per Javascript löschen, im Cookie ein Timeout oder ein schon 
abgelaufenes Cookie löscht das Cookie im Browser des Nutzers.

Ein Angreifer hat das Session-Cookie u.U. längst abgegriffen.
Und die serverseitige Session funktioniert immer noch! Beim Abmelden / 
Sessionende muss daher auf jeden Fall die serverseitige Session 
invalidiert oder gelöscht werden.


Ähnlich ist es mit der Eingabevalidierung: im Browser, per JS irgendwas 
prüfen ist schön und gut. Von der Usability auch top, weil es sofort 
Feedback gibt.
Zwingend notwendig ist aber die Validierung auf der Serverseite!

Als Angreifer habe ich die Möglichkeit, beliebige Daten an den Server zu 
schicken, ohne jede clientseitige Validierung.
Wenn z.B. SQL-Injection möglich ist, weil serverseitig schlecht 
validiert wird, kann das ausgenutzt werden. Egal ob im Browser 
Sonderzeichen entfernt wurden oder ob das sogar nur ein Checkbox-Feld 
ist.

(Ja ich weiß, für Webentwickler ist diese Security-Zeugs oft scheinbar 
unnützer Ballast. So einen wirren Scheiß macht ja eh keiner... Ich weiß 
aber, dass Webapplikationen wegen solcher Nachlässigkeiten oft 
angreifbar sind, ich war 5 Jahre Pentester.
Und ich weiß, dass öffentlich erreichbare Webapplikationen irgendwann 
angegriffen werden. Unsicher ist nicht ob, sondern wann.)

Tilo R. schrieb:
> Ja ich weiß, für Webentwickler ist diese Security-Zeugs oft scheinbar
> unnützer Ballast.

Nicht für alle ;-)
Jahrelang mein eigenbau CMS betrieben, nicht ein einziger Versuch ging 
durch.

Leider alles weg, bei Gewitter backup auf ner externen HDD machen ist ne 
absolut beschissene Idee. Vor allem weil es dir gleich alles zerstört!

Nee, ist kein unnützer Ballast. Weil gerade dadurch entstehen 
schwerwiegende Sicherheitslücken, die nicht nur das eine quick'n'dirty 
Test-Script gefährden, sondern durch sowas wie eine SQL-Injection 
schnell richtig Schaden machen können.

Aber ich glaube sowas, wie daß man die Session beim Abmelden 
serverseitig als ungültig markiert oder wenn man sie behalten möchte 
zumindest als abgemeldet, sollte sich von selbst verstehen. Oder die 
Daten, die man aus einem Cookie erhält, grundsätzlich als 
kompromittierbar anzusehen und entsprechend zu prüfen - wie jede andere 
Benutzer-Eingabe auch.

Leider werden dem DAU oftmals unnütze Methoden als besonders nützlich 
verkauft und als Server-Betreiber verliert man dadurch Möglichkeiten, 
einen legitimen Benutzer sicherer zu erkennen. Wenn man z.B. die 
IP-Adresse bei der Anmeldung in der Session speichert, legt man die 
Latte für einen Angreifer ein Stück höher. Leider fliegen dadurch aber 
auch alle User raus, die keine eindeutige IP haben. Geht also nicht 
mehr. Oder zusätzliche Daten wie den User-Agent in der Session zu 
speichern und bei den Zugriffen zu überprüfen. Das sind alles kleine 
Puzzle-Teile, die sich ein Angreifer erst zusammensuchen muß. Leider 
senden viele Browser sowas heute erst gar nicht mehr mit weil das ja 
suuuper gefährlich ist und man sooo viele hochgeheime Daten dadurch 
ausspäht... **lol**

Tilo R. schrieb:
> Versucht mal, die Sichtweise eines Angreifers immer gleich mitzudenken.
> Das Cookie per Javascript löschen, im Cookie ein Timeout oder ein schon
> abgelaufenes Cookie löscht das Cookie im Browser des Nutzers.
Richtig, bei JS löscht es das Cookie aber jetzt sofort, Serverseitig das 
Cookie löschen geht bei PHP aber meines Wissens nur per Aufruf einer 
neuen Seite. Ebenso auch die SessionVars.

>
> Ein Angreifer hat das Session-Cookie u.U. längst abgegriffen.
> Und die serverseitige Session funktioniert immer noch! Beim Abmelden /
> Sessionende muss daher auf jeden Fall die serverseitige Session
> invalidiert oder gelöscht werden.

Per Ajaxaufruf kein Problem.

>
> Ähnlich ist es mit der Eingabevalidierung: im Browser, per JS irgendwas
> prüfen ist schön und gut. Von der Usability auch top, weil es sofort
> Feedback gibt.
> Zwingend notwendig ist aber die Validierung auf der Serverseite!
>
> Als Angreifer habe ich die Möglichkeit, beliebige Daten an den Server zu
> schicken, ohne jede clientseitige Validierung.

MySqli_Real_Escape und $_SERVER[„HTTP_REFERER“] sollten mal mindestens 
Pflicht sein.

> Wenn z.B. SQL-Injection möglich ist, weil serverseitig schlecht
> validiert wird, kann das ausgenutzt werden. Egal ob im Browser
> Sonderzeichen entfernt wurden oder ob das sogar nur ein Checkbox-Feld
> ist.
>
> (Ja ich weiß, für Webentwickler ist diese Security-Zeugs oft scheinbar
> unnützer Ballast. So einen wirren Scheiß macht ja eh keiner... Ich weiß
> aber, dass Webapplikationen wegen solcher Nachlässigkeiten oft
> angreifbar sind, ich war 5 Jahre Pentester.

Ernstgemeinte Frage, kann man Dich buchen? Würde mich interessieren ob 
mein CMS Lücken hat.

> Und ich weiß, dass öffentlich erreichbare Webapplikationen irgendwann
> angegriffen werden. Unsicher ist nicht ob, sondern wann.)

> [..] Ebenso auch die SessionVars.

1

$params=session_get_cookie_params();

2

setcookie(session_name(), '', time()-86400,

3

 $params['path'], $params['domain'],

4

 $params['secure'], $params['httponly']);

5

$_SESSION=array();

6

session_destroy();

Sollte jede Session killen, alle Daten auf dem Server und auch den 
Cookie beim Client.

> $_SERVER[„HTTP_REFERER“] sollte[n] mal mindestens Pflicht sein.
Kannste knicken, viele Clients senden keinen Referer mehr mit wie ich 
oben bereits schrieb. Der ist ja so böhse und verrät so viel über den 
Benutzer, genau wie diese gefährlichen Kekse, daß man das alles komplett 
ablehnen und verbannen muß.

Draco schrieb:
> Hä, was haben die HTML Identifier mit dem Session Cookie zu tun?

Es geht nicht um den Doctype an sich, sondern darum, dass überhaupt 
Ausgaben getätigt werden, bevor die session gestartet wird.

Einfach weil der "Set-Cookie" Http-Header eben ein Header ist, und nicht 
in den Content gehört.

Draco schrieb:
> Ich bitte um Aufklärung, weil auf meinen Seiten kommt der Session Start
> immer im Script Bereich, und funktioniert tadellos.

Es gibt ein paar Sonderfälle, wo das klappt. (z.B. Url-basierte 
Sessions, "ob_start" & co usw.)
Vermutlich hast du so einen. Allgemeingültig ist das nicht, wie auch in 
der PHP-Dokumentation vermerkt.