[PHP] Session wordt overgenomen door andere user

[RickyHeijnen]

DJMaze schreef op donderdag 22 november 2018 @ 17:05:
[...]

1 dag is echt veel te veel.
Sessie cookies zijn standaard maar 24 minuten geldig (bij inactiviteit of sluiten van de browser).

Stap over op een andere sessie storage (database, memcache, etc.) en zorg voor meer beveiliging, dan is je probleem hoogstwaarschijnlijk opeens weg.
Zeker wanneer in je PATH_SESSION meer dan 1000 bestanden staan.

Waarom is 1 dag te veel? Het is een backend applicatie die altijd open staat. Als ze twee uur van hun bureau weg zijn geweest en er belt een klant dan is het niet fijn als ze eerst opnieuw moeten inloggen als snel iets willen opzoeken. Ik zou het eventueel kunnen terugdraaien naar 8 of 10 uur.

Ik snap dat ik code kan aanpassen om het probleem op te lossen. Waarschijnlijk ga ik dit nu ook doen, maar de oorzaak van het probleem blijft dan altijd een raadsel.

PATH_SESSION (/home/app/cache/sessions/) bevat nu 55 files waarvan de oudste van vanmorgen half 7. Dus die GC werkt prima.

Het probleem is inderdaad nog niet verholpen. Afgelopen vrijdag weer 2 incidenten.

Sinds anderhalve week log ik alle HTTP request in een database. Daarin zie je heel duidelijk wat er gebeurt:

User A (rood) en User B (groen) zitten beide tegelijk in het systeem, van de een op de andere klik (blauwe regels) heeft User A ineens hetzelfde sessieid als User B gekregen en zijn ze als dezelfde persoon ingelogd. Ze zitten beide op een andere locatie met een ander IP en de sessietijd van User A was niet verlopen.

rutgerw schreef op donderdag 22 november 2018 @ 19:52:
[...]


Zonder dat ik een verklaring heb zou ik in elk geval deze dingen aanpassen:
- Die runtime ini_sets voor de session handler weghalen. Gewoon de standaardinstellingen gebruiken
- De session_write_close() calls weghalen (onnodige schrijfacties, session_write_close() wordt sowieso wel aangeroepen, geen noodzaak om dat expliciet te doen)
- 1 en niet meer dan 1 session_start()

Voor de rest is het behoorlijk vaag. De kans dat twee users dezelfde sessie toegewezen krijgen is zo goed als 0, zeker met die aantallen users waar jij mee te maken hebt. Zelfs al heb je twee verschillende applicaties die dezelfde sessie storage gebruiken, dan nog is de kans erg klein.

Als je die ini-sets weg hebt, zou je dan eens je volledige sessie configuratie kunnen posten zoals phpinfo() die geeft?

Ik heb dit nu aangepast. De reden voor de session_write_close() direct na session_start() is zodat meerdere ajax-calls niet op elkaar blijven wachten omdat het sessie bestand geopend is door een ander script. Behalve bij het inloggen en uitloggen worden nergens sessie's weggeschreven.

Hierbij de sessie configuratie:

Session Support		enabled
Registered save handlers		files user
Registered serializer handlers		php_serialize php php_binary wddx
Directive	Local Value	Master Value
session.auto_start	Off	Off
session.cache_expire	180	180
session.cache_limiter	nocache	nocache
session.cookie_domain	no value	no value
session.cookie_httponly	Off	Off
session.cookie_lifetime	0	0
session.cookie_path	/	/
session.cookie_secure	Off	Off
session.gc_divisor	0	0
session.gc_maxlifetime	1440	1440
session.gc_probability	0	0
session.lazy_write	On	On
session.name	PHPSESSID	PHPSESSID
session.referer_check	no value	no value
session.save_handler	files	files
session.save_path	/var/cpanel/php/sessions/ea-php71	/var/cpanel/php/sessions/ea-php71
session.serialize_handler	php	php
session.sid_bits_per_character	4	4
session.sid_length	32	32
session.upload_progress.cleanup	On	On
session.upload_progress.enabled	On	On
session.upload_progress.freq	1%	1%
session.upload_progress.min_freq	1	1
session.upload_progress.name	PHP_SESSION_UPLOAD_PROGRESS	PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix	upload_progress_	upload_progress_
session.use_cookies	On	On
session.use_only_cookies	On	On
session.use_strict_mode	Off	Off
session.use_trans_sid	0	0

