Hallo.
Ich teste grade eine Session über PHP.
Was ich nicht verstehe ist, warum ich diese angelegte Variable in den
Chrome Entwicklertools nicht angezeigt bekomme.
Sie scheint es jedoch zu geben und ist auch lesbar.
Wenn ich beispielsweise bei Digikey den Application/SessionStorage
öffne, sehe ich einige Variablen hinterlegt.
Bei meinem kleinen Test irgendwie nicht:
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.
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 ;)
Angehängt der Screenshot von Digikey.
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
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
>> 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.....
Tilo R. schrieb:> 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
Stimmt schon.
Ich speicher tatsächlich auch die Login-Daten darin ab.
Danke für die weiteren Tipps!
Es ist eine interne Verwaltung im Firmennetz, daher ist nicht wirklich
was abgefangen.
Ich war da nun gerade nochmal dran, weil Mitarbeiter meinten, dass man
sehr schnell ausgeloggt wird und die Zeit nicht reicht.
Auf den einzelnen Seiten wird
1
ini_set('session.gc_maxlifetime', 28800); //Session-Time auf 8h stellen
aufgerufen.
Und trotzdem ist nach ca. einer halben Stunde schluss.
Es gibt Spezialisten die unfassbar lange brauchen um Formulare
einzutippen und dann schlägt es zu...
SessionStart war nur hier im Testcode nach dem HTML-Zeugs.
Sorry.
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.)
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ß.
Ben B. schrieb:>> $_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ß.
Also ich hab das bei mir auf dem Server gecheckt, mit Android, iOS, Mac,
Windows 7 und 10, jeweils Opera, Firefox, (Edge), Safari, da kam der Ref
immer mit. ... Wenn einer sich alles dicht macht, selbst schuld wenn er
bei meiner Site nicht weiter kommt.
Εrnst B. schrieb:> 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.
Hä, was haben die HTML Identifier mit dem Session Cookie zu tun?
Ich bitte um Aufklärung, weil auf meinen Seiten kommt der Session Start
immer im Script Bereich, und funktioniert tadellos.
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.