[PHP] Session wordt overgenomen door andere user

[RickyHeijnen]

Ik heb een backend webapplicatie draaien in PHP. Sinds een aantal dagen krijg ik de melding van gebruikers dat ze na een periode inactiviteit 'ineens' waren ingelogd als een andere collega.

Ik kon het zelf niet goed reproduceren of vinden wat nu precies het probleem was, tot ik het nu zojuist zelf ook ineens had; bij het openen van de applicatie in mijn browser was ik al direct ingelogd als een medewerker (waarvan ik zelf nooit ingelogd heb).

Wat ik heb ontdekt is dat ik een PHPSESSID heb gekregen die al bestond en was gekoppeld aan een ingelogde gebruiker.

session.gc_maxlifetime staat op 2 uur en session files worden ook na 2 uur netjes verwijderd door de GC.
Het 'ineens' wisselen van medewerker gebeurt ook nadat ze een periode niet actief zijn geweest in het systeem, maar wel open hebben staan. Logisch, normaal moeten ze dan opnieuw inloggen.

Ik weet dat het heel vaag is en heb ook echt geen idee waar ik moet zoeken in de source van de applicatie is niks veranderd de afgelopen weken.

Kan iemand me een klein beetje in de juiste richting duwen?
- Hoe kan het dat PHP session_id's uitgeeft die al bestaan?

En de extra vraag die bij me naar boven komt:
- Hoe veilig is het gebruik van SESSIONs bij het gebruik van een webapplicatie? Is het veilig genoeg om het te gebruiken voor authenticatie?
Nu is het gelukkig een backend applicatie dus niet echt gevolgen mbt privacy etc. Maar als je dit op de frontend van een website hebt dan lijkt me dit toch extreem onwenselijk.

[RobIII]

RickyHeijnen schreef op vrijdag 16 november 2018 @ 15:34:
- Hoe veilig is het gebruik van SESSIONs bij het gebruik van een webapplicatie? Is het veilig genoeg om het te gebruiken voor authenticatie?

Euh... authenticatie gebruik je om een sessie te krijgen, daarna heeft 't niets meer met elkaar te maken. En ja, sessions zijn veilig (mits goed toegepast). Zo'n beetje élke site gebruikt het...

[b2vjfvj75gjx7]

code:

if(session_id() == '' || !isset($_SESSION)) {
    // session isn't started
    session_start();
}

Voor je een sessie uitgeeft, kan je ook checken of die bestaat (en desnoods alles wissen als een sessie wel bestaat, te lang in-actief is, en hergebruikt (?) moet worden).

Maar het lijkt mij dat er iets anders speelt, dan een sessie die auto-magisch overgaat naar een andere gebruiker...

[b2vjfvj75gjx7]

RobIII schreef op vrijdag 16 november 2018 @ 15:47:
[...]

Euh... authenticatie gebruik je om een sessie te krijgen, daarna heeft 't niets meer met elkaar te maken. En ja, sessions zijn veilig (mits goed toegepast). Zo'n beetje élke site gebruikt het...

Denk dat TP identificatie bedoelt, niet authenticatie ...

Je zou aan de hand van een session(id) een gebruiker kunnen identificeren (of het good practice is, is een tweede).

Maar voor authenticatie is het inderdaad kip / ei -> eerst moet je authenticatie doen, geef je een sessie weg en dan pas kan je identificeren adhv. de sessie...

[YopY]

Ben je ingelogd als een andere gebruiker, of lijkt dat maar zo? Zit er een cache op pagina's ergens? Dat is een vaak voorkomend probleem, dwz, dat je een gecachede pagina van een andere gebruiker krijgt.

Zit het session ID in een cookie of in de URL? Die zou in een cookie moeten staan idealiter.

Zijn de sessions gekoppeld aan het IP van de gebruiker?

[RickyHeijnen]

b2vjfvj75gjx7 schreef op vrijdag 16 november 2018 @ 15:52:
Denk dat TP identificatie bedoelt, niet authenticatie ...

Je zou aan de hand van een session(id) een gebruiker kunnen identificeren (of het good practice is, is een tweede).

Maar voor authenticatie is het inderdaad kip / ei -> eerst moet je authenticatie doen, geef je een sessie weg en dan pas kan je identificeren adhv. de sessie...

Klopt, ik bedoelde identificatie inderdaad Dus alleen identificatie op basis van session_id() is dat genoeg voor een basis backend applicatie met 20-25 users? Lijkt mij wel... Het gaat eigenlijk ook al een jaar of 6 prima, alleen sinds afgelopen week krijg ik zo'n 2-3x per dag de melding dat ze ineens iemand anders zijn. De applicatie staat op een managed VPS met PHP 7.0 en wordt nu en dan wel geupdate, maar ik heb geen idee of dat het veroorzaakt kan hebben.

YopY schreef op vrijdag 16 november 2018 @ 15:55:
Ben je ingelogd als een andere gebruiker, of lijkt dat maar zo? Zit er een cache op pagina's ergens? Dat is een vaak voorkomend probleem, dwz, dat je een gecachede pagina van een andere gebruiker krijgt.

Nee, cache van de pagina is het niet aan de orde. Ik zie echt dat mijn Cookie-header een PHPSESSID een ID kreeg waarvan het sessie-bestand op de server al een half uur eerder was aangemaakt.

YopY schreef op vrijdag 16 november 2018 @ 15:55:
Zit het session ID in een cookie of in de URL? Die zou in een cookie moeten staan idealiter.

cookie ofcourse

YopY schreef op vrijdag 16 november 2018 @ 15:55:
Zijn de sessions gekoppeld aan het IP van de gebruiker?