[ Voor 0% gewijzigd door RickyHeijnen op 26-11-2018 13:51 . Reden: spelfout ]

[RickyHeijnen]

DJMaze schreef op dinsdag 27 november 2018 @ 09:26:
Aan de log te zien vind ik het sowieso kwalijk dat iemand opeens de sessie van een ander heeft en dat bij het uitloggen de sessie niet wordt vernietigd.

Bij het uitloggen gebeurt alleen unset($_SESSION['uid']);. Omdat het enige dat je wilt is de gebruiker uitloggen. Als er (in theorie) nog andere sessie variabelen actief zijn dan wil je die niet ook wissen bij het uitloggen. Aangezien dat in deze applicatie niet van toepassing is had het inderdaad ook anders gekund, ben ik met je eens, maar lijkt me niet zo 'kwalijk' als jij suggereert. Daarnaast doet een session_destroy() alleen de sessie vernietigen. Je behoud wel hetzelfde PHPSESS_ID. Met als gevolg dat 2 gebruikers ineens uitgelogd zijn.

ACM schreef op maandag 26 november 2018 @ 20:16:
[...]

Ik vraag me af of je wel voldoende informatie hier logt. Je wil eigenlijk ook de Set-Cookie headers zien (liefst buiten php om). Zitten hier nog POST-requests tussen of GET-parameters met sessie id (wellicht kreeg gebruiker 51 een linkje doorgestuurd van 4?)? Die key-financial-invoice (de laatste voor het sessie-id veranderde) kunnen we niet volledig zien, gebeurde daar nog iets bijzonders?

Via de request parameters meekrijgen zou uit moeten staan volgens jouw config, maar wie weet gaat daar iets mis. Gebeurt er nog iets in javascript met dat sessie id (je kan httponly aanzetten als dat niet gebeurt, is het weer wat veiliger)?

Verder is het alsnog aan te bevelen om de sessie te verwijderen bij uitloggen, want na die logout hebben beide gebruikers ineens userid 51 ipv allebei uitgelogd en daarna userid 51 alleen ingelogd.

Ik heb inmiddels bij het uitloggen een setcookie("PHPSESSID", '', time() - 42000, "/"); toegevoegd.

Meer informatie had ik eigenlijk niet perse nodig. Ik ben zelf eens gaan proberen om in een normaal browser scherm en een incognito browser scherm en heb nu zelf 2 hele concrete voorbeelden van wat er gebeurt:



Het gebeurt als 2 gebruikers in korte tijd na elkaar in dezelfde pagina zitten. Waardoor ik toch begin te denken dat er ergens headers gecached worden en opnieuw uitgespuugd worden door bijv. nginx of apache. Maar als dat zo is dan lijkt me dat een behoorlijk security issue. Het betreft nu gelukkig een interne backend applicatie, maar als je dit op je front-end website hebt lijkt me dit alles behalve wenselijk (nog zacht uitgedrukt).

Even nogmaals herhalen; de applicatie zelf draait al jaren en op wat noodzakelijke aanpassingen wordt er niet veel aan geknutseld. De laatste aanpassing is al weer een aantal maanden geleden, het probleem treedt op sinds een week of 4 nu.

Ik heb zelf weinig kaas gegeten van webserver configuratie etc. in principe doe ik daar zelf ook niks aan, dus weet ook niet precies waar ik nu moet gaan zoeken. Ik zal sowieso eens de hostingprovider vragen of er onlangs nog updates zijn uitgevoerd en wat precies.

Voor nu ga ik nog eerst wat verder debuggen of ik nog wat specifieker kan vinden wat er precies gebeurt.

Tot zover alvast erg bedankt voor jullie hulp

Edit: het request waarbij sessie-flip plaats vindt staat blijkbaar niet in het log, waaruit ik concludeer dat het request helemaal niet wordt uitgevoerd, maar de gehele pagina (incl headers) ergens wordt gecached en wordt uitgespuugd.