Door
Onbekende gebruiker
op 21-06-2021 22:35
gewijzigd op 21-06-2021 22:36
6.577 views
Ik heb een simpele javascript-functie die het altijd deed, totdat de klant eindelijk overstapte naar Edge.
Het gekke is dat de functie wel gewoon werkt met Internet Explorer en Firefox.
window.addEventListener('unload', function() {
let oXhr = new XMLHttpRequest();
let sUrl = document.getElementById('xhrAfmelden').getAttribute('href');
oXhr.open('POST', sUrl, false); // sync, anders venter te vroeg gesloten
oXhr.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
formData.append('_CSRF_', sToken);
oXhr.send();
});
De code moet er voor zorgen dat wanneer een venster gesloten wordt, de gebruiker automatisch wordt uitgelogd.
Het is nodig omdat bijna geen enkele gebruiker zichzelf uitlogt.
Maar sinds kort verschijnt hierdoor in mijn JS-foutlog vanuit Edge deze melding:
Het lijkt er op dat Edge (en evt. andere webkit browsers) de XMLHttpRequest niet afmaakt. Als ik de derde parameter van open() op true zet, werkt het soms wel met Edge, maar meestal niet. Wel krijg ik altijd de vraag van Edge 'Site opnieuw laden?.
Als ik het probeer met onbeforeunload gebeurt er helemaal niets, dus ik heb ff geen flauw idee hoe nu verder.
Weet iemand een oplossing?
Hehe ... cool :) Hoe weet de tab dan dat ie nog geen ID heeft? Roep je eerst de URL 'kaal' aan, en stuur je daarna het ID als POST-parameter mee of zoiets?
?Onbekende gebruiker
23-06-2021 14:01
gewijzigd op 23-06-2021 14:23
Als je de URL intikt krijg je een HTML pagina waarin al de random ID zit als JS variabele.
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.
Oké, klinkt leuk :-) Wel goed de veiligheid in de gaten houden en controleren of zo'n tab-id geen zwak punt is wat kan worden gemanipuleerd.
?Onbekende gebruiker
23-06-2021 22:26
Vind ik ook :)
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..
Klinkt goed :-) Geen idee wat er mis kan gaan ... zo te horen heb je er al goed over nagedacht!
?Onbekende gebruiker
24-06-2021 08:15
Ik denk niet dat het misgaat, alles blijft binnen de browser zoals gewoonlijk, met tab ID's maak ik alleen onderscheid tussen verschillende tabs, meer is het niet.
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.
?Onbekende gebruiker
08-08-2021 08:47
Ik loop toch nog tegen een klein detail aan bij het testen.
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...
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.
?Onbekende gebruiker
08-08-2021 09:39
Binnen de organisatie zijn developertools uitgeschakeld voor browsers van gewone gebruikers.
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?