Iedereen werkt vanuit hetzelfde netwerk, dus het IP van de gebruiker is voor bijna iedereen hetzelfde, tenzij ze bijv. thuis werken of ik hier inlog vanaf kantoor. Maar de session is niet gekoppeld aan het IP.

[rvrbtcpt]

Is niet ergens caching aangezet dat eerder niet het geval was? Varnish of op de webserver laag. Dit klinkt wel als een dergelijk issue.

[Voor 37% gewijzigd door rvrbtcpt op 16-11-2018 16:16]

[Cartman!]

RickyHeijnen schreef op vrijdag 16 november 2018 @ 16:07:
[...]
Dus alleen identificatie op basis van session_id()

Wat bedoel je hiermee? Hoe ziet dat er in code uit?

[frickY]

Waar staat de configuratie van "session.entropy_file" op? De kans dat PHP 2x een zelfde ID genereert is extreem klein. Mits goed geconfigureerd.

Ik zou er van uit gaan dat er ergens server responses, incl headers, gecached worden.
Maak je gebruik van diensten zoals bijvoorbeeld Cloudflare?

[eric.1]

RickyHeijnen schreef op vrijdag 16 november 2018 @ 15:34:
Ik weet dat het heel vaag is en heb ook echt geen idee waar ik moet zoeken in de source van de applicatie is niks veranderd de afgelopen weken.

Er mag dan niets veranderd zijn, toch gaat je sessie-beheer niet goed. Dat zit lijkt me hoe dan ook in de source.

tot ik het nu zojuist zelf ook ineens had; bij het openen van de applicatie in mijn browser was ik al direct ingelogd als een medewerker (waarvan ik zelf nooit ingelogd heb).

Wat ik heb ontdekt is dat ik een PHPSESSID heb gekregen die al bestond en was gekoppeld aan een ingelogde gebruiker.

Je had geen cookie / of in ieder geval geen geldige session-id. Er werd toen een id gebruikt welke bedoeld was voor een andere gebruiker, welke uiteraard bekend is op de server. Dus deze nieuwe sessie kreeg opeens een id van een andere gebruiker.

Links- of rechtsom mist er een controle of is het gewoon niet helemaal goed geïmplementeerd toch? Daar zou ik maar eens mee beginnen; hoe is het mogelijk dat iemand een bestaand session-id krijgt toegewezen van een andere gebruiker. Daar moet ergens een logica voor zorgen.

[ThomasG]

Frijns.Net schreef op vrijdag 16 november 2018 @ 16:15:
Is niet ergens caching aangezet dat eerder niet het geval was? Varnish of op de webserver laag. Dit klinkt wel als een dergelijk issue.

Caching is zeer waarschijnlijk waar het fout gaat. Het kan een proxy als Varnish zijn die verkeerd cached. Maar ook memcached of redis zijn die de fout in gaat omdat ze bijvoorbeeld out-of-memory lopen.

Daarbij kunnen sessies altijd 'gestolen' worden zodra iemand het sessie-id weet. Dat ging vroeger geregeld fout toen het sessie-id in de url stond, en mensen urls uitwisselde (staat nu in een cookie). Je kunt daar wel checks voor inbouwen zoals het opslaan van het ip-adres van de bezoeker in de sessie en zodra het niet klopt de sessie killen, maar die zijn weer vervelend als het op mobiele telefoons e.d. wordt gebruikt en je veel van ip-adres wisselt.

[AW_Bos]

Gaat het om gebruikers op een vast netwerk die elkaars inlog krijgen? Of van totaal vreemden?
Zo kan je snel achterhalen of het een caching issue op het netwerk is, of iets met sessies.
Ik vermoed sterk het eerste....

Ikzelf laat altijd na een inlog een session_regenerate_id() draaien, om een nieuwe SessieID te geven. Mocht deze uitlekken via een MITM na de inlog, dan heeft iemand anders er niks aan.

[Voor 30% gewijzigd door AW_Bos op 18-11-2018 14:21]

[Olaf van der Spek]

RickyHeijnen schreef op vrijdag 16 november 2018 @ 15:34:
...

Geen https?

Welke cache headers gebruik je?

[dev10]

Wat ik heb ontdekt is dat ik een PHPSESSID heb gekregen die al bestond en was gekoppeld aan een ingelogde gebruiker.

Kun je uitleggen hoe je de PHPSESSID koppelt aan de gebruiker? Dit is namelijk niet persé nodig. Wat je heel gemakkelijk kunt doen bij het inloggen van de gebruiker, is een authenicatie token opslaan in de sessie. Vervolgens controleer je in je applicatie welke gebruiker er bij die specifieke authenticatie-token hoort en weet je wie er ingelogd is.

Dit verklaart overigens nog niet hoe het kan dat er een sessie token wordt hergebruikt. Hoe genereer je een sessie token? Laat je dit door PHP doen, of heb je zelf een stukje logica geschreven om een 'unieke' token te maken? Ik heb het in m'n hele leven een keer zien gebeuren dat er door PHP zelf exact dezelfde sessie token werd gegeven aan twee verschillende gebruikers binnen hetzelfde netwerk. Ik heb het vaker zien gebeuren bij code waarbij de sessie token zelf werd gegenereerd en gezet door middel van session_id('token').

Als je zelf de sessie-token genereert, zou ik je aan willen raden om het in die hoek te zoeken.

[Wim-Bart]

De site staat extern op een VPS. Het gedrag al getest vanaf een andere locatie?

