Beitrag 10 von 15: Sicher ist sicher – Sicherheitsaspekte beim Einsatz von iframes

Beitrag 10: Sicher ist sicher – Sicherheitsaspekte beim Einsatz von iframes

Iframes sind ein mächtiges Werkzeug, um Inhalte von einer Quelle in eine andere einzubetten. Wie bei vielen mächtigen Werkzeugen im Web gibt es jedoch auch potenzielle Sicherheitsrisiken, die man kennen und berücksichtigen muss. Da unser Zentralmenü über einen iframe von `studioenns.eu` in unsere verschiedenen WordPress-Seiten geladen wird, wollen wir uns heute die Sicherheitsaspekte dieser Technologie genauer ansehen. Welche Risiken bestehen theoretisch, und wie stellen wir sicher, dass der Einsatz des Zentralmenü-iframes für unsere Seiten und deren Besucher sicher ist?

Die Same-Origin Policy als grundlegender Schutz

Das wichtigste Sicherheitskonzept im Webbrowser in Bezug auf Frames und Skripting ist die **Same-Origin Policy (SOP)**. Vereinfacht gesagt, erlaubt die SOP Skripten (JavaScript) von einer Webseite nur dann den Zugriff auf Inhalte und Eigenschaften einer anderen Webseite (z.B. innerhalb eines iframes), wenn beide Webseiten denselben „Origin“ haben. Ein Origin wird durch das Protokoll (http/https), den Hostnamen (Domain) und den Port definiert.

In unserem Fall:

• Die WordPress-Seite läuft z.B. auf `https://projekt-a.studioenns.info`.
• Der iframe-Inhalt kommt von `https://studioenns.eu/zentralmenue/home.html`.

Da die Hostnamen (`projekt-a.studioenns.info` vs. `studioenns.eu`) unterschiedlich sind, handelt es sich um **unterschiedliche Origins**. Die Same-Origin Policy greift und verhindert standardmäßig, dass:

• JavaScript auf der WordPress-Seite direkt auf den DOM-Baum (den HTML-Inhalt) des iframes zugreift oder dessen Skripte manipuliert.
• JavaScript innerhalb des iframes (in `home.html`) direkt auf den DOM-Baum der umgebenden WordPress-Seite zugreift oder deren Cookies liest.

Diese Trennung ist ein fundamentaler Schutzmechanismus, der viele potenzielle Angriffe verhindert.

Potenzielle Risiken im Zusammenhang mit iframes

Trotz der SOP gibt es Szenarien und Angriffsvektoren, die im Zusammenhang mit iframes relevant sein können, insbesondere wenn man Inhalte von *Drittanbietern* einbettet:

1. Clickjacking (UI Redress Attack): Hierbei wird eine transparente oder unsichtbare iframe-Seite über eine legitime Seite gelegt. Der Angreifer versucht, den Nutzer dazu zu bringen, auf Elemente der unsichtbaren iframe-Seite zu klicken (z.B. einen „Gefällt mir“-Button oder einen gefährlichen Bestätigungs-Dialog), während der Nutzer glaubt, er interagiere mit der sichtbaren, legitimen Seite darunter.

   Schutz: Moderne Browser implementieren Schutzmechanismen. Webseiten können sich zusätzlich durch den `X-Frame-Options` HTTP-Header oder die `frame-ancestors`-Direktive in der Content Security Policy (CSP) schützen. Diese Header teilen dem Browser mit, ob die Seite überhaupt in einem Frame (von welcher Quelle) dargestellt werden darf.

2. Phishing über iframes: Ein Angreifer könnte versuchen, eine bösartige Webseite (z.B. eine gefälschte Login-Seite) in einem iframe auf einer ansonsten harmlos aussehenden Seite einzubetten, um Zugangsdaten abzugreifen.

   Schutz: Die SOP verhindert zwar den direkten Zugriff auf Daten der Hauptseite, aber der Nutzer könnte getäuscht werden. Wachsamkeit und Browser-Warnungen helfen. Auch hier können `X-Frame-Options` und CSP auf der potenziell eingebetteten (bösartigen) Seite deren Einbettung verhindern.

3. Malware-Verbreitung: Wenn der Inhalt, der im iframe geladen wird, von einer kompromittierten oder bösartigen Quelle stammt, könnte dieser Inhalt versuchen, Schwachstellen im Browser auszunutzen (Drive-by-Downloads).

   Schutz: Nur Inhalte aus vertrauenswürdigen Quellen einbetten! Browser-Sicherheitsupdates aktuell halten.

4. Ressourcen-Erschöpfung (Denial of Service): Eine schlecht programmierte oder bösartige iframe-Seite könnte versuchen, exzessiv Ressourcen (CPU, Speicher) zu verbrauchen und so die Hauptseite oder den Browser zum Absturz zu bringen.

   Schutz: Einbettung nur von vertrauenswürdigen Quellen. Browser haben oft Mechanismen, um außer Kontrolle geratene Skripte zu erkennen.

