Wo kommen die rel-Attribute in euren WordPress-Links her?
target="_blank"
-Links ein Sicherheitsrisiko versteckt – und was ihr dagegen tun könnt.Verwendet ihr für eure Website WordPress? Dann könnte euch in den vergangenen Tagen – seit dem Update auf die Version 4.7.4 – aufgefallen sein, dass eure Links in der Quellcode-Ansicht des Editors plötzlich anders aussehen:
Alle Links, für die ihr „Link in einem neuen Tab öffnen“ ausgewählt habt, haben nämlich plötzlich zu ihrem Attribut target="_blank"
noch das Attribut rel="noopener noreferrer"
dazubekommen. Aber warum?
Der Grund ist eigentlich ganz einfach: target="_blank"
birgt ein erstaunlich großes Sicherheitsrisiko. Erstaunlich deshalb, weil das Attribut ständig und überall verwendet wird – und das damit verbundene Risiko auch schon lange bekannt ist. Bislang wurde es häufig schlicht ignoriert – wohl auch deshalb, weil das Risiko für Missbrauch hauptsächlich auf solchen Seiten besteht, auf denen viele von Nutzern generierte Inhalte gepostet werden – Facebook und Instagram etwa. Dennoch öffnet es grundsätzlich auf allen Webseiten die Möglichkeit für Phishing-Attacken.
Wo liegt das Problem?
Das Link-Attribut target="_blank"
gibt dem Browser die Anweisung, den Befehl window.opener
auszuführen. Dadurch bekommt das neu zu öffnende Fenster die Möglichkeit, den Inhalt des aufrufenden Fensters zu manipulieren. Reverse Tabnabbing nennt man das. Man kann dies zum Beispiel dazu nutzen, dem User vorzugaukeln, er sei noch auf der aufrufenden Seite und ihn zur Eingabe von Login-Daten auffordern, um diese dann abzugreifen.
Was kann man dagegen tun?
Dass das Risiko so lange ignoriert wurde, ist besonders deshalb erstaunlich, weil es verhältnismäßig einfach zu beheben ist. Es genügt nämlich (eigentlich), dem Link das Attribut rel="noopener"
mitzugeben, um dem neuen Fenster den Zugriff auf das öffnende Fenster zu verweigern.
Warum lautet die Angabe in den veränderten Links in WordPress dann aber rel="noopener noreferrer"
? Unter anderem Alex Jumašev vom JitBit-Blog führt dies darauf zurück, dass Firefox noopener
nicht unterstützt. [EDIT: Das ist offenbar seit März 2017 nicht mehr richtig, siehe Update.] Das wäre ein triftiger Grund, ein weiteres Attribut zu ergänzen. Das Dumme ist nur, dass das von WP außerdem ergänzte noreferrer
noch mehr tut, als nur den Zugriff auf das öffnende Fenster zu blocken. Es verhindert nämlich auch, dass der neu aufgerufenen Seite via HTTP-Header Informationen über die aufrufende Seite mitgegeben werden. Das kann nicht nur ein Problem für Analytics-Tools wie Google Analytics oder Piwik sein, die so im Zweifel nicht mehr nachvollziehen können, woher die Nutzer einer Seite kamen, sondern möglicherweise auch für Affiliate-Programme. Inwiefern dies beispielsweise Links im Rahmen des amazon-Affiliate-Programms beeinflusst, wird derzeit heftig diskutiert – eine offizielle Ansage von amazon selbst gibt es dazu aktuell noch nicht.
Warum sind die Attribute nicht in allen Links ergänzt?
Wer aus dem Auftauchen der neuen Attribute im WP-Editor jetzt schließt, dass die Ergänzungen bei allen target="_blank"
-Links in der gesamten WordPress-Installation vorgenommen wurden, liegt allerdings falsch. Die von WordPress vorgenommene Änderung betrifft nämlich genau genommen nur den TinyMCE-Editor, also den visuellen Editor von WordPress. Das bedeutet: Die Attribute werden nur in seit Version 4.7.4 neu angelegten Beiträgen/Seiten oder beim Bearbeiten bestehender Beiträge/Seiten ergänzt. Und auch nur, wenn ihr tatsächlich den WordPress-eigenen Editor nutzt. Verwendet ihr stattdessen einen etwa vom Theme mitgelieferten Visual Builder/Drag-and-Drop-Builder, wie sie gerade für komplexe Themes wie Divi, X oder Enfold* immer beliebter werden, ändert sich an eurem Code gar nichts.
* EDIT: Da Enfold trotz Layout-Editor in vielen Modulen den TinyMCE nutzt, werden die Link-Ergänzungen dort trotzdem gesetzt, danke an Renate Hermanns für den Hinweis!
Was also tun?
Gute Frage, denn das kommt drauf an. Wenn ihr nie die Option „Link in einem neuen Tab öffnen“ verwendet, braucht ihr gar nichts zu tun, dann ändert sich nämlich nichts. Wenn doch, solltet ihr wohl als erstes herausfinden, ob die Änderungen im WP-Update eure Website/euren Blog betreffen oder nicht. Ruft dafür mal eine eurer Seiten oder einen eurer Beiträge, in denen ihr Links in neuen Fenstern öffnet, im Editor auf und schaut euch den Code in der Text-Version an. Wenn dort hinter target="_blank"
die Ergänzung rel="noopener noreferrer"
steht, gilt dies für alle seit Version 4.7.4 neu angelegten bzw. im Editor bearbeiteten Beiträge/Seiten.
target="_blank"
suchen und überprüfen, ob die Ergänzung vorhanden ist. [/box]
Bevor ihr das Verhalten eures Themes prüft, solltet ihr darauf achten, dass ihr auch die aktuelle Version des Themes verwendet. Eine gute Gelegenheit, nicht nur die WordPress-Basis-Installation und verwendete Plugins, sondern auch euer Theme auf den aktuellen Stand zu bringen.
Wie entscheiden?
Wisst ihr, wie die Lage in eurem Fall aussieht, müsst ihr eine Entscheidung treffen. Wie die aussieht, hängt von vielen Faktoren ab:
- Wie verwendet ihr
target="_blank"
? Öffnet ihr damit zum Beispiel auch ab und zu interne Links auf eigene Inhalte in einem neuen Tab? Dann könnte dasnoreferrer
-Attribut eure Analytics-Daten ein wenig durcheinander bringen. - Benutzt ihr überhaupt ein Analytics-Tool?
- Arbeitet ihr mit Affiliate-Programmen und setzt zum Beispiel Affiliate-Links auf amazon oder andere Partner? Dann solltet ihr versuchen zu klären, ob das
noreferrer
-Attribut Einfluss auf eure Affiliate-Zuordnung hat. - Bietet ihr auf eurer Website Fremden die Möglichkeit, Links zu posten? Beispielsweise in der Kommentarsektion eures Blogs? Denn nur dann ist das Risiko für Reverse Tabnabbing hinter
target="_blank"
auch tatsächlich eine realistische Gefahr. Solange ihr die Links, die ihr so aufruft, selber auswählt und nur auf seriöse Seiten verlinkt (was eigentlich ohnehin selbstverständlich sein sollte), bleibt das Risiko vergleichsweise gering.
Je nachdem, wie ihr die obigen Fragen beantwortet, solltet ihr abwägen, was für euch wichtiger ist:
- Wenn ihr Affiliate-Links setzt, für die die fehlenden Referrer-Angaben ein Problem sind, möchtet ihr die von WordPress nun ergänzten Attribute möglicherweise lieber wieder loswerden. Fragt sich nur, ob das so richtig empfehlenswert ist, denn das Sicherheitsrisiko bleibt ja bestehen. Ein Kompromiss könnte es sein, auf die Zusatzangabe
noreferrer
zu verzichten und darauf zu hoffen, dass Firefox sich in Zukunft besser mitnoopener
versteht. Egal, wie ihr euch entscheidet, müsst ihr jetzt aktiv werden. - Ist der Schutz vor Reverse Tabnabbing euch besonders wichtig und Analytics und Affiliate-Links kratzen euch weniger? Dann ist die aktuelle WP-Änderung für euch ein guter erster Schritt, denn dann sollte euer Ziel sein, für alle
target="_blank"
-Links das Attributrel="noopener noreferrer"
zu ergänzen. Sofern ihr zum Erstellen und Bearbeiten eurer Seiten/Beiträge den normalen TinyMCE-Editor von WordPress nutzt, dürfte das für alle zukünftigen Links in euren Beiträgen/Seiten bereits der Fall sein.
ABER: Um die Ergänzung auch rückwirkend für bereits bestehende Inhalte einzubauen, müsst ihr selbst Hand anlegen. Und wenn ihr wirklich auf der sicheren Seite sein wollt auch, denn wenn man genauer hinschaut, sind die Änderungen im TinyMCE-Editor am denkbar schlechtesten Ort gelandet.
Was ist mit der Kommentarsektion?
Oben habe ich erklärt, wo ein faktisches Risiko von Reverse Tabnabbing besteht: Da, wo Fremde von eurer Website aus Links setzen können. Das ist außerhalb von Social-Media-Plattformen meist in Foren oder etwa in den Kommentarsektionen eines Blogs der Fall. Habt ihr eine kleine Unternehmenswebsite mit angeschlossenem Blog, dürfte also in den dortigen Kommentaren euer größtes Risiko liegen. Da das WP-Update sich aber ausschließlich auf den Editor auswirkt, hat die Änderung auf die Kommentare überhaupt keine Auswirkung. Darin werden Links werden weiterhin wie gewohnt mit dem Attribut rel="nofollow"
ausgeliefert. Keine Spur von noopener
oder noreferrer
.
Heißt also: Eigentlich egal, für welche Version ihr euch entschieden habt: Hand anlegen an eure Links solltet ihr in jedem Fall. Das ist natürlich ziemlich mühselig, wenn man es manuell macht, vor allem, wenn ihr regelmäßig neue Inhalte publiziert. Für statische Seiten kann man einmal einen Suchen&Ersetzen-Lauf (zum Beispiel mit dem entsprechenden Plugin) über die Seite schicken. Bei ständig neuen Inhalten müsst ihr das aber dann bei jedem neuen Beitrag wieder beachten – und die Kommentarfunktion betreffen die damit vorgenommenen Änderungen auch nicht.
Die aus meiner Sicht derzeit sinnvollste Lösung für dieses Problem bietet das Plugin WP External Links. Damit könnt ihr nämlich das Verhalten eurer Links ziemlich genau definieren und sehr präzise festlegen, welcher Art von Links welche Attribute mitgegeben werden können. Das Plugin unterscheidet zwischen internen und externen Links, lässt besondere Regelungen für Ausnahmen zu (hilfreich zum Beispiel, wenn ihr bestimmte Affiliate-Links anders behandeln möchtet) – und bezieht in die Änderungen auch die Kommentarfunktion mit ein. Genau das, was wir an dieser Stelle brauchen.
[box] Das Attributnoopener
solltet ihr euren Links auf jeden Fall mitgeben, denn abgesehen von der behobenen Sicherheitslücke bringt das noopener
-Attribut offensichtlich sogar noch Performance-Vorteile mit sich.[/box]
rel=noopener bringt nicht nur Sicherheits-, sondern auch Performance-Vorteile. #ReverseTabnabbing Klick um zu Tweeten
Und ohne WordPress?
Baut ihr eure Website selber „from scratch“, habt ihr die Kontrolle über eure Links ja ohnehin selbst in der Hand – je nachdem, wie eure Risikoeinschätzung und eure Prioritäten liegen, solltet ihr diese im Zweifel entsprechend anpassen. Wenn die Entscheidung einmal gefallen ist, dürfte das mit einem entsprechenden Suchen&Ersetzen-Durchlauf kein Riesenaufwand sein. Wenn ihr ein anderes CMS verwendet, lohnt sich ein Blick in den Quelltext, um festzustellen, wie mit den target="_blank"
-Links umgegangen wird und ob zum Beheben des Sicherheitsrisikos – oder zum Abfedern von Problemen bei fehlenden Referrer-Angaben – noch Maßnahmen nötig sind.
Fazit
Der mit der 4.7.4-Version von WordPress vorgenommene Einbau von rel="noopener noreferrer"
in den TinyMCE-Editor wirkt ein bisschen wie ein Schnellschuss, dessen Sinn sich nicht direkt erschließt. Die Auswirkungen auf Analytics-Tools und Affiliate-Programme sind nicht wirklich geklärt, vor allem aber schützt der Einbau in den Editor den am meisten gefährdeten Bereich, nämlich die Kommentarsektion, gar nicht. Wer das Risiko dort absichern möchte, wo es entsteht, muss also selber aktiv werden – beispielsweise durch Einsatz eines Plugins wie WP External Links. Was der Einbau der neuen Attribute definitiv gebracht hat: Aufmerksamkeit für die potenzielle Reverse-Tabnabbing-Gefahr. Ist ja auch ein Verdienst.
Und weil die Frage immer wieder auftaucht: Nein – SEO-Probleme birgt die Änderung nicht.
Update (12.05.2017): Offenbar wird seit Firefox-Version 52 sehr wohl auch rel="noopener
"
unterstützt. Es gibt also eigentlich gar keinen Grund mehr, noreferrer
ebenfalls zu ergänzen. Warum das WordPress-Update beide Attribute enthält, ist deshalb umso weniger verständlich. In Sachen Sicherheit dürfte somit überhaupt nichts dagegen sprechen, die von WP geänderten Links dahingehend anzupassen, dass sie nur noch das Attribut noopener
enthalten – beispielsweise über das Plugin WP External Links.
28.04.2017 | rel=”noreferrer noopener”: SEO issues after WordPress 4.7.4 Update?
28.04.2017 | NoOpener NoReferrer In Our Links!
26.04.2017 | Why am I seeing rel=”noopener noreferrer” in my WordPress links?
29.01.2017 | Links absichern mit rel=“noopener“
11.09.2016 | The target=“_blank“ vulnerability by example
KF/ciq
- SEO lernen beim SEO-Mittwoch. Und warum SEO jetzt mittwochs stattfindet. - 15. November 2023
- Warum ist es wichtig, für mehr Klimaschutz zu demonstrieren? - 6. September 2023
- SEO lernen in Zeiten von KI. Lohnt sich das noch? - 18. Juli 2023
Das lustige ist, jedesmal wenn ich mich mit WordPress halbwegs angefreundet habe und die bequemlichkeiten dieses doch fertigen CMS bei all seinen Einschränkungen und Korsettstangen zu schätzen lerne, dann kommt irgend so ein Ding um die Ecke und ich mach die nächsten Projekte mit viel Elan wieder mit meinem eigenem CMS – da habe ich wenigstens volle Kontrolle. Das Plugin werde ich aber für die bestehenden Seiten mal ausprobieren. Zwar finde ich den Codeschnipsel für die funktions.php sehr charmant, aber wenn man dann mal das Theme wechselt vergisst man garantiert, dass dieser in der Child-Funktions schlummert.
Schönen Tag noch und viele Grüße, Bella
Hallo Bella,
ja, das Gefühl kenne ich. 🙂 – Anpassungen in der Child-Functions versuche ich auch nach Möglichkeit zu vermeiden. In diesem Fall spricht aus meiner Sicht auch die Sicherheitsfrage dagegen, die WP-Änderungen einfach wieder rückgängig zu machen. Deshalb mein Plädoyer für eine individuellere Herangehensweise…
Viele Grüße
Katja
Hi Katja, super recherchierter Artikel. Der Performance Vorteil war mir noch nicht bekannt, danke! Ich habe mich in den letzten Tagen auch mit dem Thema beschäftigt und unter anderem das von dir verlinkte Plugin getestet. Mir fehlte die Möglichkeit die Attribute einzeln für bestimmte Links definieren zu können. Also habe ich angefangen ein eigenes Plugin dafür zu entwickeln. Das Plugin klinkt sich in den Link-Dialog des Editors ein und ermöglicht es für jeden Link die Werte „noopener“ und „noreferrer“ für das rel Attribut selbst zu bestimmen.
Ich würde mich freuen wenn du dir das ganze ansiehst und mir Feedback dazu gibst: https://www.chingin.de/blog/advanced-link-attributes/
Übrigens bleibt mit dieser Lösung erstmal alles so wie es von WordPress seit dem letzten Update vorgesehen ist, außer man bestimmt manuell für einen Link die Werte zu entfernen. Das hat den Vorteil dass man die Möglichkeit hat bei „sicheren“ Linkzielen selbst zu entscheiden. Für Affiliates ist das meiner Meinung nach eine gute Lösung.
Hallo Timm,
danke für das ausführliche Feedback! Deine Plugin-Lösung klingt nach einer super Möglichkeit, das noreferrer-Problem zum Beispiel für Affiliate-Links individuell zu beheben, finde ich gut. In eingeschränktem Rahmen ermöglicht WP External Links das über die Ausnahmen ja auch, aber natürlich lange nicht so flexibel und individuell.
Was mir allerdings an WP External Links sehr gut gefällt, ist die Tatsache, dass die Einstellungen sich auch auf Links außerhalb des Editors (wie z.B. in den Kommentaren) auswirken, das fand ich eigentlich am WP-Update die größte Schwachstelle, dass es die eigentlich doch am meisten gefährdete Kommentarsektion unangetastet lässt.
Hast Du denn schon ausprobiert, ob die beiden Plugins sich miteinander vertragen? Dann wäre Deins ja die perfekte Ergänzung.
Viele Grüße
Katja
Leider ist es so dass WP External Links einen Filter während der Ausgabe des Textes anwendet der die Einstellungen die im Link-Dialog vorgenommen wurden überschreibt. Das heißt die Regeln vom WP External Plugin werden die attribute welche im Editor über mein Plugin gesetzt wurden überschreiben.
Ja, die Kommentare sind tatsächlich natürlich ein großer Schwachpunkt. Ich sammle gerade Features um welche ich das Pugin noch erweitern kann. Jetzt stehen die Kommentare mit auf der Liste, vielen Dank 🙂
Hmm, hatte ich befürchtet, dass die beiden sich nicht kombinieren lassen. Falls Du das Plugin um die Kommentarproblematik erweitert bekommst, sag mal Bescheid. 🙂
Liebe Katja,
danke für den ausführlichen Beitrag zum Thema. Es beschäftigt mich auch gerade. Ich habe dazu auch schon einiges gelesen und bin unschlüssig, was ich in Zukunft meinen Kunden raten soll. Es muss tatsächlich genau abgewogen werden, worauf der Fokus liegt – Analytics, Affiliate-Links etc.
Kleine Korrektur: Auch Enfold setzt die neuen Links, denn in vielen Module wird ebenfalls der TinyMCE genutzt. Ich habe es gerade noch mal überprüft.
Liebe Grüße,
Renate
Liebe Renate,
danke für den Hinweis, habe ich direkt korrigiert – den Code habe ich bei Enfold tatsächlich nicht überprüft, mea culpa.
Liebe Grüße
Katja
Es gibt ein Update zum Thema: Offenbar ist nämlich seit der Firefox-Version 52 „noreferrer“ überhaupt nicht mehr notwenig, weil Firefox nun auch „noopener“ unterstützt. Siehe oben.
„noreferrer“ wird anscheinend wohl auch gar nicht mehr gesetzt, zumindest bei mir im Blog nicht. Ist das bei auch so?
Hallo Tobi,
da hast Du recht – inzwischen wird auch bei mir nur noch „rel=noopener“ gesetzt, ohne „noreferrer“. Scheint fast, als hätte WP bei einem der letzten Updates still und heimlich das umstrittene „noreferrer“ wieder rausgenommen – still und heimlich deshalb, weil ich ich in den Release Notes und Changelogs der letzten Updates seit 4.7.4 keine Infos zu einer Änderung finden kann.
Da ich zwischenzeitlich meine Links über das Plugin „WP External Links“ individuell gesteuert habe, ist mir die Änderung bislang noch gar nicht aufgefallen.
Warum das vor allem auch nach dem lauten Aufschrei aus der Affiliate-Szene zum Thema „noreferrer“ nicht in irgendeiner Form kommuniziert wurde, ist mir allerdings ein Rätsel…
Danke für den Hinweis und viele Grüße
Katja
Als kleinen Hinweis: External Links hat einen Kompatibilitätsproblem mit wpSEO. Wenn man bei wpSEO die nofollow option aktiviert und nutzt, dann wird ein Teil des Attributs das wpSEO setzt durch das automatische _blank von External Links überschrieben. Sprich, das nofollow Attribut wird beim link nicht mit rel=“nofollow“ sondern nur mit nofollow“ hinter dem Link eingefügt und funktioniert entsprechend nicht korrekt und der LInk ist somit ein follow Link. Ich habe daher External Links wieder runter geschmissen. Beste Grüße
Danke für den Hinweis!
Muss mich kurz konkretisieren, da ich mich gerade vertan habe: WP External Links funktioniert, External Links (ohne WP) hat den Konflikt mit dem SEO Plugin wpSEO. Sorry! Das sind zwei verschiedene Plugins!
Dann sollte man wohl nur den Noopener Tag verwenden und einfach auf den Noreferrer Tag verzichten. Macht auch gar keinen Sinn beides mit auszuliefern, da der Referrer Tag immer wertvolle Informationen mit übergibt. Da sind wohl die WordPress Entwickler wieder über as Ziel hinaus geschossen. Der Noopener Tag bezieht sich jedoch nur auf die von der Sicherheitslücke betroffenen Windows Komponente.
Bei Amazon wird die Publisher-ID, also die ID, die benötigt wird, um zu wissen, wer das Produkt empfohlen hat, per HTTP GET übertragen. Dieser wird auch mit der alten WordPress-Version übertragen. Bei Amazon dürfte es also in keinem Fall zu Einbußen kommen, jedoch zu Skepsis bei Amazon, wenn keine Referrer mit übertragen würden. Dann wird vermutlich nur der Account genauer überprüft und wenn es sich um eine WordPress-Seite handelt, ist alles wieder im grünen Bereich 🙂