Het kan ook zijn dat er een laag 7 firewall tussen staat die niet lekker geconfigureerd is. Heb dit gezien met o.a. Baracuda WAF, die kan echt slecht met sessie cookies om gaan (PHP, ASP. NET).

[Harrie_]

dev10 schreef op dinsdag 20 november 2018 @ 17:08:
[...]
Kun je uitleggen hoe je de PHPSESSID koppelt aan de gebruiker? Dit is namelijk niet persé nodig. Wat je heel gemakkelijk kunt doen bij het inloggen van de gebruiker, is een authenicatie token opslaan in de sessie. Vervolgens controleer je in je applicatie welke gebruiker er bij die specifieke authenticatie-token hoort en weet je wie er ingelogd is.
[...]

Dit kan ik totaal niet volgen. Je sessie is toch juist de authenticatie-token?

• Iemand logt in met username Pietje en password XXX
• SELECT id, username, password, etc FROM users WHERE username = ...
• password-hash vergelijken
• success -> $_SESSION['userid'] = $db_result['id'];
• User krijgt een cookie met content abc123 en op server staat er in sessiefile sess_abc123: userid|s:0:"344"; en zo weet je welke user er is ingelogd?

Of ben ik nu compleet van de wap

[Voor 11% gewijzigd door Harrie_ op 21-11-2018 15:20]

[dev10]

Harrie_ schreef op woensdag 21 november 2018 @ 15:13:
[...]
Of ben ik nu compleet van de wap

Nee, niet persé. Jouw manier kan ook, maar ik zelf zou hem op een andere manier doen:

• Gebruiker logt in met user en password
• SELECT id, username, password, auth_token FROM users WHERE username = 'user'
• Vergelijk de wachtwoord hash
• Bij correct wachtwoord -> $_SESSION['auth_token'] = $result['auth_token'];

Vervolgens kun je de user ophalen aan de hand van de auth_token. Als de gebruiker zijn wachtwoord aanpast, kun je opnieuw inloggen forceren door de auth_token ook direct te wijzigen. Dit is iets lastiger is om te implementeren op het moment dat je alleen de user_id opslaat in de sessie.

Je kunt in mijn voorbeeld ook zeggen dat je autorisatie tokens in een aparte tabel opslaat, zodat je voor iedere sessie een aparte token hebt en je in een keer overal kunt uitloggen door de tokens in die tabel weg te gooien.

[Olaf van der Spek]

Harrie_ schreef op woensdag 21 november 2018 @ 15:13:
• success -> $_SESSION['userid'] = $db_result['id'];

Je start wel een nieuwe sessie. Toch?

[Harrie_]

Olaf van der Spek schreef op woensdag 21 november 2018 @ 16:24:
[...]

Je start wel een nieuwe sessie. Toch?

Ja, heel-heel-heelemaal bovenin

[RickyHeijnen]

Harrie_ schreef op woensdag 21 november 2018 @ 15:13:
[...]


Dit kan ik totaal niet volgen. Je sessie is toch juist de authenticatie-token?

• Iemand logt in met username Pietje en password XXX
• SELECT id, username, password, etc FROM users WHERE username = ...
• password-hash vergelijken
• success -> $_SESSION['userid'] = $db_result['id'];
• User krijgt een cookie met content abc123 en op server staat er in sessiefile sess_abc123: userid|s:0:"344"; en zo weet je welke user er is ingelogd?

Of ben ik nu compleet van de wap

Dit is exact hoe het nu gaat... en hoe het eigenlijk al een jaar of 5 gaat in die applicatie...

Wat beteft de vragen mbt caching:
- Er is geen Memached of Redis aanwezig (die cachen toch sowieso geen headers?)
- Het is geen netwerk issue aangezien ik het vanaf mijn eigen locatie ook één keer heb gehad -> Ik kreeg bij het openen van de site (incogito) direct een PHPSESSID cookie toegekend waarvan het sessiefile op de server al ruim een half uur eerder terug was aangemaakt en waardoor ik dus ook direct was ingelogd als de persoon van die oorspronkelijke sessie.

Wat ik nu gedaan heb afgelopen zondag is PHP geupdate van 7.0 naar 7.1 en PHP-FPM uitgezet. Sindsdien heb ik alleen maandag en dinsdag beide 1x een melding gehad van verkeerde inlog en daarna niet meer *klopt af*. Terwijl ik vorige week wel 4-5 meldingen per dag kreeg.

Dus of het nu opgelost is... geen idee waar het aan lag... ook geen idee

[emnich]

RickyHeijnen schreef op donderdag 22 november 2018 @ 14:46:

Wat ik nu gedaan heb afgelopen zondag is PHP geupdate van 7.0 naar 7.1 en PHP-FPM uitgezet. Sindsdien heb ik alleen maandag en dinsdag beide 1x een melding gehad van verkeerde inlog en daarna niet meer *klopt af*. Terwijl ik vorige week wel 4-5 meldingen per dag kreeg.

Dus of het nu opgelost is... geen idee waar het aan lag... ook geen idee

Als je na de upgrade het nog 2x hebt gehad is het blijkbaar niet opgelost.

Kan je niet een stukje relevante code plaatsen?

Harrie_ schreef op woensdag 21 november 2018 @ 20:27:
[...]


Ja, heel-heel-heelemaal bovenin

Na het succesvol inloggen moet je je oude sessie verwijderen en weer een nieuwe starten.

[Voor 17% gewijzigd door emnich op 22-11-2018 15:12]

[Harrie_]

emnich schreef op donderdag 22 november 2018 @ 15:07:
Kan je niet een stukje relevante code plaatsen?

