it-swarm.com.de

Verhindert inkognito / privates Surfen XSS-Angriffe?

Beim Starten einer inkognito/privaten Browsersitzung sollten keine Cookies von anderen Browsing-Profilen vorhanden sein. Wenn ich beispielsweise in meinem Hauptbrowserprofil bei einer Site angemeldet bin und dann eine neue private Browsersitzung starte, bin ich nicht bei derselben Site angemeldet (Cookies werden nicht übertragen). Angenommen, es handelt sich um eine neue private Browsersitzung, sollten keine Cookies oder vertraulichen Informationen vorhanden sein, die überhaupt verfügbar sind.

Hat dies auch den Nebeneffekt, XSS-Angriffe zu verhindern oder aufzuheben, da keine sensiblen Daten gestohlen werden müssen? Oder ist das ein falsches Sicherheitsgefühl?

15
Jack

Bei einem XSS-Angriff geht es nicht in erster Linie um Cookies. Es geht auch nicht darum, sensible Daten zu stehlen. Es geht stattdessen darum, vom Angreifer kontrollierten Code auf der Clientseite im Kontext der von Ihnen besuchten Site auszuführen. Welche Art von Schaden durch diesen Code verursacht werden kann, hängt von der tatsächlichen Site und dem tatsächlichen Kontext ab.

Die Verwendung einer privaten Browsersitzung verhindert XSS nicht von sich aus, kann jedoch die Auswirkungen des Schadens begrenzen, den XSS anrichten kann - d. H. Es hat keinen Zugriff auf die Cookies oder andere gespeicherte Daten aus der nicht privaten Browsersitzung. Es kann zwar immer noch schaden, aber dies hängt wiederum vom spezifischen Kontext und der Site ab, die Sie besuchen.

31
Steffen Ullrich

Es gibt hauptsächlich zwei Arten von XSS-Angriffen : Persistent und Ad-hoc.

Eine private Browsersitzung schützt Sie vor Ad-hoc-XSS-Angriffen, jedoch nicht vor dauerhaften Angriffen.

Ein beständiges XSS funktioniert, indem ein Angreifer irgendwo in die vertrauliche Seite Skriptcode einfügt. Dies kann durch Senden einer vorbereiteten Nachricht auf der Plattform oder durch eine andere Methode zum Einfügen von Daten in den Speicher der vertraulichen Seite erfolgen. Wenn Sie sich auf der vertraulichen Seite anmelden, um einige Daten anzuzeigen, werden die injizierten Daten vom Server geladen und an Ihren Browser übertragen. Sie werden ausgeführt, wenn die Site anfällig ist. Ein Beispiel wäre eine vorbereitete Nachricht in einer Online-Banking-Transaktion. Der Angreifer würde Ihnen eine echte Transaktion senden und der Nachrichtenteil würde schädliches Skript enthalten. Da keine andere Seite beteiligt ist, können Sie sich nicht davor schützen, sondern nur der Seiteninhaber.

Ein Ad-hoc-XSS kann funktionieren, indem Sie auf einen vorbereiteten Link klicken, der Injektionsdaten enthält. Ein solcher Link könnte wie https://banking.securebank.com/searchTransaction?query=<script>doEvil(...)</script> aussehen, bei dem das injizierte Skript Teil des Links ist. Der Angreifer versucht, Sie zum Klicken auf diesen Link zu bewegen, oder versucht, ihn im Hintergrund über JavaScript von seiner eigenen vorbereiteten Seite aus auszuführen. Wenn Sie also E-Mail-Links und nicht vertrauenswürdige Seiten in einer separaten Sitzung öffnen, ist Ihr Benutzerkonto auf der vertraulichen Seite vor dieser Art von Angriff geschützt, da Sie in der Inkognito-Sitzung nicht auf der vertraulichen Seite angemeldet sind. Während das XSS möglicherweise noch ausgeführt wird, kann es Ihrem eigenen Konto auf der vertraulichen Seite keinen Schaden zufügen. Dies möchten wir schützen.

3
Falco

Wie Steffen bereits erwähnt hat, funktioniert ein XSS (cross Site Scripting-Angriff) per Definition nicht nur mit Cookies. Wenn jemand Zugriff auf eine Datenbank erhält und bestimmte Felder bearbeitet, die Skript-Tags enthalten, die auf bestimmten Webseiten ausgeführt werden können, kann er einen XSS-Angriff ausführen.

Es bedeutet nur, dass jemand in Ihrem Browser Skripte auf der Seite ausführt, die Sie besuchen, um Informationen von Ihnen abzurufen (möglicherweise Cookies) oder Sie zu täuschen, indem Sie das DOM so anpassen, dass beispielsweise eine Zahlungsschaltfläche mit seiner fehlerhaften Website verknüpft wird.

1
Devilscomrade