
Proof-of-Concept für Content-Hijacking mit Flash, PDF und Silverlight
Veröffentlicht unter AGPL (siehe LICENSE für weitere Informationen).
Dieses Projekt kann verwendet werden, um einen Proof of Concept für Folgendes zu liefern:
Hinweis: .XAP-Dateien können in eine beliebige andere Erweiterung umbenannt werden, aber sie können nicht mehr domänenübergreifend geladen werden. Es scheint, dass Silverlight die Dateierweiterung anhand der bereitgestellten URL ermittelt und sie ignoriert, wenn sie nicht .XAP ist. Dies kann weiterhin ausgenutzt werden, wenn eine Website es Benutzern erlaubt, ";" oder "/" nach dem tatsächlichen Dateinamen zu verwenden, um eine ".XAP"-Erweiterung hinzuzufügen.
Hinweis: .XAP-Dateien können in eine beliebige andere Erweiterung umbenannt werden, aber sie können nicht mehr domänenübergreifend geladen werden. Es scheint, dass Silverlight die Dateierweiterung anhand der bereitgestellten URL ermittelt und sie ignoriert, wenn sie nicht .XAP ist. Dies kann weiterhin ausgenutzt werden, wenn eine Website es Benutzern erlaubt, ";" oder "/" nach dem tatsächlichen Dateinamen zu verwenden, um eine ".XAP"-Erweiterung hinzuzufügen.
Hinweis: Wenn Silverlight eine .XAP-Datei domänenübergreifend anfordert, muss der Inhaltstyp wie folgt sein: application/x-silverlight-app.
Hinweis: PDF-Dateien können nur im Adobe Reader Viewer verwendet werden (sie funktionieren nicht mit den integrierten PDF-Viewern von Chrome und Firefox).
Hinweis: Das Lesen statischer Inhalte oder öffentlich zugänglicher Daten kann nicht als Problem betrachtet werden. Es ist wichtig, falsch-positive Ergebnisse aus Ihren Advisories zu entfernen. Beachten Sie, dass die alleinige Verwendung eines Sternchens ("*") im "Access-Control-Allow-Origin"-Header kein Problem darstellt.
Verwendungsbeispiel:
Die Dateitypen, die hochgeladen werden dürfen, sollten auf diejenigen beschränkt werden, die für die Geschäftsfunktionalität erforderlich sind.
Die Anwendung sollte Filterung und Inhaltsprüfung für alle Dateien durchführen, die auf den Server hochgeladen werden. Dateien sollten gründlich gescannt und validiert werden, bevor sie anderen Benutzern zur Verfügung gestellt werden. Im Zweifelsfall sollte die Datei verworfen werden.
Das Hinzufügen der Header "Content-Disposition: Attachment" und "X-Content-Type-Options: nosniff" zur Antwort statischer Dateien sichert die Website gegen Flash- oder PDF-basierte Cross-Site-Content-Hijacking-Angriffe. Es wird empfohlen, diese Vorgehensweise für alle Dateien anzuwenden, die Benutzer in allen Modulen, die sich mit Dateidownloads befassen, herunterladen müssen. Obwohl diese Methode die Website nicht vollständig gegen Angriffe mit Silverlight oder ähnlichen Objekten absichert, kann sie das Risiko der Verwendung von Adobe Flash- und PDF-Objekten verringern, insbesondere wenn das Hochladen von PDF-Dateien erlaubt ist.
Flash/PDF (crossdomain.xml) oder Silverlight (clientaccesspolicy.xml) Cross-Domain-Richtliniendateien sollten entfernt werden, wenn sie nicht verwendet werden und keine geschäftliche Anforderung für Flash- oder Silverlight-Anwendungen besteht, mit der Website zu kommunizieren.
Der domänenübergreifende Zugriff sollte auf eine minimale Menge vertrauenswürdiger Domänen beschränkt werden, die Zugriff benötigen. Eine Zugriffsrichtlinie gilt als schwach oder unsicher, wenn ein Platzhalterzeichen verwendet wird, insbesondere im Wert des Attributs "uri".
Jede "crossdomain.xml"-Datei, die für Silverlight-Anwendungen verwendet wird, sollte als schwach betrachtet werden, da sie nur ein Platzhalterzeichen ("*") im Domain-Attribut akzeptieren kann.
Das Browser-Caching sollte für die corssdomain.xml- und clientaccesspolicy.xml-Dateien deaktiviert werden. Dies ermöglicht es der Website, die Datei bei Bedarf einfach zu aktualisieren oder den Zugriff auf die Webdienste einzuschränken. Sobald die Clientzugriffsrichtliniendatei geprüft wurde, bleibt sie für die Browsersitzung in Kraft, sodass die Auswirkungen des Nicht-Cachings auf den Endbenutzer minimal sind. Dies kann je nach Inhalt der Zielwebsite sowie Sicherheit und Komplexität der Richtliniendatei(en) als geringes oder informatives Risiko gemeldet werden.
CORS-Header sollten so überprüft werden, dass sie nur für statische oder öffentlich zugängliche Daten aktiviert sind. Andernfalls sollte der "Access-Control-Allow-Origin"-Header nur autorisierte Adressen enthalten. Andere CORS-Header wie "Access-Control-Allow-Credentials" sollten nur verwendet werden, wenn sie erforderlich sind. Elemente innerhalb der CORS-Header wie "Access-Control-Allow-Methods" oder "Access-Control-Allow-Headers" sollten überprüft und entfernt werden, wenn sie nicht erforderlich sind.
Hinweis: Die Verwendung des "Referer"-Headers kann keine Lösung sein, da es möglich ist, diesen Header beispielsweise durch das Senden einer POST-Anfrage mit Adobe Reader und PDF zu setzen (siehe die Datei "xfa-manual-ContentHijacking.pdf" im Verzeichnis "objects"). Update: Das Setzen des "Referer"-Headers wurde von Adobe behoben, es sei denn, Sie finden auch einen Bypass dafür ;)
Aktuelle Updates/Hilfe finden Sie auf der Projektseite: https://github.com/nccgroup/CrossSiteContentHijacking
Soroush Dalili (@irsdl) von der NCC Group
Schon das Hochladen einer JPG-Datei kann zu Cross-Domain-Data-Hijacking führen (Client-seitiger Angriff)! https://soroush.secproject.com/blog/2014/05/even-uploading-a-jpg-file-can-lead-to-cross-domain-data-hijacking-client-side-attack/
Mehrere PDF-Schwachstellen – Text und Bilder auf Steroiden http://insert-script.blogspot.co.at/2014/12/multiple-pdf-vulnerabilites-text-and.html
HTTP-Kommunikation und Sicherheit mit Silverlight http://msdn.microsoft.com/en-gb/library/cc838250(v=vs.95).aspx
Erklärung von Cross-Domain- und Client-Zugriffsrichtliniendateien für Silverlight http://www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight
Spezifikation der Cross-Domain-Richtliniendatei http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Festlegen einer crossdomain.xml-Datei für HTTP-Streaming http://www.adobe.com/devnet/adobe-media-server/articles/cross-domain-xml-for-streaming.html
Ausnutzen von CVE-2011-2461 auf google.com http://blog.mindedsecurity.com/2015/03/exploiting-cve-2011-2461-on-googlecom.html