Edge logt niet uit met sluiten van venster
Vanuit die basispagina wordt een eerste XmlHttpRequest verstuurd waarna de loginpagina wordt getoond.
Na het inloggen krijgt de browser een HTTP cookie met de tab ID als onderdeel van de cookienaam.
Bij elke HTTP request stuurt de browser altijd alle cookies mee by design, dus kan je in PHP aan de hand van de tab ID de juiste cookie er uit filteren.
En als je de pagina opnieuw laadt komt er een ander ID in te staan, en dan ben je voor het oog ook uitgelogd.
Maar qua veiligheid, wat zou er kunnen gebeuren?
Als je de token hebt, kan je nog niets want de cookies zijn HTTP cookies en standaard HttpOnly en dus niet met JS te lezen, dus XSS kan je wel vergeten. Verder zitten er de standaard beveiligingen op, zoals een CSRF-token, anti clickjacking, anti-iframe, en zo..
Verder volg ik natuurlijk alle Cheat Sheets van OWASP die ik maar kan vinden, en blijf ik kritisch, meer kan ik niet doen.
Misschien is het nog leuk om zelf proberen m'n applicatie te hacken met de Zed Attack Proxy, maar zoveel tijd heb ik niet, dat moet nog een keer uitbesteed.
Na veelvuldig opnieuw in te loggen, loopt het aantal cookies vol zodat de webserver zegt dat de cookies of header te lang zijn.
Ik neem aan dat dit in de praktijk weinig zal voorkomen, eindgebruikers loggen niet graag de hele tijd in.
Je kunt client-side niet je eigen cookie uitlezen en verwijderen, dus er moet iets anders...
Ad Fundum op 08/08/2021 08:47:24:
Je kunt client-side niet je eigen cookie uitlezen en verwijderen
Je kan toch gewoon op het pagina icoon klikken in de adresbar en daar je cookies wissen.
Ook via de F12 kan je in chrome en edge de coockies wissen en vermoedelijk in (bijna) alle browsers.
Ze gebruiken daar Edge en Firefox, geen Chrome of iets anders.
Ik heb zelf geen Edge op Linux, maar zit die knop voor cookies dan ook in Edge?
Ofwel.. dat gaat hem niet worden, geen normaal mens (lees: niet-IT-er) gaat dit onthouden. Met als gevolg dat ze de webapplicatie terecht de schuld gaan geven.
Als de applicatie wordt afgesloten is er een event dat een XHR-request doet, maar de response niet afwacht met dank aan Google (Chrome). Ik krijg dan deze JavaScript error:
"Uncaught NetworkError: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'https://mijnsite.nl/': Synchronous XHR in page dismissal. See https://www.chromestatus.com/feature/4664843055398912 for more details."
Maar hoe moet het dan?
Toevoeging op 08/08/2021 13:13:56:
Nog even gezocht en kwam uit bij SO, het schijnt te kunnen met sessionStorage.
Dit uitzoeken wordt de volgende stap...
Zo heb ik pas geleden nog een cookie-overzicht voor mijn site gemaakt.
Gewijzigd op 08/08/2021 22:48:55 door - Ariën -
Ad Fundum op 08/08/2021 13:03:40:
Nog even gezocht en kwam uit bij SO, het schijnt te kunnen met sessionStorage.
sessionStorage en LocalStorage is niet moeilijk hoor. Wel enkel via javascript
tip: start je js met let stor = window["localStorage"]; of let stor = window["sessionStorage"]; dan kan je eenvoudig tussen de 2 wissellen.
Jan
Ik heb nu (voor de veiligheid) strikte HTTP-cookies waar JS niet bij kan. Wel heeft elke tab een JS variabele met de tab id, die wordt meegestuurd in het XHR-verzoek om te weten om welke cookie het gaat (de tab id is onderdeel van de cookienaam). Maar bij het sluiten van de tab kan je in JS niet de cookie unsetten.
Tegenwoordig kan je niet meer wachten op een HTTP response tijdens een document.unload event, waardoor de browser niet gecommuniceerd krijgt dat de cookie verwijderd moet worden. Het blijft actief in de browser totdat je de browser sluit. En voor elke nieuwe tab stuurt-ie oude cookies mee van tabs die er misschien al lang niet meer zijn.
Een stukje GC kan ingebouwd door bij het laden van de pagina (het is een SPA) te kijken welke cookies er worden meegestuurd naar PHP. Als er verlopen cookies tussenzitten kan PHP die inderdaaad alsnog laten verlopen via setcoookie(). Het maakt de kans kleiner dat de request buffer van de webserver vol zal lopen.
Maar dit is geen ideale oplossingsrichting. Misschien kan ik toch 1 cookienaam gebruiken, en de tab id uit de sessionStorage (of waar het ook staat) verwerken in de XHR-verzoeken (de hele SPA werkt met alleen maar XHR), zodat de webapplicatie ook al weet om welke sessie het gaat. Dan zou ik voor de hele SPA nog maar 1 'gebundelde' cookie nodig hebben.
Ik ga eens kijken of die oplossing te maken valt.
Kun je wellicht in plaats van bij het sluiten van een tabblad, tijdens het openen van een tabblad controleren op bestaande cookies? En op dat moment de inactieve cookies verwijderen?
Maar ik heb er nog even over nagedacht, en eigenlijk kan wat ik wil niet langer.
Het probleem is dat cookies niet verlopen dankzij de max-age=0 (anders werkt het niet eens goed), en dat de server de cookies op de browser niet meer goed kan beheren vanwege het missende synchrone unload event. De browser stuurt elke keer alle mee, en met de JS variabele kan de server onderscheid maken.
Maar dan blijven van gesloten tabs alle cookies in de browser totdat de browser gesloten wordt.
Dat werkt dus niet goed.
Ik ben zo snugger geweest om nu pas een keer te gaan kijken hoe de Fritz!Box het dan wel voor elkaar krijgt, en het antwoord is een grote teleurstelling: de Fritz!Box gebruikt daarvoor geen cookies, maar gooit de SID gewoon in de URL, zelfs over HTTP(!).
De uitkomst is dat ik een SID per browser tab wel kan vergeten, wil je het goed geregeld hebben. De business kan er gelukkig omheen, ze hebben tegenwoordig ipv. IE11 nu Edge én Firefox, dus ik kan het net zo goed weer allemaal terugveranderen.
Dit topic is gesloten.