Dit inderdaad. Iedereen is hier in het wilde weg aan het gissen waar het aan zou kunnen liggen terwijl het misschien zomaar in de code zichtbaar is?

emnich schreef op donderdag 22 november 2018 @ 15:07:
Na het succesvol inloggen moet je je oude sessie verwijderen en weer een nieuwe starten.

Dit volg ik niet? Er is geen oude sessie anders kon je in de eerste instantie niet eens inloggen, want dan was je al ingelogd?

PHP:

// pseudo
session_start();
if ($_SESSION['ingelogd'] === true){
    // user is ingelogd
    if($uitloggen){
        session_destroy();
    }
} else {
    // login form
    if($inloggen){
        $_SESSION['ingelogd'] = true;
    }
}

[RickyHeijnen]

emnich schreef op donderdag 22 november 2018 @ 15:07:
Als je na de upgrade het nog 2x hebt gehad is het blijkbaar niet opgelost.

Wel als ze die sessie's nog open hadden staan omdat ze in het weekend hun browser niet afsluiten. Ik heb na de upgrade niet alle openstaande sessie's gereset.

[Harrie_]

@RickyHeijnen Heb je gecontroleerd of de sess_bestanden op de server wel worden verwijderd? Als je in de afgelopen 5 jaar daar inmiddels 1.000.000 sess_bestanden hebt verzameld kan ik me best voorstellen dat het daarmee te maken heeft?

Welk OS/Webserver draai je?

[RickyHeijnen]

Harrie_ schreef op donderdag 22 november 2018 @ 15:18:
[...]
Dit inderdaad. Iedereen is hier in het wilde weg aan het gissen waar het aan zou kunnen liggen terwijl het misschien zomaar in de code zichtbaar is?

Ik heb in de code niks veranderd dus lijkt me stug dat het daaraan ligt, maargoed hierbij de regels waarbij iets met de sessies gebeurt.

PHP:

<?php
class MainController
{

    function startSession()
    {
        ini_set('session.gc_maxlifetime', 60*60*24);
        ini_set('session.gc_divisor', 10);
        
        session_save_path(PATH_SESSION);
        session_start();
        session_write_close();
    }
}


class User
{
    private function doWriteLoginSession($user_id)
    {
        session_start();
        $_SESSION['uid'] = $user_id;
        session_write_close();
    }
    private function getLoginSession($user_id)
    {
        return isset($_SESSION['uid']) ? $_SESSION['uid'] : false;
    }
}
?>

Harrie_ schreef op donderdag 22 november 2018 @ 15:21:
@RickyHeijnen Heb je gecontroleerd of de sess_bestanden op de server wel worden verwijderd? Als je in de afgelopen 5 jaar daar inmiddels 1.000.000 sess_bestanden hebt verzameld kan ik me best voorstellen dat het daarmee te maken heeft?

Welk OS/Webserver draai je?

Yes heb ik gecontroleerd, dat is niet het geval maar had voor de zekerheid direct ini_set('session.gc_divisor', 10); toegevoegd, maar dat hielp niet. Tevens dat verklaart ook niet dat ik een sessie toegewezen kreeg die een half uur eerder was aangemaakt.

Server draait op CENTOS 7.5 KVM

[emnich]

Harrie_ schreef op donderdag 22 november 2018 @ 15:18:
[...]


Dit inderdaad. Iedereen is hier in het wilde weg aan het gissen waar het aan zou kunnen liggen terwijl het misschien zomaar in de code zichtbaar is?


[...]


Dit volg ik niet? Er is geen oude sessie anders kon je in de eerste instantie niet eens inloggen, want dan was je al ingelogd?

PHP:

// pseudo
session_start();
if ($_SESSION['ingelogd'] === true){
    // user is ingelogd
    if($uitloggen){
        session_destroy();
    }
} else {
    // login form
    if($inloggen){
        $_SESSION['ingelogd'] = true;
    }
}

Er is altijd al een sessie omdat je anders niet kan controleren of de gebruiker ingelogd is. Om een sessie hijack te voorkomen kan je dan het beste bij het inloggen (of als gevoelige sessie data veranderd) een nieuwe sessie aanmaken.

@RickyHeijnen Kijk eens in je PATH_SESSION folder naar hoeveel bestanden er zijn en hoe ze heten en naar de rechten van die folder. En je hebt al gekeken naar de session settings in php.ini?

[DJMaze]

RickyHeijnen schreef op donderdag 22 november 2018 @ 15:31:
ini_set('session.gc_maxlifetime', 60*60*24);

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.

[Kalentum]

RickyHeijnen schreef op donderdag 22 november 2018 @ 15:31:
Ik heb in de code niks veranderd dus lijkt me stug dat het daaraan ligt, maargoed hierbij de regels waarbij iets met de sessies gebeurt.

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?

[ACM]

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).

Waarom? Je kan toch ook iets als 'ingelogd blijven' aanbieden, dan is 1 dag zelfs veel te kort...

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.

Als het misgaat doordat onterecht een bepaalde sessie id aan een gebruiker opnieuw wordt toegekend, dan lijkt me dat de interne opslag niet zo uitmaakt?
Als het misgaat doordat een response inclusief cookies wordt gecached en die opnieuw wordt doorgestuurd, dan maakt het hele onderliggende sessiesysteem al helemaal niet eens meer uit.

[ACM]

Harrie_ schreef op donderdag 22 november 2018 @ 15:18:
Dit volg ik niet? Er is geen oude sessie anders kon je in de eerste instantie niet eens inloggen, want dan was je al ingelogd?

