Questo hack è fantastico nella sua assoluta semplicità. Permette di aggirare bellamente sia la normativa che moltissimi tool progettati per tutelare la privacy degli utenti in quei strumenti di sorveglianza chiamati "Web browsers". A chi (come me) non ci aveva pensato, può insegnare moltissimo. Di seguito riporto solo la spiegazione dell'attacco, disarmante nella sua semplicità. L'unica vera difesa, al momento, è disabilitare la cache del browser. Però la vulnerabilità dei browser sarebbe semplice da correggere in questo caso, invalidando la cache localmente: non inviare mai l'ETag registrato al server, inviare eventualmente una richiesta HEAD o una OPTIONS per ottenere l'ETag attuale della risorsa ed eventualmente effettuare la GET se necessario. Nei commenti c'è un altro trucchetto analogo (e persino più difficile da notare in un log proxy) che si basa sui redirect 301. Triste la conclusione dell'autore, preoccupato che i legislatori possano imporre agli sviluppatori dei browser di chiudere queste vulnerabilità che, seppure invasive della privacy, permettono (a suo dire) continua innovazione. Per (S)fortuna, è una preoccupazione triste quanto ingenua. Giacomo ___ Using Cache Technology To Track And Identify Users While ETags serve a useful purpose when used for caching, the feature can also be hijacked and intentionally misused for user tracking. Here is how I did it for my example above: 1) I built a website with three pages 2) I embedded the same iFrame on each of the pages. This iFrame is simply a white 1x1 pixel, which is invisible for the user. 3) When this iFrame resource is requested, I am creating a random ID via PHP on the server side. I use this ID to override the ETag ID for the iFrame, which is usually issued automatically. 4) Every time a user requests one of the three pages (and therefore requests that iFrame), my ETag ID is included in the request. Then, I am checking on the server side, if that ID exists or whether this is a first time request without an ETag. → If ETag exists: Returning visitor. Keep the ID and send the same one back. → If ETag does not exist: New visitor. New ID. From then on, this ID will be included in all request headers of this user’s device on the site. 5) As a last step — here is how this ETag ID finds its way into the analytics: I print the ID from the request/response headers in the iFrame on server side. Invisible for the user, this iFrame now contains the user’s ID. Then I pick it up from there on client side via JavaScript and simply include this ID in my analytics tracking request instead of a cookie ID. Continua su https://levelup.gitconnected.com/no-cookies-no-problem-using-etags-for-user-...