{"id":169865,"date":"2026-04-23T18:24:28","date_gmt":"2026-04-23T16:24:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-api-indexeddb-pozvolyayushhaya-identificzirovat-polzovatelej-firefox-i-tor-browser"},"modified":"2026-04-23T18:24:28","modified_gmt":"2026-04-23T16:24:28","slug":"uyazvimost-v-api-indexeddb-pozvolyayushhaya-identificzirovat-polzovatelej-firefox-i-tor-browser","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/uyazvimost-v-api-indexeddb-pozvolyayushhaya-identificzirovat-polzovatelej-firefox-i-tor-browser","title":{"rendered":"Eine Schwachstelle in der API IndexedDB, die es erm\u00f6glicht, Benutzer von Firefox und Tor Browser zu identifizieren.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im Gecko-Browser-Engine wurde eine Schwachstelle (CVE-2026-6770) entdeckt, die es erm\u00f6glicht, eindeutige Identifikatoren zur Verfolgung des \u00d6ffnens verschiedener Websites aus einem einzigen Browser zu erstellen. Das Problem tritt in allen auf Firefox basierenden Browsern auf, einschlie\u00dflich Tor Browser, und funktioniert selbst im privaten Modus. Die Identifikatoren gelten innerhalb des aktuellen Browserprozesses und werden nach einem Neustart des Browsers zur\u00fcckgesetzt. Die Schwachstelle wurde in den Versionen Firefox 150\/140.10.0 und Tor Browser 15.0.10 behoben. <\/p>\n
Um eine Kennung zu erstellen, gen\u00fcgt es, auf verschiedenen Websites \u00fcber die API IndexedDB dieselbe Datenbanksequenz zu erstellen und dann die Reihenfolge dieser Datenbanken als Ergebnis des Aufrufs der Methode indexedDB.databases() zu bewerten. Bei verschiedenen Browserinstanzen wird die Reihenfolge der Auflistung der Datenbanken unterschiedlich sein, aber innerhalb einer Instanz bleibt sie konstant. Diese Reihenfolge bleibt bis zum Neustart des Browsers bestehen und wird unabh\u00e4ngig von der ge\u00f6ffneten Website reproduziert. <\/p>\n
Beispielsweise wird nach der Erstellung der Datenbanken \u201ea,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,r\u201c in einer Firefox-Instanz die Methode indexedDB.databases() immer \u201eg,c,p,a,l,f,n,r,d,j,b,o,h,e,m,i,k\u201c zur\u00fcckgeben, w\u00e4hrend in einer anderen Instanz \u201ej,b,o,h,e,m,i,k,f,n,r,d,g,c,p,a,l\u201c zur\u00fcckgegeben wird. Bei der Erstellung von 16 Datenbanken k\u00f6nnen etwa 44 Bit Entropie zur Identifizierung gewonnen werden. Die Erstellung der Kennung wird nicht durch das L\u00f6schen lokaler Browser-Speicher oder das Aktualisieren der Tor-Knotenfolge durch die Schaltfl\u00e4che \u201eNeue Identit\u00e4t\u201c im Tor Browser beeintr\u00e4chtigt. Die Methode kann ebenfalls zur Identifizierung von Nutzern im Privatmodus verwendet werden. <\/p>\n
Die Schwachstelle ergibt sich aus einer Besonderheit der API-Implementierung von IndexedDB, bei der die Reihenfolge der Datenbanken von der spezifischen Anordnung interner Strukturen abh\u00e4ngt, die f\u00fcr jede Instanz des Browserprozesses charakteristisch ist. Die Reihenfolge der Elemente in der Liste der Datenbanken, die von der Methode indexedDB.databases() zur\u00fcckgegeben wird, h\u00e4ngt nicht von den Namen der Datenbanken oder von ihrer Erstellungsreihenfolge ab, sondern von der Platzierung in der globalen Hash-Tabelle der internen UUID-Hashes, die mit den Dateinamen assoziiert sind, in denen die Datenbanken auf der Festplatte gespeichert sind. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"