{"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\/news\/uyazvimost-v-api-indexeddb-pozvolyayushhaya-identificzirovat-polzovatelej-firefox-i-tor-browser","title":{"rendered":"Eine Schwachstelle in der API IndexedDB erm\u00f6glicht die Identifizierung von Benutzern in Firefox und Tor Browser.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im Browser-Engine Gecko wurde eine Schwachstelle (CVE-2026-6770) entdeckt, die es erm\u00f6glicht, einzigartige Identifikatoren zum Nachverfolgen des Zugriffs auf verschiedene Websites aus demselben Browser zu generieren. Das Problem tritt in allen auf Firefox basierenden Browsern auf, einschlie\u00dflich Tor Browser, und funktioniert sogar 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 Identifikationsnummer zu erstellen, gen\u00fcgt es, \u00fcber die API IndexedD auf verschiedenen Websites die gleiche Datenbanksequenz anzulegen und anschlie\u00dfend die Reihenfolge dieser Datenbanken mit dem Aufruf der Methode indexedDB.databases() zu bewerten. Die Reihenfolge der Datenbanken kann sich zwischen verschiedenen Browserinstanzen unterscheiden, wird jedoch innerhalb einer Instanz wiederholt. Diese Reihenfolge bleibt bis zum Neustart des Browsers erhalten und ist unabh\u00e4ngig von der ge\u00f6ffneten Website. <\/p>\n
Beispielsweise wird nach der Erstellung der Datenbank \u201ea,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,r\u201c in einer Instanz von Firefox 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 sie in einer anderen Instanz \u201ej,b,o,h,e,m,i,k,f,n,r,d,g,c,p,a,l\u201c zur\u00fcckgibt. Bei der Erstellung von 16 Datenbanken kann man etwa 44 Bit Entropie zur Identifizierung erreichen. Die Generierung der Identifikationsnummer wird nicht von der Bereinigung des lokalen Browser-Cache und der Aktualisierung der Tor-Node-Kette durch die Schaltfl\u00e4che \u201eNeue Identit\u00e4t\u201c im Tor-Browser beeinflusst. Die Methode kann auch zur Identifizierung von Benutzern im privaten Modus verwendet werden. <\/p>\n
Die Schwachstelle wird durch die Besonderheit der Implementierung der API IndexedDB verursacht, wobei die Reihenfolge der Datenbanken von der internen Strukturabh\u00e4ngigkeit beeinflusst wird, die f\u00fcr jede Instanz des Browser-Prozesses spezifisch 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 der Reihenfolge ihrer Erstellung ab, sondern von der Platzierung der internen UUID-Hashes in der globalen Hash-Tabelle, die mit den Dateinamen verkn\u00fcpft 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":"