Im letzten Beitrag haben wir die Anfälligkeit von Webseiten für Cross-Site Scripting (XSS) behandelt, durch das Angreifer Nutzerdaten stehlen konnten – dank Frameworks wie Angular wurden effektive Sicherheitsmechanismen eingeführt. Doch die Angreifer geben nicht auf und müssen nun deutlich mehr Aufwand betreiben, um ihre Webseitenbesucher mit bösartigen JavaScript-Code zu infiltrieren. Das iframe-Sandbox bietet dabei einen noch stärkeren Sicherheitsrahmen, um potenziell gefährliche Inhalte von Drittanbietern auf ihrer Webseite zu isolieren.
Die Story geht weiter
Du bist Nutzer:in eines Online Shops: Du bist begeistert von der neuen Winterkollektion deines Lieblings-Online-Shops, möchtest das Shirt vor dem Kauf aber lieber nochmal im Geschäft anprobieren. Du entdeckst im Online-Shop eingebunden eine interaktive Karte mit einer kompakten Übersicht aller Geschäfte in deiner Nähe. Wie praktisch – oder?
Was du nicht weißt: Diese Karte stammt gar nicht vom Online-Shop selbst, sondern von einem Entwickler-Team eines externen Unternehmens. Dieses priorisiert das Ausrollen neuer Features höher als die Wartung und das Beheben von Bugs, sodass das Schließen von Sicherheitslücken lange auf sich warten lässt. Und die Angreifenden liegen immer auf der Lauer – ihr Ziel sind nun aber nicht mehr die von dir geschriebenen Software-Module, sondern die Abhängigkeiten deines Projektes. Durch das Öffnen der interaktiven Karte hat sich nun also wieder eine neue, potenzielle Sicherheitslücke ergeben. Im Folgenden zeigen wir dir, wie du diese Sicherheitslücke mithilfe eines iframe sandbox in einen geschützten Raum verlagern kannst, um deine IT-Sicherheit mit proaktivem XSS-Schutz zu verbessern.
Updates gegen Sicherheitslücken
Öffentlich bekannte Sicherheitslücken werden in das CVE-System gepflegt. CVE steht für “Common Vulnerabilities and Exposures” (Gemeinsame Schwachstellen und Expositionen). Es handelt sich um eine öffentliche und weit verbreitete Identifizierungssystematik für Sicherheitslücken und Schwachstellen in Software und Hardware. CVE-Einträge enthalten normalerweise keine detaillierten Informationen über die Schwachstellen selbst. Stattdessen dienen sie als Verweis auf detailliertere Sicherheitsberichte und Informationen, die von den betroffenen Softwareherstellern oder anderen Sicherheitsorganisationen bereitgestellt werden. Vor der Publizierung eines CVEs wird in der Regel das Entwicklerteam der Software kontaktiert und bekommt Zeit eine gepatchte Version herauszubringen. Schafft das Team dies nicht, wird die entdeckte Lücke trotzdem veröffentlicht. Bestenfalls reagiert das Team schnell und die Lücke wird geschlossen bevor sie publik gemacht wird. Ob diese aber vor ihrer Entdeckung aktiv ausgenutzt wurde, ist schwer nachzuvollziehen.
Wenn Updates nicht ausreichen
Du bist Entwickler:in: du hast eine interaktive Tankstellenkarte als iframe bei dir auf der Webseite eingebunden. Das Entwicklerteam dieser Karte gehört zu einem großen Unternehmen, mit dem du einen Exklusivitätsvertrag unterschrieben hast. Dieses priorisiert das Ausrollen neuer Features höher als die Wartung und das Beheben von Bugs, sodass Sicherheitslücken lange offen bleiben.
Als Angreifer:in ist dir die Praxis des Teams bekannt und möchtest dies gerne ausnutzen. Wenn es nach dir ginge, soll die Karte mehr als nur den Code vom Kartenteam auf den Kundenrechnern ausführen.
Sandbox für iframe-s
Du bist Entwickler:in: du hast für diesen Fall schon vorgesorgt. Du kennst und nutzt das “sandbox”-Attribut eines iframe-s.
Handelt es sich um den Inhalt eines Drittanbieters auf deiner Webseite, so sorgt das “sandbox”-Attribut für besseren Schutz bei eingebetteten Inhalten (iframe).
<iframe src="https://beispiel.com" sandbox="..."> <!-- Inhalt des iframes wird hier platziert --> </iframe>
Das “sandbox”-Attribut akzeptiert eine durch Leerzeichen getrennte Liste von Werten, die die Beschränkungen festlegen, die auf den Inhalt innerhalb des iframe-s angewendet werden sollen. Diese Werte können Folgendes umfassen:
allow-same-origin: Ermöglicht dem iframe das Anfordern von Inhalten der gleichen Herkunft wie der übergeordneten Seite. Dies ist normalerweise erforderlich, um die Kommunikation zwischen der übergeordneten Seite und dem iframe zu ermöglichen.allow-scripts: Erlaubt die Ausführung von JavaScript im iframe. Ohne diesen Wert ist JavaScript im iframe deaktiviert.allow-forms: Erlaubt Formularübermittlungen im iframe.allow-modals: Ermöglicht dem iframe das Anzeigen von modalen Dialogfeldern.allow-popups: Ermöglicht dem iframe das Öffnen neuer Browserfenster oder Tabs.allow-popups-to-escape-sandbox: Erlaubt Popups, außerhalb der Sandbox des iframe-s geöffnet zu werden.allow-pointer-lock: Erlaubt dem iframe die Verwendung der Pointer Lock API.allow-top-navigation: Ermöglicht dem iframe das Navigieren im Top-Level-Fenster. Ohne diesen Wert kann das iframe nicht die URL der übergeordneten Seite ändern.
Je nach den gewünschten Beschränkungen für den Inhalt des iframe-s können Sie einen oder mehrere dieser Werte im “sandbox”-Attribut angeben.
Zum Beispiel:html<iframe src="https://beispiel.com" sandbox="allow-same-origin allow-scripts"></iframe>
In diesem Beispiel darf das iframe JavaScript ausführen und Inhalte der gleichen Herkunft wie die deiner Seite anfordern. Andere Funktionen wie Formularübermittlungen, Popups und Navigation auf fremden Webseiten sind deaktiviert. Und schon ist der nächste Angriff abgewehrt, trotz kompromittierem iframe.
Stay tuned!
Aber die Angreifer sind hartnäckig und fokussieren nun die anderen Abhängigkeiten der Website. Erfahre im nächsten Beitrag, ob das beliebte Quietsche-Entchen-Generator-Modul des Online-Shops, eine Abhängigkeit mit vielen Sicherheitslücken, vor den Angreifern gerettet werden kann.
Schreib uns eine Mail – wir freuen uns auf deine Nachricht! hello@qualityminds.de oder auf LinkedIn