5. Informationslecks durch `Referer`-Header: Wenn ein Nutzer auf einen Link *innerhalb* des iframes klickt, der zu einer externen Seite führt, kann der `Referer`-HTTP-Header der Anfrage die URL der *Hauptseite* (die den iframe einbettet) an die externe Seite übermitteln. Dies könnte potenziell sensible Informationen in der URL preisgeben.

   Schutz: Verwendung des `Referrer-Policy`-Headers oder des `rel=“noreferrer“`-Attributs auf Links, um die Übermittlung des Referrers zu steuern.

Sicherheitsmaßnahmen für unser Zentralmenü

Die gute Nachricht ist: Da wir die Quelle des iframe-Inhalts (`https://studioenns.eu/zentralmenue/home.html`) **selbst kontrollieren**, sind viele der Risiken, die bei der Einbettung von Drittanbieter-Inhalten bestehen, für unser Zentralmenü stark reduziert oder irrelevant.

• Vertrauenswürdige Quelle: Wir wissen, dass der Code in `home.html` von uns stammt und keinen bösartigen Zweck verfolgt. Das Risiko von Malware oder Phishing durch das Menü selbst ist praktisch ausgeschlossen.
• Kontrolle über den Inhalt: Wir stellen sicher, dass das Menü keine exzessiven Ressourcen verbraucht.
• Clickjacking-Schutz (Empfehlung): Obwohl das Risiko gering ist, da wir die Quelle kontrollieren, ist es gute Praxis, auch auf der `home.html`-Seite selbst einen `X-Frame-Options: SAMEORIGIN` oder `CSP: frame-ancestors ’self‘ https://*.studioenns.info;` (angepasst an die Domains, die einbetten dürfen) Header zu setzen. Dies würde verhindern, dass *andere*, fremde Seiten unser Zentralmenü in einem iframe einbetten könnten (z.B. um uns zu imitieren).
• HTTPS verwenden: Sowohl die Hauptseiten als auch die iframe-Quelle (`home.html`) sollten über HTTPS geladen werden, um die Datenübertragung zu verschlüsseln und Man-in-the-Middle-Angriffe zu verhindern. Unser Code verwendet `https://studioenns.eu`, was gut ist.
• `sandbox`-Attribut (Optionale zusätzliche Härtung): Obwohl in unserem Code nicht vorhanden, könnten wir dem iframe-Tag das `sandbox`-Attribut hinzufügen, um die Rechte des iframe-Inhalts weiter einzuschränken. Beispiel:

  <iframe src="..." ... sandbox="allow-scripts allow-same-origin allow-popups"></iframe>

  Dies würde z.B. standardmäßig Formularübermittlung, Pointer Lock, Top-Navigation etc. blockieren und nur explizit erlaubte Fähigkeiten freischalten (`allow-scripts` für JavaScript im Menü, `allow-same-origin`, damit es auf Ressourcen von `studioenns.eu` zugreifen kann, `allow-popups` falls Links im Menü neue Fenster öffnen sollen). Für ein reines Navigationsmenü ist dies oft nicht nötig, kann aber eine zusätzliche Sicherheitsebene bieten, falls man sich Sorgen über Cross-Site-Scripting (XSS) *innerhalb* der `home.html` machen würde (was bei eigener Kontrolle unwahrscheinlich sein sollte).

• `Referrer-Policy` (Empfehlung): Setzen eines geeigneten `Referrer-Policy`-Headers auf den Hauptseiten und/oder der `home.html`, um die Weitergabe von URL-Informationen bei Klicks auf externe Links zu kontrollieren (z.B. `strict-origin-when-cross-origin`).

Fazit: Ein beherrschbares Risiko bei eigener Kontrolle

Der Einsatz von iframes birgt theoretische Sicherheitsrisiken, insbesondere wenn Inhalte von Dritten eingebettet werden. Da wir jedoch die Quelle unseres Zentralmenü-iframes (`studioenns.eu`) selbst kontrollieren und pflegen, können wir die meisten dieser Risiken ausschließen oder durch bewährte Praktiken (HTTPS, Vertrauen in die Quelle, optionale Header wie XFO/CSP/Referrer-Policy) minimieren. Die Same-Origin Policy bietet einen starken Basisschutz. Für unseren Anwendungsfall ist die iframe-Lösung unter Sicherheitsaspekten daher als gut handhabbar und vertretbar einzustufen.

Im nächsten Beitrag werfen wir einen Blick auf Alternativen: Welche anderen technischen Möglichkeiten gäbe es, ein Zentralmenü zu realisieren, und warum haben wir uns für den iframe entschieden?

#Sicherheit,,,, #WebSecurity,,,, #iframe,,,, #SameOriginPolicy,,,, #Clickjacking,,,, #Phishing,,,, #XFrameOptions,,,, #ContentSecurityPolicy,,,, #HTTPS,,,, #Zentralmenü,,,, #StudioEnns,,,, #WordPress,,,, #Risikomanagement