Iframes in XSS, CSP and SOP
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Es gibt 3 Möglichkeiten, den Inhalt einer iframed Seite anzugeben:
Über src
, das eine URL angibt (die URL kann cross origin oder same origin sein)
Über src
, das den Inhalt mit dem data:
-Protokoll angibt
Über srcdoc
, das den Inhalt angibt
Zugriff auf Eltern- & Kind-Variablen
Wenn Sie das vorherige HTML über einen HTTP-Server (wie python3 -m http.server
) aufrufen, werden Sie feststellen, dass alle Skripte ausgeführt werden (da es keine CSP gibt, die dies verhindert). Der Elternteil kann nicht auf die secret
-Variable innerhalb eines iframes zugreifen und nur die iframes if2 & if3 (die als gleichseitig betrachtet werden) können auf das Geheimnis im ursprünglichen Fenster zugreifen.
Beachten Sie, dass if4 als null
-Ursprung betrachtet wird.
Bitte beachten Sie, dass in den folgenden Umgehungen die Antwort auf die iframed-Seite keinen CSP-Header enthält, der die Ausführung von JS verhindert.
Der self
-Wert von script-src
erlaubt nicht die Ausführung des JS-Codes mit dem data:
-Protokoll oder dem srcdoc
-Attribut.
Allerdings erlaubt selbst der none
-Wert der CSP die Ausführung der iframes, die eine URL (vollständig oder nur den Pfad) im src
-Attribut angeben.
Daher ist es möglich, die CSP einer Seite mit zu umgehen:
Beachten Sie, dass die vorherige CSP nur die Ausführung des Inline-Skripts erlaubt.
Allerdings werden nur die Skripte if1
und if2
ausgeführt, aber nur if1
kann auf das übergeordnete Geheimnis zugreifen.
Daher ist es möglich, eine CSP zu umgehen, wenn Sie eine JS-Datei auf den Server hochladen und sie über ein iframe laden können, selbst mit script-src 'none'
. Dies kann potenziell auch durch den Missbrauch eines Same-Site-JSONP-Endpunkts erfolgen.
Sie können dies mit dem folgenden Szenario testen, bei dem ein Cookie gestohlen wird, selbst mit script-src 'none'
. Führen Sie einfach die Anwendung aus und greifen Sie mit Ihrem Browser darauf zu:
Der Inhalt innerhalb eines iframes kann durch die Verwendung des sandbox
-Attributs zusätzlichen Einschränkungen unterworfen werden. Standardmäßig wird dieses Attribut nicht angewendet, was bedeutet, dass keine Einschränkungen bestehen.
Wenn verwendet, auferlegt das sandbox
-Attribut mehrere Einschränkungen:
Der Inhalt wird behandelt, als ob er aus einer einzigartigen Quelle stammt.
Jeder Versuch, Formulare einzureichen, wird blockiert.
Die Ausführung von Skripten ist verboten.
Der Zugriff auf bestimmte APIs ist deaktiviert.
Es verhindert, dass Links mit anderen Browsing-Kontexten interagieren.
Die Verwendung von Plugins über <embed>
, <object>
, <applet>
oder ähnliche Tags ist nicht erlaubt.
Die Navigation des übergeordneten Browsing-Kontexts des Inhalts durch den Inhalt selbst wird verhindert.
Funktionen, die automatisch ausgelöst werden, wie die Video-Wiedergabe oder das automatische Fokussieren von Formularsteuerelementen, werden blockiert.
Der Wert des Attributs kann leer gelassen werden (sandbox=""
), um alle oben genannten Einschränkungen anzuwenden. Alternativ kann er auf eine durch Leerzeichen getrennte Liste spezifischer Werte gesetzt werden, die das iframe von bestimmten Einschränkungen befreien.
Überprüfen Sie die folgenden Seiten:
Bypassing SOP with Iframes - 1Bypassing SOP with Iframes - 2Blocking main page to steal postmessageSteal postmessage modifying iframe locationLernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)