Sicherheit von Webanwendungen. Target="_blank" Sicherheitslücke
Lukasz Kolko
Die Nutzung von Webanwendungen ist für jede Gesellschaft alltäglich geworden. Wir haben jeden Tag mit ihnen zu tun. Wir können sagen, dass sie uns umgeben. Wir nutzen sie bei der Arbeit, zur Unterhaltung und als Werkzeuge für die Kommunikation mit anderen. Als Benutzer und Entwickler ist uns oft nicht bewusst, wie viele Sicherheitslücken täglich in solchen Anwendungen entdeckt werden.
Die in diesem Dokument erörterte Schwachstelle besteht schon seit langem, und aufgrund ihrer Einfachheit wird sie oft unterschätzt oder ist manchen sogar unbekannt. Webanwendungsentwickler.
Fast jede Webanwendung enthält Links, die, wenn sie angeklickt werden, in einer neuen Registerkarte geöffnet werden, um die Registerkarte mit der ursprünglichen Seite nicht zu schließen. Dies ist ein bevorzugtes Verhalten, da die Ersteller wollen, dass der Benutzer so viel Zeit wie möglich in der Anwendung verbringt.
Ein Angriff, der diese Schwachstelle ausnutzt, ist das so genannte "Reverse Tabnabbing". Dabei handelt es sich um einen Angriff, bei dem eine von der Zielseite verlinkte Seite in der Lage ist, diese Seite z. B. durch eine Phishing-Site zu ersetzen.
Angriffsszenario
Angenommen, das Opfer nutzt Facebook, das dafür bekannt ist, Links über target="_blank" zu öffnen,
Erstellen Sie eine gefälschte virale Seite,
Erstellen Sie eine Phishing-Website, die wie eine Facebook-Anmeldeseite aussieht,
Setzen Sie den untenstehenden Code auf der viralen Seite, z. B. über eine gefundene XSS-Schwachstelle window.opener.location = 'https://phishing-website/facebook.com';
Das Opfer klickt auf den Link auf Facebook, der zu der viralen Seite führt,
Die virale Seite leitet die Facebook-Registerkarte auf die Phishing-Website um und fordert den Benutzer auf, sich erneut anzumelden.
Wir können also die übergeordnete Registerkarte der infizierten Zielseite durch ein Fensterobjekt der Web-API ändern. Bei einem Angriff werden in der Regel mehrere entdeckte Schwachstellen und Phishing-Betrügereien parallel genutzt.
Das Problem
Wenn wir eine neue Registerkarte im Browser öffnen, indem wir einen Link mit dem target="_blank" Attribut haben wir Zugang zu unserem "Referrer" aus der neuen Registerkarte. Genauer gesagt, auf den Öffner Eigenschaft der Fenster Objekt, das einen Verweis auf das Fenster zurückgibt, das es geöffnet hat, unsere übergeordnete Seite.
Dies ist auf das Verhalten der Fenster.öffnen() Funktion. Mit Zugriff auf dieses Attribut können wir unsere übergeordnete Seite leicht ersetzen. Beachten Sie, dass einige moderne Browser die fenster.öffner Funktion in der Ziel-Registerkarte als null um dieses Verhalten zu verhindern.
Oben sehen Sie den infizierten Link, der ursprünglich eine neue Registerkarte mit einer GitHub-Seite öffnet, aber in der Zwischenzeit unsere "übergeordnete" Seite auf die Stackoverflow-Seite ändert.
Live-Beispiel
1. HTML-Links
hinzufügen rel="noopener noreferrer" zum <a> Tag.
Die rel Attribut definiert die Beziehung zwischen einer verlinkten Ressource und dem aktuellen Dokument.
noopener weist den Browser an, zum Ziel zu navigieren, ohne dem Elternteil, der es geöffnet hat, Zugriff zu gewähren. Registerkarte "Ziel Fenster.öffner wird null.
noreferrer verhindert, dass der Browser, wenn er zum Ziel navigiert, die Adresse oder einen anderen Wert als Referrer über die Referent HTTP-Header. Beachten Sie, dass der Name dieses HTTP-Headers absichtlich falsch als "Referrer" geschrieben wird.
Für das JavaScript Fenster.öffnen Funktion können Sie die Werte hinzufügen noopener und noreferrer im windowFeatures Parameter des Fenster.öffnen Funktion, aber verschiedene Browser können unterschiedlich reagieren, daher wird empfohlen, die Fenster.öffner als null nach Gebrauch Fenster.öffnen() Funktion.