't Is een best practice uit de security wereld om een nieuw sessie id (of dus volledig nieuwe sessie) te forceren zodra iemand inlogt. Op die manier kan iemand met een eventueel eerder verkregen/afgeluisterde anoniem sessie id niet misbruikt worden om meer rechten te vergaren.

Bij uitloggen moet je uiteraard ook iets soortgelijks doen.

[TRON]

Denk ook even aan het tegengaan van session fixation.

Als gebruikers allemaal een link gebruiken in hun bookmarks als: https://website/pagina/&SESSION_ID=<hier_een_sessie_id_dat_iedereen_als_bookmark_heeft_opgeslagen_omdat_iemand_een_keer_een_verkeerde_link_heeft_doorgestuurd> dan kan dat ook een van de oorzaken zijn als sessions fixation wordt toegelaten.

[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]

[ACM]

RickyHeijnen schreef op maandag 26 november 2018 @ 13:48:
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.

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.

[Voor 10% gewijzigd door ACM op 26-11-2018 20:17]

[incaz]

Vreemd. Mocht je eruit komen, hou ons vooral op de hoogte want dit leest haast als een thriller.

Met dat linkjes doorsturen: ik zie in de urls wel dat beide gebruikers een paar keer op dezelfde objecten bezig lijken te zijn (rental en invoice) - stel dat daar iets zit dat op een of andere manier conflict resolution probeert toe te passen waardoor de session overgedragen wordt? Misschien iets dat probeert om wijzigingen niet verloren te laten gaan als je uitgelogd raakt of iemand anders tegelijkertijd de gegevens wijzigt ofzo?

[DJMaze]

RickyHeijnen schreef op maandag 26 november 2018 @ 13:48:
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.

Hoe denk je dat bedrijven zoals Facebook dat doen met de "remember me"?
Gelukkig niet via sessies.

Zolang een webbrowser open staat kan je wel prima een http request elke 10 minuten doen via XMLHTTPRequest om de sessie open te houden (heartbeat / keepalive).

Voor de rest moet je dan waarschijnlijk ook even de sessies beveiligen op IP basis

[Erkel]

Lastig om het zo in te schatten maar het lijkt er op dat de key-financial-invoice de boosdoener is?
- Gebruiker .228 rommelt wat rond.
- Gebruiker .226 rommelt wat rond en navigeert naar key-financial-invoice (regel 150514)
- Gebruiker .228 navigeert via wat kliks naar key-financial-invoice (regel 150522-150528)
- Gebruiker .228 heeft na eerst volgende actie zelfde sessie id als .226 (regel 150578)

[Sandor_Clegane]

Hop je naar een ander systeem voor bepaalde aanvragen en geef je hierbij de sessie door?

[ACM]

DJMaze schreef op maandag 26 november 2018 @ 20:32:
Hoe denk je dat bedrijven zoals Facebook dat doen met de "remember me"?
Gelukkig niet via sessies.

Ik zou wel verwachten via sessies. Hoe anders? Ze zullen allicht ivm hun grootte wat efficienter proberen om te gaan met wat in een datablob hoort die je "sessie" kan noemen en wat daar niet in hoort.

Maar ook e.o.a. login-token-cookie is effectief een sessie-cookie als daar domweg weer allerlei gebruikers-eigen state wordt opgebouwd bij een request.

En wedervraag: ik weet precies hoe Tweakers het doet, hoe denk jij dat het gebeurt?
Wel met sessies; weliswaar niet de php-sessies, maar veel compactere dingen met slechts beperkte opslagfunctionaliteit. Maar we noemen het alsnog wel sessies

Wellicht hebben jij en ik een andere definitie van een 'sessie'.

Zolang een webbrowser open staat kan je wel prima een http request elke 10 minuten doen via XMLHTTPRequest om de sessie open te houden (heartbeat / keepalive).

Waarom zou je dat doen? De cookie een langere TTL geven is een veel goedkopere oplossing. Wat is er op tegen om sessies langer open te houden? Uiteraard hangt e.e.a. samen met risico's, bij banken is het niet zo vreemd dat ze je er sneller uitgooien dan bij facebook (of ons). Maar om nou te stellen dat sessies altijd van heel korte duur moeten zijn vind ik erg ver gaan.

Voor de rest moet je dan waarschijnlijk ook even de sessies beveiligen op IP basis

