The recently disclosed groundbreaking vulnerabilities have set a precedent for how massive a security vulnerability can be. In the recent years, we have witnessed vulnerabilities that affect major frameworks like Java, PHP, OpenSSL and CGI. We haven’t seen a vulnerability affecting such a fundamental hardware piece in our computers – the CPU – until this day.
These vulnerabilities shuffle the cards on all the conventional protection mechanisms that exist in the web today – Same Origin Policy, Cross-Origin Source Sharing, Content Security Policy, et al.
The system memory, and IPC (Inter-Process Communication) were considered safe until today, so we could rely on sensitive data residing in memory not leaking outside.
Now that the picture has changed, it forces us to think about new attack surfaces. For example, an attacker may host a malicious website that scans the browser memory for data from other websites. If a victim website is still open in another tab, the data on that page may be compromised.
Reducing the Attack Surface with “SameSite” Cookie Attribute
In order to mitigate some specific attempts of extracting private data, we could consider using the following method.
Enabling the “SameSite” cookie attribute will prevent the attacker from controlling authenticated/sensitive data being saved in the memory (no cookie = no session).
SameSite attribute is controlled in: Security ›› Application Security : Headers : Cookies List ›› Edit Cookie ›› Insert SameSite Attribute