CSRF mislukt door SameSite cookies by default

Sinds er een embedded Chrome browser beschikbaar is in Burp Suite (vanaf versie 2020.7) maak ik hier regelmatig gebruik van als vervanger van Firefox met een separaat profiel. Toen ik eerder deze week bezig was met het uitvoeren van een pentest tegen een Lotus Domino webapplicatie, werkte een CSRF aanval niet terwijl ik dit wel had verwacht. Na het versturen van de POST request, kreeg ik telkens het inlogscherm te zien. Misschien had ik wat gemist, maar na meerdere controles zag ik toch echt nergens een teken van anti-csrf-tokens of een cookie met een mitigerende SameSite flag; de SameSite kolom in de Chrome DevTools was voor alle cookies leeg. Toen kwam ik op het idee om het eens in Firefox te proberen en verdorie: works like a charm.

Het nieuws eerder dit jaar is blijkbaar aan me voorbij gegaan, want het duurde even voordat ik door had dat Google vanaf Chrome 80 third-party cookie requests standaard blokkeert tenzij expliciet anders geconfigureerd. Hoewel dit in DevTools niet duidelijk wordt gemaakt (!), is de default setting nu “Lax”. Dit betekent dat cookies niet meer door de browser worden meegestuurd bij POST requests vanuit een ander domein; de basis onder een CSRF aanval. Ook Firefox lijkt dit voorbeeld te gaan volgen en kiest hiermee voor een verbeterde security-by-default. Behoren CSRF aanvallen daarmee definitief tot het verleden? Daar lijkt het niet op, aangezien er nog voldoende situaties zijn waarin een CSRF aanval nog wel werkt.