Dit is normaal gesproken niet nodig en o.a. met mobiele providers (waar opeenvolgende requests van verschillende ip's kunnen komen) eerder nadelig dan voordelig.

En zolang reeds gegeven sessie-cookies onverwacht uitgedeeld worden aan een ander, betekent dat in deze context dan vooral dat beide gebruikers dan steeds plotseling uitgelogd zijn. Het onderliggende probleem blijft dan hetzelfde

[emnich]

RickyHeijnen schreef op donderdag 22 november 2018 @ 15:31:
[...]


Ik heb in de code niks veranderd dus lijkt me stug dat het daaraan ligt, maargoed hierbij de regels waarbij iets met de sessies gebeurt.

PHP:

<?php
class MainController
{

    function startSession()
    {
        ini_set('session.gc_maxlifetime', 60*60*24);
        ini_set('session.gc_divisor', 10);
        
        session_save_path(PATH_SESSION);
        session_start();
        session_write_close();
    }
}


class User
{
    private function doWriteLoginSession($user_id)
    {
        session_start();
        $_SESSION['uid'] = $user_id;
        session_write_close();
    }
    private function getLoginSession($user_id)
    {
        return isset($_SESSION['uid']) ? $_SESSION['uid'] : false;
    }
}
?>

Is dit 100% zeker alles in je hele code waar iets van sessions in voorkomen (zoek op session case insensitive)?

Anders verwacht ik dat er wellicht nog wat meer op die server draait waarbij de sessie settings anders zijn. Je hebt bijvoorbeeld nog een ticketsysteempje waarbij de sessid wel via de url overgedragen wordt. Beide gebruikers zijn bezig met invoice 8734 die gekoppeld is aan ticket 123 met url /ticket/123?sessid=987654.

[DJMaze]

ACM schreef op dinsdag 27 november 2018 @ 08:33:
En wedervraag: ik weet precies hoe Tweakers het doet, hoe denk jij dat het gebeurt?
Wel met sessies; weliswaar niet de php-sessies, maar veel compactere dingen met slechts beperkte opslagfunctionaliteit. Maar we noemen het alsnog wel sessies

Juist, geen php session_start() voor duidelijke redenen.
Jullie gebruiken "__Secure-TnetID" en "uid" cookies met een geldigheid van 4 jaar.

Nou kan je die van jullie ook zien als "sessie" maar dat vind ik nog een wezenlijk verschil met session_start().
Ook aangezien de session.save_path in een shared omgeving heel vaak gevaarlijk staat ingesteld als /tmp

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.

[Janoz]

Nou kan je die van jullie ook zien als "sessie" maar dat vind ik nog een wezenlijk verschil met session_start().

Ik denk dat je daarin dan zwaar in de minderheid bent. Ik denk dat iedereen dat als een sessie ziet. Php's 'session_start()' is gewoon een implementatie van het 'sessie-patroon' waarbij een random token bij de client bewaard wordt (in een cookie, of door het mee te geven als parameter bij elk request) die refereert aan een stukje data op de server. Zo ongeveer elk zichzelf respecterende webomgeving heeft daarvoor een 'standaard' implementatie, en daarnaast zijn er, zoals overal in de IT, velen die vervolgens nog een keer het wiel uitgevonden hebben.

[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.

[emnich]

@RickyHeijnen Het lijkt dan inderdaad een cache probleem te zijn. Laat je hoster even kijken naar de instellingen voor de site en dan vooral
proxy_no_cache $cookie_PHPSESSID
proxy_cache_bypass $cookie_PHPSESSID

Of zet zelf de headers zo dat ie geen gebruik maakt van de cache.

[RickyHeijnen]

emnich schreef op dinsdag 27 november 2018 @ 12:29:
@RickyHeijnen Het lijkt dan inderdaad een cache probleem te zijn. Laat je hoster even kijken naar de instellingen voor de site en dan vooral
proxy_no_cache $cookie_PHPSESSID
proxy_cache_bypass $cookie_PHPSESSID

Of zet zelf de headers zo dat ie geen gebruik maakt van de cache.

Ik heb ze direct al even een bericht gestuurd, maar zit ook zelf even te kijken. Voor de huidige configuratie wordt gebruik gemaakt van Engintron for cPanel/WHM;

Engintron for cPanel/WHM integrates the popular Nginx® web server as a "reverse caching proxy" in front of Apache in cPanel®.

Nginx will cache & serve static assets like CSS, JavaScript, images etc. as well as dynamic HTML with a 1 second micro-cache. This process will reduce CPU & RAM usage on your server, while increasing your overall serving capacity. The result is a faster performing cPanel server.

Engintron is both free & open source.

Grote kans dat daarin een update heeft plaatsgevonden wat het e.e.a. in de war heeft gegooid op gebied van caching.

In de twee printscreens van de request- en response headers die ik mijn vorige post geplaatst heb zie je ook x-nginx-cache-status: HIT. Bij alle requests waarbij er geen sessie-flip plaatsvindt is deze header x-nginx-cache-status: EXPIRED

Dit is de huidige configuratie:

Perl: common_http.conf

# /**
#  * @version    1.9.2
#  * @package    Engintron for cPanel/WHM
#  * @author     Fotis Evangelou (https://kodeka.io)
#  * @url        https://engintron.com
#  * @copyright  Copyright (c) 2018 Kodeka OÜ. All rights reserved.
#  * @license    GNU/GPL license: https://www.gnu.org/copyleft/gpl.html
#  */

# Common definitions for HTTP content

# Initialize important variables
set $CACHE_BYPASS_FOR_DYNAMIC 0;
set $CACHE_BYPASS_FOR_STATIC 0;
set $PROXY_DOMAIN_OR_IP $host;
set $PROXY_FORWARDED_HOST $host;
set $PROXY_SCHEME $scheme;
set $SITE_URI "$host$request_uri";

# Generic query string to request a page bypassing Nginx's caching entirely for both dynamic & static content
if ($query_string ~* "nocache") {
    set $CACHE_BYPASS_FOR_DYNAMIC 1;
    set $CACHE_BYPASS_FOR_STATIC 1;
}

# Proxy requests to "localhost"
if ($host ~* "localhost") {
    set $PROXY_DOMAIN_OR_IP "127.0.0.1";
}

# Disable caching for cPanel specific subdomains
if ($host ~* "^(webmail|cpanel|whm|webdisk|cpcalendars|cpcontacts)\.") {
    set $CACHE_BYPASS_FOR_DYNAMIC 1;
    set $CACHE_BYPASS_FOR_STATIC 1;
}

# Fix Horde webmail forwarding
if ($host ~* "^webmail\.") {
    set $PROXY_FORWARDED_HOST '';
}

# Set custom rules like domain/IP exclusions or redirects here
include custom_rules;

location / {
    try_files $uri $uri/ @backend;
}

location @backend {
    include proxy_params_common;
    # === MICRO CACHING ===
    # Comment the following line to disable 1 second micro-caching for dynamic HTML content
    include proxy_params_dynamic;
}

# Enable browser cache for static content files (TTL is 1 hour)
location ~* \.(?:json|xml|rss|atom)$ {
    include proxy_params_common;
    include proxy_params_static;
    expires 1h;
}

# Enable browser cache for CSS / JS (TTL is 30 days)
location ~* \.(?:css|js)$ {
    include proxy_params_common;
    include proxy_params_static;
    expires 30d;
}

# Enable browser cache for images (TTL is 60 days)
location ~* \.(?:ico|jpg|jpeg|gif|png|webp)$ {
    include proxy_params_common;
    include proxy_params_static;
    expires 60d;
}

# Enable browser cache for archives, documents & media files (TTL is 60 days)
location ~* \.(?:3gp|7z|avi|bmp|bz2|csv|divx|doc|docx|eot|exe|flac|flv|gz|less|mid|midi|mka|mkv|mov|mp3|mp4|mpeg|mpg|odp|ods|odt|ogg|ogm|ogv|opus|pdf|ppt|pptx|rar|rtf|swf|tar|tbz|tgz|tiff|txz|wav|webm|wma|wmv|xls|xlsx|xz|zip)$ {
    set $CACHE_BYPASS_FOR_STATIC 1;
    include proxy_params_common;
    include proxy_params_static;
    expires 60d;
}

# Enable browser cache for fonts & fix @font-face cross-domain restriction (TTL is 60 days)
location ~* \.(eot|ttf|otf|woff|woff2|svg|svgz)$ {
    include proxy_params_common;
    include proxy_params_static;
    expires 60d;
    #add_header Access-Control-Allow-Origin *;
}

# Prevent logging of favicon and robot request errors
location = /favicon.ico {
    include proxy_params_common;
    include proxy_params_static;
    expires 60d;
    log_not_found off;
}

location = /robots.txt  {
    include proxy_params_common;
    include proxy_params_static;
    expires 1d;
    log_not_found off;
}

# Deny access to files like .htaccess or .htpasswd
location ~ /\.ht {
    deny all;
}

Perl: proxy_params_common

# /**
#  * @version    1.9.2
#  * @package    Engintron for cPanel/WHM
#  * @author     Fotis Evangelou (https://kodeka.io)
#  * @url        https://engintron.com
#  * @copyright  Copyright (c) 2018 Kodeka OÜ. All rights reserved.
#  * @license    GNU/GPL license: https://www.gnu.org/copyleft/gpl.html
#  */

# General Proxy Settings
proxy_pass                    $PROXY_SCHEME://$PROXY_DOMAIN_OR_IP:$PROXY_TO_PORT;
proxy_hide_header             Upgrade;
proxy_http_version            1.1;                # Always upgrade to HTTP/1.1
proxy_set_header              Accept-Encoding ""; # Optimize encoding
proxy_set_header              Connection "";      # Enable keepalives
proxy_set_header              Host $host;
proxy_set_header              Proxy "";
proxy_set_header              Referer $http_referer;
proxy_set_header              X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header              X-Forwarded-Host $PROXY_FORWARDED_HOST;
proxy_set_header              X-Forwarded-Port $server_port;
proxy_set_header              X-Forwarded-Proto $scheme;
proxy_set_header              X-Forwarded-Server $host;
proxy_set_header              X-Real-IP $remote_addr;
proxy_set_header              CF-Connecting-IP $http_cf_connecting_ip;
proxy_set_header              CF-Visitor $http_cf_visitor;

# Buffers
proxy_buffers                 256 16k;
proxy_buffer_size             128k;
proxy_busy_buffers_size       256k;
proxy_temp_file_write_size    256k;

# Timeouts
proxy_connect_timeout         300s;
proxy_read_timeout            300s;
proxy_send_timeout            300s;

Perl: proxy_params_dynamic

# /**
#  * @version    1.9.2
#  * @package    Engintron for cPanel/WHM
#  * @author     Fotis Evangelou (https://kodeka.io)
#  * @url        https://engintron.com
#  * @copyright  Copyright (c) 2018 Kodeka OÜ. All rights reserved.
#  * @license    GNU/GPL license: https://www.gnu.org/copyleft/gpl.html
#  */

# === MICRO CACHING ===
# 1 second (1s) micro-caching enabled for all proxied dynamic HTML content
# If you wish to have longer cache times, change the "proxy_cache_valid"
# line from "1s" to whatever time you want (e.g. "30s" or "1m").
# This cache is turned off when certain criteria are met, e.g. when a site
# manager logs into WordPress' backend/admin section.

#############################################################################################
# ADVANCED USERS ONLY:
# This setting is for cPanel servers with only one to a few sites & NO user-generated content
# in the frontend (no forums, no e-commerce sites, no user logins!) - you have been warned!
# Use the time defined in "$EXPIRES_FOR_DYNAMIC" to force client-side caching on dynamic content
# (set to 1m by default). To enable, uncomment all lines located at the bottom of this file.
# You can also raise "proxy_cache_valid" to the same value (e.g. "1m") to force longer
# server-side caching.
# The combination of these settings will have Nginx serve all content without issuing requests
# to Apache except only when it's required to refresh its cache.

set $EXPIRES_FOR_DYNAMIC 1m;

#############################################################################################

# Allow separate cache entries for mobile devices (smartphones & tables)
set $MOBILE "";
if ($http_user_agent ~* "(iPhone|iPod|iPad|Android|Mobile|Tablet)") {
    set $MOBILE "mobile_";
}

# CMS (& CMS extension) specific cookies (e.g. Joomla, K2 for Joomla, WordPress, WooCommerce, PrestaShop etc.)
if ($http_cookie ~* "(joomla_[a-zA-Z0-9_]+|userID|wordpress_[a-zA-Z0-9_]+|wp-postpass|comment_author_[a-zA-Z0-9_]+|woocommerce_cart_hash|woocommerce_items_in_cart|wp_woocommerce_session_[a-zA-Z0-9]+|sid_customer_|sid_admin_|PrestaShop-[a-zA-Z0-9]+)") {
    set $CACHE_BYPASS_FOR_DYNAMIC 1;
    set $EXPIRES_FOR_DYNAMIC 0;
}

# Invision Power Board (IPB) v3+
if ($cookie_member_id ~ "^[1-9][0-9]*$") {
    set $CACHE_BYPASS_FOR_DYNAMIC 1;
    set $EXPIRES_FOR_DYNAMIC 0;
}

# Invision Power Board (IPB) v4+
if ($cookie_ips4_member_id ~ "^[1-9][0-9]*$") {
    set $CACHE_BYPASS_FOR_DYNAMIC 1;
    set $EXPIRES_FOR_DYNAMIC 0;
}
if ($http_cookie ~ "ips4_IPSSessionFront") {
    set $CACHE_BYPASS_FOR_DYNAMIC 1;
    set $EXPIRES_FOR_DYNAMIC 0;
}

# Admin sections & generic entry point names for CMSs
if ($request_uri ~* "(/administrator|com_user|com_users|com_contact|com_mailto|/component/user|/component/users|/component/contact|/component/mailto|/wp-admin|/wp-login.php|/cart|/my-account|/checkout|/wc-api|/addons|/lost-password|\?add-to-cart=|\?wc-api=|/ucp.php|/login|/logout|/connect|/signin|/signup|/register)") {
    set $CACHE_BYPASS_FOR_DYNAMIC 1;
    set $EXPIRES_FOR_DYNAMIC 0;
}

# Disable caching when the "Cache-Control" header is set to "private"
if ($http_cache_control ~* "private") {
    set $CACHE_BYPASS_FOR_DYNAMIC 1;
    set $EXPIRES_FOR_DYNAMIC 0;
}

# Proxy cache settings
proxy_no_cache                 $CACHE_BYPASS_FOR_DYNAMIC;
proxy_cache_bypass             $CACHE_BYPASS_FOR_DYNAMIC;

proxy_cache                    engintron_dynamic;
#proxy_cache_background_update on;
proxy_cache_key                "$MOBILE$request_method$scheme$host$request_uri";
proxy_cache_lock               on;
proxy_cache_methods            GET HEAD;
proxy_cache_use_stale          error timeout invalid_header updating http_429 http_500 http_502 http_503 http_504; # Additional options: http_403 http_404
proxy_cache_valid              200 1s; # Adjust for longer server-side cache times (unfortunately, we cannot use a variable here)
proxy_ignore_headers           Cache-Control Expires Set-Cookie Vary;

Perl: proxy_params_static

# /**
#  * @version    1.9.2
#  * @package    Engintron for cPanel/WHM
#  * @author     Fotis Evangelou (https://kodeka.io)
#  * @url        https://engintron.com
#  * @copyright  Copyright (c) 2018 Kodeka OÜ. All rights reserved.
#  * @license    GNU/GPL license: https://www.gnu.org/copyleft/gpl.html
#  */

# === STATIC ASSET CACHING ===
# Proxy Cache Settings for static files ONLY.
# Nginx can cache static files and directly serve them without issuing calls
# to Apache on every static file request.
# By default Engintron will set a 1 minute (1m) cache time for static files.
# To increase, simply adjust the value for "proxy_cache_valid"
# Respects the different "Expires" header set per file type in "default.conf"
# for client-side caching.
# Every other header is ignored, stripped or reset from the request to
# maximize caching.
# This cache is turned off when certain criteria are met, e.g. when a site
# manager logs into WordPress' backend/admin section.

# Admin sections for CMSs
if ($request_uri ~* "(/administrator|/wp-admin|/wp-login.php)") {
    set $CACHE_BYPASS_FOR_STATIC 1;
}

# Proxy cache settings
proxy_no_cache          $CACHE_BYPASS_FOR_STATIC;
proxy_cache_bypass      $CACHE_BYPASS_FOR_STATIC;

proxy_cache             engintron_static;
proxy_cache_key         "$request_method$scheme$host$request_uri";
proxy_cache_lock        on;
proxy_cache_min_uses    1;
proxy_cache_revalidate  on;
proxy_cache_use_stale   error timeout invalid_header updating http_500 http_502 http_503 http_504; # Additional options: http_403 http_404
proxy_cache_valid       200 301 302 1m; # Adjust for longer server-side cache times (unfortunately, we cannot use a variable here)

proxy_ignore_headers    Cache-Control Expires Set-Cookie Vary;
proxy_hide_header       Cache-Control;
proxy_hide_header       Expires;
proxy_hide_header       Pragma;
proxy_hide_header       Set-Cookie;
proxy_hide_header       Vary;

# Reset headers
add_header              Pragma "public";

# Disable logging
access_log              off;

[RickyHeijnen]

Nu ik weet waar de oorzaak zit maakt dit het Googlen ook wat makkelijker en kom zo uit bij een vergelijkbare issue: https://github.com/engintron/engintron/issues/133

Super bedankt voor jullie hulp, inzichten en adviezen... Denk dat ik er zo verder wel uit ga komen