AWS Hacking'i öğrenin ve pratik yapın:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
GCP Hacking'i öğrenin ve pratik yapın: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* [**abonelik planlarını**](https://github.com/sponsors/carlospolop) kontrol edin!
* **Bize katılın** 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) veya **bizi****Twitter'da** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)** takip edin.**
Deneyimli hackerlar ve bug bounty avcıları ile iletişim kurmak için [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) sunucusuna katılın!
İçerik Güvenlik Politikası (CSP), esasen **cross-site scripting (XSS)** gibi saldırılara karşı**koruma sağlamak** amacıyla tanınan bir tarayıcı teknolojisidir. Tarayıcı tarafından güvenli bir şekilde yüklenebilecek kaynakların yollarını ve kaynaklarını tanımlayarak çalışır. Bu kaynaklar, resimler, çerçeveler ve JavaScript gibi çeşitli öğeleri kapsar. Örneğin, bir politika, aynı alan adından (self) kaynakların yüklenmesine ve çalıştırılmasına izin verebilir; bu, inline kaynakları ve `eval`, `setTimeout` veya `setInterval` gibi fonksiyonlar aracılığıyla string kodunun çalıştırılmasını içerir.
CSP'nin uygulanması, **yanıt başlıkları** aracılığıyla veya **HTML sayfasına meta öğeleri ekleyerek** gerçekleştirilir. Bu politikayı izleyerek, tarayıcılar bu şartları proaktif bir şekilde uygular ve tespit edilen ihlalleri hemen engeller.
CSP, hem aktif hem de pasif içeriğin yüklenmesi için kaynakları kısıtlar, inline JavaScript yürütmesi ve `eval()` kullanımı gibi yönleri kontrol eder. Bir örnek politika:
* **script-src**: JavaScript için belirli kaynaklara izin verir, URL'ler, satır içi scriptler ve olay işleyicileri veya XSLT stilleri tarafından tetiklenen scriptler dahil.
* **default-src**: Belirli fetch direktifleri yoksa kaynakları almak için varsayılan bir politika belirler.
* **child-src**: Web işçileri ve gömülü çerçeve içerikleri için izin verilen kaynakları belirtir.
* **connect-src**: fetch, WebSocket, XMLHttpRequest gibi arayüzler kullanılarak yüklenebilecek URL'leri kısıtlar.
* **frame-ancestors**: Geçerli sayfayı gömebilecek kaynakları belirtir, `<frame>`, `<iframe>`, `<object>`, `<embed>` ve `<applet>` gibi öğelere uygulanır.
*`*`: `data:`, `blob:`, `filesystem:` şemaları dışındaki tüm URL'lere izin verir.
*`'self'`: Aynı alan adından yüklemeye izin verir.
*`'data'`: Veriler şeması aracılığıyla kaynakların yüklenmesine izin verir (örneğin, Base64 kodlu resimler).
*`'none'`: Herhangi bir kaynaktan yüklemeyi engeller.
*`'unsafe-eval'`: `eval()` ve benzeri yöntemlerin kullanılmasına izin verir, güvenlik nedenleriyle önerilmez.
*`'unsafe-hashes'`: Belirli satır içi olay işleyicilerini etkinleştirir.
*`'unsafe-inline'`: Satır içi `<script>` veya `<style>` gibi satır içi kaynakların kullanılmasına izin verir, güvenlik nedenleriyle önerilmez.
*`'nonce'`: Kriptografik bir nonce (bir kez kullanılan sayı) kullanarak belirli satır içi scriptler için bir beyaz liste.
* JS sınırlı yürütme varsa, sayfa içinde kullanılan bir nonce almak mümkündür `doc.defaultView.top.document.querySelector("[nonce]")` ile ve ardından kötü niyetli bir script yüklemek için yeniden kullanılabilir (strict-dynamic kullanılıyorsa, herhangi bir izin verilen kaynak yeni kaynaklar yükleyebilir, bu nedenle bu gerekli değildir), örneğin:
*`'report-sample'`: İhlal raporunda ihlal eden kodun bir örneğini içerir (hata ayıklama için yararlıdır).
*`'strict-origin'`: 'self' ile benzer ancak kaynakların protokol güvenlik seviyesinin belgeyle eşleşmesini sağlar (yalnızca güvenli kökenler güvenli kökenlerden kaynak yükleyebilir).
*`'strict-origin-when-cross-origin'`: Aynı kökenli istekler yapıldığında tam URL'leri gönderir, ancak istek çapraz köken olduğunda yalnızca kökeni gönderir.
*`'unsafe-allow-redirects'`: Hemen başka bir kaynağa yönlendirecek kaynakların yüklenmesine izin verir. Güvenliği zayıflattığı için önerilmez.
Eğer bir şekilde **izin verilen JS kodu, DOM'da yeni bir script etiketi oluşturuyorsa** ve bu izin verilen script onu oluşturuyorsa, **yeni script etiketi çalıştırılmaya izin verilecektir**.
Ayrıca, sunucu tarafından kabul edilen bir uzantı kullanarak bir dosya içinde **JS kodu yükleyebilseniz bile** (örneğin: _script.png_), bu yeterli olmayacaktır çünkü bazı sunucular, apache sunucusu gibi, **dosyanın MIME türünü uzantıya göre seçer** ve Chrome gibi tarayıcılar, bir görüntü olması gereken bir şeyin içinde **Javascript** kodunu **çalıştırmayı reddeder**. "Umarım", hatalar vardır. Örneğin, bir CTF'den öğrendiğim kadarıyla **Apache,**_**.wave**_ uzantısını**bilmez**, bu nedenle onu **MIME türü olarak audio/\*** ile sunmaz.
Buradan, bir XSS ve dosya yüklemesi bulursanız ve **yanlış yorumlanan bir uzantı** bulmayı başarırsanız, o uzantıyla bir dosya yüklemeyi ve script'in içeriğini denemek isteyebilirsiniz. Ya da, sunucu yüklenen dosyanın doğru formatını kontrol ediyorsa, bir polyglot oluşturabilirsiniz ([bazı polyglot örnekleri burada](https://github.com/Polydet/polyglot-database)).
Eğer JS enjekte etmek mümkün değilse, örneğin kimlik bilgilerini **bir form eylemi enjekte ederek** dışarı sızdırmayı deneyebilirsiniz (ve belki şifre yöneticilerinin şifreleri otomatik doldurmasını bekleyebilirsiniz). [**Bu raporda bir örnek bulabilirsiniz**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Ayrıca, `default-src`'nin form eylemlerini kapsamadığını unutmayın.
#### Angular kullanarak ve `window` nesnesini döndüren fonksiyonlar içeren bir kütüphane ile payloadlar ([bu yazıya göz atın](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
Yazı, `cdn.cloudflare.com` (veya başka bir izin verilen JS kütüphaneleri deposu) üzerinden **tüm kütüphaneleri****yükleyebileceğinizi**, her kütüphaneden eklenen tüm fonksiyonları çalıştırabileceğinizi ve **hangi kütüphanelerden hangi fonksiyonların `window` nesnesini döndürdüğünü** kontrol edebileceğinizi gösteriyor.
[**bu CTF yazımına**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=es&\_x\_tr\_pto=wapp#noteninja-3-solves) göre, CSP içinde [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) kullanarak CSP'yi atlayarak rastgele JS kodu çalıştırabilirsiniz:
Google Apps Script'i, script.google.com içindeki bir sayfada bilgi almak için kötüye kullanmak mümkündür. Bunu [bu raporda olduğu gibi](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/) yapabilirsiniz.
Scenarios like this where `script-src` is set to `self` and a particular domain which is whitelisted can be bypassed using JSONP. JSONP uç noktaları, bir saldırganın XSS gerçekleştirmesine olanak tanıyan güvensiz geri çağırma yöntemlerine izin verir, çalışan yük:
**Güvenilir uç nokta bir Açık Yönlendirme içeriyorsa** aynı zafiyet meydana gelecektir çünkü başlangıç uç noktası güvenilir ise, yönlendirmeler de güvenilir kabul edilir.
Aşağıdaki [gönderide](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) açıklandığı gibi, CSP'de bir yerde izin verilen birçok üçüncü taraf alan adı, verileri dışarı sızdırmak veya JavaScript kodu çalıştırmak için istismar edilebilir. Bu üçüncü taraflardan bazıları şunlardır:
Hedefinizin CSP'sinde izin verilen alan adlarından herhangi birini bulursanız, üçüncü taraf hizmetine kaydolarak CSP'yi atlayabileceğiniz ve ya verileri o hizmete dışarı sızdırabileceğiniz ya da kod çalıştırabileceğiniz ihtimali vardır.
Veri sızdırma işlemini, her zaman [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/) ile yapıldığı gibi gerçekleştirebilmelisiniz. Bu durumda, aşağıdaki genel adımları izlersiniz:
2. Yeni bir "Facebook Girişi" uygulaması oluşturun ve "Web Sitesi"ni seçin.
3. "Ayarlar -> Temel" bölümüne gidin ve "Uygulama Kimliğinizi" alın.
4. Veri sızdırmak istediğiniz hedef sitede, "customEvent" ve veri yükü aracılığıyla doğrudan Facebook SDK aracı "fbq" kullanarak veri sızdırabilirsiniz.
5. Uygulamanızın "Etkinlik Yöneticisi"ne gidin ve oluşturduğunuz uygulamayı seçin (etkinlik yöneticisi, şu URL'ye 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örün.
Ardından, kurban tarafında, saldırganın Facebook geliştirici hesabı uygulama kimliğine işaret eden Facebook izleme pikselini başlatmak ve şu şekilde özel bir etkinlik oluşturmak için aşağıdaki kodu çalıştırırsınız:
Diğer yedi üçüncü taraf alan adı için, önceki tabloda belirtilen, onları kötüye kullanmanın birçok başka yolu vardır. Diğer üçüncü taraf kötüye kullanımları hakkında ek açıklamalar için önceki [blog yazısına](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) bakın.
Yukarıda bahsedilen yol kısıtlamalarını aşmak için yönlendirmeye ek olarak, bazı sunucularda kullanılabilecek başka bir teknik olan Relative Path Overwrite (RPO) vardır.
Bu, tarayıcı için `https://example.com/scripts/react/` altında bulunan `..%2fangular%2fangular.js` adlı bir dosya yüklüyorsunuz gibi göründüğü için çalışır; bu CSP ile uyumludur.
∑, bunu çözümleyecekler ve etkili bir şekilde `https://example.com/scripts/react/../angular/angular.js` isteğinde bulunacaklar, bu da `https://example.com/scripts/angular/angular.js` ile eşdeğerdir.
Eğer **base-uri** direktifi eksikse, bunu [**dangling markup injection**](../dangling-markup-html-scriptless-injection/) gerçekleştirmek için kötüye kullanabilirsiniz.
Ayrıca, eğer **sayfa bir göreli yol kullanarak bir script yüklüyorsa** (örneğin `<script src="/js/app.js">`) ve bir **Nonce** kullanıyorsanız, **base****etiketini** kötüye kullanarak scripti **kendi sunucunuzdan yüklemesini sağlayabilirsiniz ve bu bir XSS'ye yol açar.**\
Eğer savunmasız sayfa **httpS** ile yükleniyorsa, base'de bir httpS URL'si kullanın.
Content Security Policy (CSP) olarak bilinen belirli bir politika, JavaScript olaylarını kısıtlayabilir. Yine de, AngularJS alternatif olarak özel olaylar sunar. Bir olay içinde, AngularJS, yerel tarayıcı olay nesnesini referans alan benzersiz bir `$event` nesnesi sağlar. Bu `$event` nesnesi, CSP'yi aşmak için kullanılabilir. Özellikle, Chrome'da, `$event/event` nesnesi, olayın yürütme zincirinde yer alan nesne dizisini tutan bir `path` niteliğine sahiptir ve `window` nesnesi her zaman dizinin sonunda yer alır. Bu yapı, sandbox kaçış taktikleri için kritik öneme sahiptir.
Bu diziyi `orderBy` filtresine yönlendirerek, dizinin üzerinde yineleme yapmak ve terminal öğeyi (yani `window` nesnesini) kullanarak `alert()` gibi küresel bir fonksiyonu tetiklemek mümkündür. Aşağıda gösterilen kod parçası bu süreci açıklamaktadır:
Bu kod parçası, olayı tetiklemek için `ng-focus` direktifinin kullanımını vurgular, `$event.path|orderBy` kullanarak `path` dizisini manipüle eder ve `alert()` fonksiyonunu çalıştırmak için `window` nesnesini kullanarak `document.cookie`'yi açığa çıkarır.
Bir Angular JS uygulamasında script yükleme için alanları beyaz listeye alan bir CSP politikası, geri çağırma fonksiyonlarının ve belirli savunmasız sınıfların çağrılması yoluyla atlatılabilir. Bu teknikle ilgili daha fazla bilgi, bu [git deposunda](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) bulunan ayrıntılı bir kılavuzda mevcuttur.
CSP sunucu tarafı yönlendirmesiyle karşılaştığında ne olur? Eğer yönlendirme, izin verilmeyen farklı bir kaynağa yönlendiriyorsa, yine de başarısız olacaktır.
Ancak, [CSP spesifikasyonu 4.2.2.3. Yollar ve Yönlendirmeler](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) açıklamasına göre, eğer yönlendirme farklı bir yola yönlendiriyorsa, orijinal kısıtlamaları atlatabilir.
Eğer CSP `https://www.google.com/a/b/c/d` olarak ayarlandıysa, yol dikkate alındığı için hem `/test` hem de `/a/test` scriptleri CSP tarafından engellenecektir.
Ancak, son `http://localhost:5555/301`**sunucu tarafında `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`** olarak **yönlendirilecektir**. Bu bir yönlendirme olduğu için, **yol dikkate alınmaz** ve **script yüklenebilir**, böylece yol kısıtlaması aşılmış olur.
Bu nedenle, en iyi çözüm, web sitesinin herhangi bir açık yönlendirme zafiyeti olmadığından ve CSP kurallarında istismar edilebilecek herhangi bir alan adı bulunmadığından emin olmaktır.
`'unsafe-inline'` kodun içinde herhangi bir script çalıştırabileceğiniz anlamına gelir (XSS kod çalıştırabilir) ve `img-src *` ise web sayfasında herhangi bir kaynaktan herhangi bir resmi kullanabileceğiniz anlamına gelir.
Bu CSP'yi, verileri resimler aracılığıyla dışarı sızdırarak atlatabilirsiniz (bu durumda XSS, bot tarafından erişilebilen bir sayfada bir SQLi içeren bir CSRF'yi kötüye kullanır ve bir resim aracılığıyla bayrağı çıkarır):
Bu yapılandırmayı**bir resmin içine yerleştirilmiş javascript kodunu yüklemek için** de kötüye kullanabilirsiniz. Örneğin, sayfa Twitter'dan resim yüklemeye izin veriyorsa, **özel bir resim****oluşturabilir**, bunu Twitter'a **yükleyebilir** ve **JS**'yi **yüklemek**, **çıkarmak** ve **çalıştırmak** için "**unsafe-inline**"ı**kötüye kullanabilirsiniz** (normal bir XSS gibi): [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
### Service Workers ile
Service workers **`importScripts`** fonksiyonu CSP tarafından sınırlı değildir:
Eğer sizin gönderdiğiniz bir **parametre****politikanın****declaration** kısmına **yapıştırılıyorsa**, o zaman **politikayı** onu **işe yaramaz** hale getirecek şekilde **değiştirebilirsiniz**. Bu bypass'lerden herhangi biri ile **script 'unsafe-inline'****izin verebilirsiniz**:
Bu direktif mevcut script-src direktiflerini **geçersiz kılacağı** için.\
Burada bir örnek bulabilirsiniz: [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](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)
Direktifin `'unsafe-inline'` eksikliğine dikkat edin.\
Bu sefer kurbanı**kontrolünüzdeki** bir sayfayı**XSS** ile **yüklemeye** zorlayabilirsiniz. Bu sefer kurbanın bilgi almak istediğiniz sayfaya erişmesini sağlayacaksınız (**CSRF**). Sayfanın içeriğine erişemezsiniz, ancak sayfanın yüklenmesi için gereken zamanı**kontrol edebilirseniz** ihtiyacınız olan bilgiyi çıkarabilirsiniz.
Bu sefer bir **bayrak** çıkarılacak, SQLi aracılığıyla **karakter doğru tahmin edildiğinde****yanıt****daha fazla zaman** alır çünkü uyku fonksiyonu vardır. Sonra, bayrağı çıkarabileceksiniz:
Bu saldırı, saldırganın **kullanıcıyı tarayıcının yer imi üzerine bir bağlantıyı sürükleyip bırakmaya ikna etmesi** anlamına gelir. Bu yer imi, **kötü niyetli javascript** kodu içerecek ve sürüklenip bırakıldığında veya tıklandığında mevcut web penceresinin bağlamında çalıştırılacak, **CSP'yi atlayarak çerezler veya tokenlar gibi hassas bilgileri çalmaya** olanak tanıyacaktır.
[**bu CTF yazısında**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP, izin verilen bir iframe içine daha kısıtlayıcı bir CSP enjekte edilerek atlatılmaktadır; bu CSP, belirli bir JS dosyasının yüklenmesine izin vermemekte ve ardından **prototip kirlenmesi** veya **dom clobbering** yoluyla **farklı bir scriptin rastgele bir script yüklemesine** olanak tanımaktadır.
[**bu CTF yazısı**](https://github.com/aszx87410/ctf-writeups/issues/48) aracılığıyla **HTML injection** ile **CSP'yi** daha fazla **kısıtlamak** mümkün oldu, böylece CSTI'yi engelleyen bir script devre dışı bırakıldı ve bu nedenle **açık hale geldi.**\
CSP, **HTML meta etiketleri** kullanılarak daha kısıtlayıcı hale getirilebilir ve inline script'ler **kaldırılarak****giriş** devre dışı bırakılabilir, böylece onların **nonce**'ları kullanılabilir ve belirli inline script'ler **sha** ile etkinleştirilebilir:
Eğer sunucunun **`Content-Security-Policy-Report-Only`** başlığı ile **kontrol ettiğiniz bir değer** ile yanıt vermesini sağlayabilirseniz (belki bir CRLF nedeniyle), bunu sunucunuza yönlendirebilirsiniz ve eğer **sızdırmak istediğiniz****JS içeriğini****`<script>`** ile sararsanız ve CSP tarafından `unsafe-inline`'in muhtemelen izin verilmediği için, bu bir **CSP hatası** tetikleyecek ve scriptin bir kısmı (hassas bilgileri içeren) `Content-Security-Policy-Report-Only` üzerinden sunucuya gönderilecektir.
* CSP tarafından izin verilen bir URL'ye (bunu `https://example.redirect.com` olarak adlandıralım) işaret eden bir `iframe` oluşturulur.
* Bu URL daha sonra CSP tarafından **izin verilmeyen** bir gizli URL'ye (örneğin, `https://usersecret.example2.com`) yönlendirir.
*`securitypolicyviolation` olayını dinleyerek, `blockedURI` özelliğini yakalayabilirsiniz. Bu özellik, engellenen URI'nin alan adını açığa çıkararak, ilk URL'nin yönlendirdiği gizli alan adını sızdırır.
Chrome ve Firefox gibi tarayıcıların CSP ile ilgili iframeleri ele alma konusunda farklı davranışlar sergilediğini belirtmek ilginçtir; bu durum, tanımsız davranış nedeniyle hassas bilgilerin sızdırılmasına yol açabilir.
Başka bir teknik, gizli alt alan adını çıkarmak için CSP'yi istismar etmeyi içerir. Bu yöntem, belirli alan adlarını kasıtlı olarak engelleyerek CSP'yi ayarlamaya ve ikili arama algoritmasına dayanır. Örneğin, gizli alt alan adı bilinmeyen karakterlerden oluşuyorsa, CSP direktifini bu alt alan adlarını engellemek veya izin vermek için değiştirerek farklı alt alan adlarını yinelemeli olarak test edebilirsiniz. İşte bu yöntemi kolaylaştırmak için CSP'nin nasıl ayarlanabileceğini gösteren bir kod parçası:
CSP tarafından hangi isteklerin engellendiğini veya izin verildiğini izleyerek, gizli alt alan adındaki olası karakterleri daraltabilir ve nihayetinde tam URL'yi ortaya çıkarabilirsiniz.
Her iki yöntem de CSP uygulamasının ve tarayıcılardaki davranışının inceliklerini kullanarak, görünüşte güvenli politikaların nasıl istemeden hassas bilgileri sızdırabileceğini göstermektedir.
Deneyimli hackerlar ve bug bounty avcıları ile iletişim kurmak için [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) sunucusuna katılın!
Bu [**videoda yorumlanan son teknik**](https://www.youtube.com/watch?v=Sm4G6cAHjWM) göre, çok fazla parametre göndermek (1001 GET parametresi, ancak POST parametreleriyle de yapabilirsiniz ve 20'den fazla dosya). PHP web kodunda tanımlı olan **`header()`** **gönderilmeyecek** çünkü bu bir hataya neden olacaktır.
PHP, varsayılan olarak **yanıtı 4096** bayt olarak **tamponlama** ile bilinir. Bu nedenle, PHP bir uyarı gösteriyorsa, **uyarıların içine yeterli veri sağlayarak**, **yanıt****CSP başlığından önce****gönderilecektir**, bu da başlığın göz ardı edilmesine neden olur.\
Sonra, teknik esasen **CSP başlığının gönderilmemesi için yanıt tamponunu uyarılarla doldurmaktan** ibarettir.
[**bu yazıdan**](https://blog.ssrf.kr/69) anlaşıldığına göre, bir hata sayfasını (potansiyel olarak CSP olmadan) yükleyerek ve içeriğini yeniden yazarak bir CSP korumasını aşmak mümkün görünmektedir.
SOME, bir sayfanın **uç noktasında** bir XSS (veya çok sınırlı XSS) **istismar eden** bir tekniktir. Bu, saldırgan sayfasından savunmasız uç noktanın yüklenmesi ve ardından istismar etmek istediğiniz aynı kök içindeki gerçek uç noktaya saldırgan sayfasının yenilenmesiyle yapılır. Bu şekilde **savunmasız uç nokta**, **payload** içindeki **`opener`** nesnesini kullanarak **istismar etmek için gerçek uç noktanın DOM'una****erişebilir**. Daha fazla bilgi için kontrol edin:
Ayrıca, **wordpress**'te `/wp-json/wp/v2/users/1?_jsonp=data` adresinde **verileri** çıktıda **yansıtan** bir **JSONP** uç noktası bulunmaktadır (yalnızca harf, rakam ve nokta sınırlaması ile).
Bir saldırgan, bu uç noktayı**WordPress'e karşı bir SOME saldırısı oluşturmak için** istismar edebilir ve bunu `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` içine **gömerek** kullanabilir; bu **script****'self' tarafından izin verildiği için** **yüklenir**. Ayrıca, WordPress yüklü olduğu için, bir saldırgan, bir kullanıcıya daha fazla ayrıcalık vermek, yeni bir eklenti yüklemek için **CSP'yi atlayan****savunmasız****callback** uç noktası aracılığıyla **SOME saldırısını** istismar edebilir...\
Bu saldırıyı nasıl gerçekleştireceğiniz hakkında daha fazla bilgi için [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/) adresini kontrol edin.
Eğer dış sunucularla **etkileşimde bulunmanıza** izin vermeyen katı bir CSP varsa, bilgileri dışarı aktarmak için her zaman yapabileceğiniz bazı şeyler vardır.
Sayfaları daha hızlı yüklemek için, tarayıcılar ana bilgisayar adlarını IP adreslerine önceden çözümleyecek ve bunları daha sonraki kullanım için önbelleğe alacaktır.\
Bir tarayıcıya bir ana bilgisayar adını önceden çözümlemesi için şunu belirtebilirsiniz: `<link rel="dns-prefetch" href="something.com">`
Deneyimli hackerlar ve bug bounty avcıları ile iletişim kurmak için [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) sunucusuna katılın!
AWS Hacking'i öğrenin ve pratik yapın:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
GCP Hacking'i öğrenin ve pratik yapın: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* [**abonelik planlarını**](https://github.com/sponsors/carlospolop) kontrol edin!
* **💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın ya da **Twitter**'da **@hacktricks\_live**'ı takip edin** 🐦.