Sichern eines Browser-Hilfsobjekts

Die einzige Möglichkeit zum vollständigen Schutz vor solchen Angriffen besteht darin, den Ausführungskontext des JavaScript der Seite und den JavaScript-Code Ihrer Erweiterung zu trennen.

Als ich dieses Problem untersuchte, fand ich, dass Internet Explorer eine Möglichkeit bietet, einen solchen Kontext zu erstellen, nämlich über IAktivschrift . Ich habe diese Lösung jedoch aus folgenden Gründen nicht implementiert:

1. Mangel an Dokumentation / Beispielen, die IActiveScript mit BHOs ​​kombinieren.
2. Mangel an Gewissheit über die Zukunft (z. B. Ссылка ).
3. Mögliche Auswirkungen auf die Leistung (IE ist nicht für seine hervorragende Leistung bekannt, wie würden zwei Instanzen von JavaScript-Engines für jede Seite die Browsergeschwindigkeit beeinflussen?).
4. Kosten der Wartung: Ich hatte bereits eine bestehende Lösung, die gut funktionierte, basierend auf sehr vernünftigen Annahmen. Da ich nicht sicher bin, ob die alternative Methode (mit IActiveScript ) fehlerfrei und zukunftssicher wäre (siehe 2), habe ich beschlossen, die Idee fallen zu lassen.

Was ich stattdessen getan habe, ist:

1. Akzeptiere, dass sehr entschlossene Angreifer auf die Funktionalität meiner Erweiterung zugreifen können.
   • @Benjamin fragte, ob der Zugriff auf eine persistente Speicher-API eine Bedrohung für die Privatsphäre des Benutzers darstellen würde. Ich halte dieses Risiko für akzeptabel, da ein Speicherkontingent erzwungen wird und alle gespeicherten Daten vor der Verwendung validiert werden und einem Angreifer keine Werkzeuge mehr zur Verfügung stehen, um den Benutzer anzugreifen. Wenn ein Angreifer den Benutzer über persistenten Speicher verfolgen möchte, kann er einfach localStorage auf einer bestimmten Domäne verwenden und mit dieser Domäne über eine <iframe> kommunizieren, indem er die postMessage API. Diese Methode funktioniert über alle Browser, nicht nur IE mit meinem BHO installiert, so dass es unwahrscheinlich ist, dass Angreifer Zeit bei der Reverse-Engineering meines BHO zur Verwendung der API widmen, wenn es eine Methode gibt, die bereits in allen modernen Browsern funktioniert (IE8 + ).
2. Schränken Sie die Funktionalität der Erweiterung ein:
   1. Die Erweiterung sollte nur auf Seiten aktiviert werden, auf denen sie aktiviert werden muss. Dies reduziert die Angriffsfläche erheblich, da es für einen Angreifer schwieriger ist, Code auf https://trusted.example.com auszuführen und den Benutzer dazu zu verleiten, https://trusted.example.com zu besuchen.
   2. Erstellen und erzwingen Sie Whitelist-URLs für den bereichsübergreifenden Zugriff auf Erweiterungsebene (in systemeigenem Code (z. B. C ++) innerhalb des BHO).
   3. Beschränken Sie sich bei sensiblen APIs auf eine sehr kleine Gruppe vertrauenswürdiger URLs (wiederum nicht in JavaScript, sondern in systemeigenem Code).
   4. Der Teil der Erweiterung, der die domänenübergreifende Funktionalität behandelt, teilt keinen Status mit Internet Explorer. Cookies und Autorisierungsheader werden von der Anfrage und der Antwort entfernt. Selbst wenn ein Angreifer Zugriff auf meine API erhält, kann er aufgrund fehlender Sitzungsinformationen den Benutzer nicht auf einer anderen Website imitieren Dies schützt nicht vor Sites, die die IP des Anfordernden für die Authentifizierung (wie Intranet-Sites oder Router) verwenden, aber dieser Angriffsvektor ist bereits durch eine korrekte Implementierung einer Whitelist abgedeckt (siehe Schritt 2).

"In nativem Code erzwingen" bedeutet nicht "hard-code in nativem Code". Sie können weiterhin Aktualisierungen bereitstellen, die Metadaten und den JavaScript-Code enthalten. MSVC ++ (2010) unterstützt ECMAScript-artige reguläre Ausdrücke <regex> , was die Implementierung einer Regex-basierten Whitelist sehr einfach macht.

Wenn Sie IActiveScript verwenden möchten, finden Sie Beispielcode im Quellcode von ceee , Gears (beide eingestellt) oder jedes andere Projekt, das versucht, die Skriptumgebung von IE zu verbessern.