* Şirketinizi HackTricks'te **reklamınızı görmek** veya **HackTricks'i PDF olarak indirmek** için [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* Özel [**NFT'lerden**](https://opensea.io/collection/the-peass-family) oluşan koleksiyonumuz [**The PEASS Family**](https://opensea.io/collection/the-peass-family)'i keşfedin
* 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) **katılın** veya **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)'u **takip edin**.
**Aynı köken** politikası, bir **kaynağa istek yapan** sunucu ve **kaynağı barındıran** sunucunun aynı protokolü (ör. `http://`), alan adını (ör. `internal-web.com`) ve **portu** (ör. 80) paylaşması gerektiğini zorunlu kılar. Bu politika altında, yalnızca aynı etki alanı ve porttan gelen web sayfaları kaynaklara erişime izinlidir.
Bu başlık **birden fazla kök**, bir **`null`** değeri veya bir joker karakter **`*`** izin verebilir. Ancak, **hiçbir tarayıcı birden fazla kökü desteklemez** ve joker karakter `*` kullanımı**kısıtlamalara** tabidir. (Joker karakter yalnızca tek başına kullanılmalıdır ve `Access-Control-Allow-Credentials: true` ile birlikte kullanılması izin verilmez.)
Bu başlık, tarayıcının otomatik olarak bir `Origin` başlığı eklediği bir web sitesi tarafından başlatılan çapraz etki alanı kaynak isteğine yanıt olarak **bir sunucu tarafından verilir**.
Varsayılan olarak, çapraz etki alanı istekleri çerezler veya Yetkilendirme başlığı gibi kimlik bilgileri olmadan yapılır. Ancak, bir çapraz etki alanı sunucusu, yanıtın okunmasına izin vermek için kimlik bilgileri gönderildiğinde `Access-Control-Allow-Credentials` başlığını**`true`** olarak ayarlayabilir.
Belirli koşullar altında, örneğin **standart olmayan bir HTTP yöntemi** (HEAD, GET, POST dışında herhangi bir şey), yeni **başlıklar** tanıtma veya özel bir **Content-Type başlık değeri** kullanma durumunda, bir ön uçu isteği gerekebilir. Bu ön hazırlık isteği, **`OPTIONS`** yöntemini kullanarak sunucuyu yaklaşan çapraz kaynak isteğinin niyetleri hakkında bilgilendirir, bunlar arasında kullanmayı planladığı HTTP yöntemleri ve başlıklar bulunur.
**Çapraz Kaynak Kaynak Paylaşımı (CORS)** protokolü, bu ön uçu kontrolünü zorunlu kılar ve izin verilen yöntemleri, başlıkları ve kökenin güvenilirliğini doğrulayarak istenen çapraz kaynak işleminin uygulanabilirliğini belirler. Bir ön uçu isteği için gereksinimleri atlatan koşullar hakkında ayrıntılı bir anlayış için [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests) tarafından sağlanan kapsamlı kılavuza başvurun.
Önemli bir nokta olarak, **bir ön uçu isteğinin olmaması, yanıtın yetkilendirme başlıklarını taşıma gerekliliğini ortadan kaldırmaz**. Bu başlıklar olmadan tarayıcı, çapraz kaynak isteğinden gelen yanıtı işleme yeteneğinden yoksun kalır.
Aşağıdaki örnekte, `PUT` yöntemini kullanmayı amaçlayan ve `Special-Request-Header` adında özel bir başlık içeren bir ön uçu isteğinin bir gösterimi gösterilmektedir:
- **`Access-Control-Allow-Headers`**: Bu başlık, gerçek istekte hangi başlıkların kullanılabileceğini belirtir. Sunucu, istemciden gelen isteklerde izin verilen başlıkları belirtmek için bunu ayarlar.
- **`Access-Control-Expose-Headers`**: Bu başlık aracılığıyla sunucu, basit yanıt başlıklarının yanı sıra yanıtın bir parçası olarak hangi başlıkların açığa çıkarılabileceğini istemciye bildirir.
- **`Access-Control-Max-Age`**: Bu başlık, ön uçuş isteğinin sonuçlarının ne kadar süreyle önbelleğe alınabileceğini belirtir. Sunucu, ön uçuş isteği tarafından döndürülen bilgilerin ne kadar süreyle yeniden kullanılabileceğini saniye cinsinden belirler.
- **`Access-Control-Request-Headers`**: Ön uçuş isteklerinde kullanılan bu başlık, istemcinin gerçek istekte hangi HTTP başlıklarını kullanmak istediğini sunucuya bildirmek için ayarlanır.
- **`Access-Control-Request-Method`**: Bu başlık da ön uçuş isteklerinde kullanılır ve istemci tarafından gerçek istekte hangi HTTP yönteminin kullanılacağını belirtmek için ayarlanır.
- **`Origin`**: Bu başlık tarayıcı tarafından otomatik olarak ayarlanır ve çapraz kaynak isteğinin kökenini belirtir. Sunucu, CORS politikasına dayanarak gelen isteğin izin verilip verilmeyeceğini değerlendirmek için bunu kullanır.
Unutmayın ki genellikle (içerik türüne ve ayarlanan başlıklara bağlı olarak) **GET/POST isteğinde ön uçuş isteği gönderilmez** (isteğin **doğrudan** gönderilir), ancak yanıtın başlıklarını/gövdesini erişmek istiyorsanız, buna izin veren bir _Access-Control-Allow-Origin_ başlığı içermelidir.\
**Bu nedenle, CORS CSRF'ye karşı koruma sağlamaz (ancak yardımcı olabilir).**
1.**`Access-Control-Request-Local-Network`**: Bu başlık, istemcinin isteğinin yerel ağ kaynağına yönelik olduğunu belirtmek için istemcinin isteğine dahil edilir. Bu, isteğin yerel ağdan kaynaklandığını sunucuya bildirmek için bir işaret olarak hizmet eder.
2.**`Access-Control-Allow-Local-Network`**: Sunucular, bu başlığı kullanarak yanıt olarak talep edilen kaynağın yerel ağ dışındaki varlıklarla paylaşılabileceğini iletişim kurmak için kullanır. Bu, farklı ağ sınırları arasında kaynakların kontrol edilmiş erişimini sağlarken güvenlik protokollerini korurken kaynak paylaşımına yeşil ışık yakar.
Dikkat edilmesi gereken bir nokta, **0.0.0.0** IP adresinin localhost'a erişmek için bu gereksinimleri **atlamak** için kullanılabileceğidir, çünkü bu IP adresi "yerel" olarak kabul edilmez.
Ayrıca, yerel ağ gereksinimlerini **atlamak** mümkündür, eğer yerel bir uç noktanın **genel IP adresini** (örneğin yönlendiricinin genel IP'si) kullanırsanız. Çünkü birkaç durumda, **genel IP** erişiliyor olsa bile, eğer **yerel ağdan** erişiliyorsa, erişim izni verilecektir.
`Access-Control-Allow-Credentials` ayarının **`true`** olarak ayarlanması, çoğu **gerçek saldırı** için bir önkoşuldur. Bu ayar, tarayıcının kimlik bilgilerini göndermesine ve yanıtı okumasına izin verir, saldırının etkinliğini artırır. Bu olmadan, tarayıcının bir isteği kendisi yerine getirmesinin avantajı azalır, çünkü bir kullanıcının çerezlerini kullanmak mümkün olmaz hale gelir.
Kurbanın ağ konumu, kimlik doğrulama şeklinde kullanıldığında bir istisna vardır. Bu, kurbanın tarayıcısının bir proxy olarak kullanılmasına olanak tanır, IP tabanlı kimlik doğrulamayı atlayarak yerel ağ uygulamalarına erişim sağlar. Bu yöntem, DNS rebinding ile benzer etkilere sahip olmasına rağmen, daha kolay sömürülebilir.
`Origin` başlığının değerinin `Access-Control-Allow-Origin` içinde yansıtıldığı gerçek dünya senaryosu, bu başlıkların birleştirilmesine yönelik kısıtlamalar nedeniyle teorik olarak olası değildir. Bununla birlikte, CORS'u birden çok URL için etkinleştirmek isteyen geliştiriciler, `Access-Control-Allow-Origin` başlığını`Origin` başlığının değerini kopyalayarak dinamik olarak oluşturabilir. Bu yaklaşım, özellikle saldırganın geçerlilik mantığını aldatmak için tasarlanmış bir alan adı kullandığında, güvenlik açıklarına neden olabilir.
Yönlendirmeler veya yerel HTML dosyaları gibi durumlar için belirtilen `null` kökeni, benzersiz bir konuma sahiptir. Bazı uygulamalar, yerel geliştirmeyi kolaylaştırmak için bu kökeni beyaz listeye alırken, yanlışlıkla herhangi bir web sitesinin bir sandboxed iframe aracılığıyla `null` kökenini taklit etmesine izin vererek CORS kısıtlamalarını atlamasına neden olur.
Bir alan adı beyaz listesiyle karşılaşıldığında, saldırganın alan adını beyaz listelenmiş bir alan adına eklemek veya alt alan adı ele geçirme zafiyetlerinden yararlanmak gibi atlama fırsatlarını test etmek önemlidir. Ayrıca, alan adı doğrulaması için kullanılan düzenli ifadeler, alan adı adlandırma kurallarındaki ince ayrıntıları göz ardı edebilir ve daha fazla atlama fırsatı sunabilir.
Düzenli ifade desenleri genellikle alfanümerik, nokta (.), ve tire (-) karakterlerine odaklanırken, diğer olasılıkları göz ardı eder. Örneğin, tarayıcılar ve düzenli ifade desenleri tarafından farklı şekilde yorumlanan karakterleri içeren bir alan adı, güvenlik kontrollerini atlatabilir. Safari, Chrome ve Firefox'un alt alan adlarındaki alt çizgi karakterlerini nasıl işlediği, bu tür farklılıkların etki alanı doğrulama mantığını atlamak için nasıl sömürülebileceğini gösterir.
**Bu atlama kontrolünün daha fazla bilgi ve ayarları için:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **ve** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)
Geliştiriciler, CORS sömürüsüne karşı koruma sağlamak için bilgi talep etmeye izin verilen alan adlarını beyaz listeye alarak savunma mekanizmaları uygularlar. Ancak, bu önlemlere rağmen, sistem güvenliği tam anlamıyla sağlanamaz. Beyaz listelenmiş alan adları içinde yalnızca bir adet bile zafiyete açık alt alanın bulunması, XSS (Cross-Site Scripting) gibi diğer zafiyetler aracılığıyla CORS sömürüsüne yol açabilir.
Örneğin, `requester.com` alan adının, başka bir alan adı olan `provider.com`'dan kaynaklara erişime izin verildiği senaryoyu düşünelim. Sunucu tarafı yapılandırması aşağıdaki gibi olabilir:
Bu yapıda, `requester.com` alt alan adlarının hepsi erişime izin verilir. Ancak, bir alt alan adı, örneğin `sub.requester.com`, XSS zafiyetiyle ele geçirilirse, saldırgan bu zayıflığı kullanabilir. Örneğin, `sub.requester.com`'a erişimi olan bir saldırgan, XSS zafiyetini kullanarak CORS politikalarını atlayabilir ve `provider.com` üzerindeki kaynaklara kötü niyetli erişim sağlayabilir.
HTTP başlığı enjeksiyonu yoluyla sunucu tarafı önbellek zehirlenmesini sömürerek, depolanan bir Cross-Site Scripting (XSS) zafiyeti oluşturulabilir. Bu senaryo, bir uygulamanın `Origin` başlığını yasaklı karakterlerden arındırmaması durumunda ortaya çıkar ve özellikle Internet Explorer ve Edge kullanıcıları için bir zafiyet oluşturur. Bu tarayıcılar `\r` (0x0d) karakterini meşru bir HTTP başlık sonlandırıcısı olarak kabul eder ve bu da HTTP başlığı enjeksiyonu zafiyetlerine yol açar.
Bu zafiyeti doğrudan bir web tarayıcısının hatalı bir başlık göndermesiyle sömürmek mümkün olmasa da, Burp Suite gibi araçlar kullanılarak elle oluşturulmuş bir istek kullanılabilir. Bu yöntem, sunucu tarafında yanlışlıkla yanıtı kaydeden ve başkalarına sunan bir önbelleğe yol açabilir. Oluşturulan payload, sayfanın karakter setini UTF-7 olarak değiştirmeyi amaçlar. UTF-7, belirli bağlamlarda betik olarak yürütülebilen karakterleri kodlama yeteneği nedeniyle XSS zafiyetleriyle sık sık ilişkilendirilen bir karakter kodlamasıdır.
Daha fazla bilgi için depolanan XSS zafiyetleri hakkında [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored) sayfasına bakın.
**Not**: Özellikle sunucu tarafı önbellek zehirlenmesi yoluyla HTTP başlık enjeksiyonu zafiyetlerinin sömürülmesi, HTTP başlıkları dahil olmak üzere tüm kullanıcı tarafından sağlanan girişlerin doğrulanması ve temizlenmesinin kritik önemini vurgular. Bu tür zafiyetleri önlemek için her zaman giriş doğrulaması içeren sağlam bir güvenlik modeli kullanın.
Bu senaryoda, uygun kodlama olmadan özel bir HTTP başlığının içeriğini yansıtan bir web sayfası örneği gözlemlenir. Özellikle, web sayfası, yüklenirken JavaScript kodunu yürütmek için tasarlanmış bir SVG görüntü etiketi içeren `X-User-id` başlığında bulunan içeriği geri yansıtır.
Cross-Origin Resource Sharing (CORS) politikaları, özel başlıkların gönderilmesine izin verir. Ancak, CORS kısıtlamaları nedeniyle yanıtın tarayıcı tarafından doğrudan işlenmemesi durumunda, böyle bir enjeksiyonun kullanışlılığı sınırlı gibi görünebilir. Kritik nokta, tarayıcının önbellek davranışını düşünürken ortaya çıkar. Eğer `Vary: Origin` başlığı belirtilmezse, kötü niyetli yanıtın tarayıcı tarafından önbelleğe alınması mümkün hale gelir. Sonuç olarak, bu önbelleğe alınmış yanıt, URL'ye yönlendirildiğinde doğrudan render edilebilir, başlangıç isteği üzerinde doğrudan render gereksinimini atlayarak. Bu mekanizma, istemci tarafı önbelleğini kullanarak saldırının güvenilirliğini artırır.
Bu saldırıyı göstermek için, bir JSFiddle gibi bir web sayfasının ortamında yürütülecek şekilde tasarlanmış bir JavaScript örneği sunulur. Bu betik basit bir eylem gerçekleştirir: belirtilen URL'ye, kötü niyetli JavaScript içeren özel bir başlık içeren bir istek gönderir. Başarılı istek tamamlanmasının ardından, hedef URL'ye yönlendirmeye çalışır ve yanıt, `Vary: Origin` başlığının uygun şekilde işlenmeden önbelleğe alındıysa enjekte edilen betiğin yürütülmesini tetikleyebilir.
XSSI, aynı köken politikasının (SOP) betik etiketi kullanılarak kaynaklar dahil edildiğinde uygulanmadığından yararlanan bir güvenlik açığı türüdür. Bu, betiklerin farklı alanlardan dahil edilebilmesi gerektiği için geçerlidir. Bu güvenlik açığı, bir saldırganın betik etiketi kullanılarak dahil edilen herhangi bir içeriğe erişim sağlamasına ve okumasına olanak tanır.
Bu güvenlik açığı, özellikle dinamik JavaScript veya JSONP (Padding ile JSON) gibi durumlarda önem kazanır, özellikle çerezler gibi ortam yetkisi bilgileri kimlik doğrulaması için kullanıldığında. Farklı bir sunucudan bir kaynak istendiğinde, çerezler dahil edilir ve saldırgan tarafından erişilebilir hale gelir.
Bu güvenlik açığını daha iyi anlamak ve azaltmak için, web uygulamalarınızdaki potansiyel XSSI güvenlik açıklarını tespit etmenize ve ele almanıza yardımcı olabilecek BurpSuite eklentisini kullanabilirsiniz. Eklentiye [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp) adresinden erişebilirsiniz.
İsteğe bir **`callback`** **parametresi** eklemeyi deneyin. Belki sayfa verileri JSONP olarak göndermek için hazırlanmıştır. Bu durumda, sayfa verileri `Content-Type: application/javascript` ile geri gönderilecektir ve CORS politikasını atlatır.
`Access-Control-Allow-Origin` kısıtlamasını atlatmanın bir yolu, bir web uygulamasından sizin adınıza bir istek yapmasını ve yanıtı geri göndermesini istemektir. Ancak bu senaryoda, son kurbanın kimlik bilgileri farklı bir etki alanına yapılan istek nedeniyle gönderilmez.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Bu araç, isteğinizi başlıklarıyla birlikte yönlendiren bir proxy sağlar ve aynı zamanda Origin başlığını istenen etki alanıyla eşleştirmek için sahte bir Origin başlığı oluşturur. Bu, CORS politikasını etkili bir şekilde atlatır. İşte XMLHttpRequest ile kullanım örneği:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Bu araç, istekleri proxy olarak yönlendirmek yerine sunucu kendi parametreleriyle kendi isteğini yapar.
`e.origin === window.origin` gibi CORS kontrol noktalarını**iframe oluşturarak** ve **onun üzerinden yeni bir pencere açarak** atlayabilirsiniz. Daha fazla bilgi için aşağıdaki sayfaya bakın:
TTL ile DNS rebinding, DNS kayıtlarını manipüle ederek belirli güvenlik önlemlerini atlatmak için kullanılan bir tekniktir. İşleyişi aşağıdaki gibidir:
1. Saldırgan bir web sayfası oluşturur ve kurbanın buna erişmesini sağlar.
2. Saldırgan daha sonra kendi etki alanının DNS (IP) adresini kurbanın web sayfasına yönlendirmek için değiştirir.
3. Kurbanın tarayıcısı DNS yanıtını önbelleğe alır ve DNS kaydının ne kadar süreyle geçerli olacağını belirten bir TTL (Yaşam Süresi) değeri olabilir.
4. TTL süresi dolduğunda, kurbanın tarayıcısı yeni bir DNS isteği yapar, bu da saldırganın kurbanın sayfasında JavaScript kodunu yürütmesine olanak tanır.
5. Saldırgan, kurbanın IP adresi üzerinde kontrolü sürdürerek, kurbandan herhangi bir çerez göndermeden kurbandan bilgi toplayabilir.
Bu teknik, tarayıcıların düşük TTL değerleriyle bile bu teknikten hemen yararlanmayı önleyebilecek önbellekleme mekanizmalarına sahip olduğunu unutmak önemlidir.
DNS rebinding, kurban tarafından gerçekleştirilen açık IP kontrol noktalarını atlamak veya bir kullanıcının veya botun uzun bir süre aynı sayfada kalması durumunda önbelleğin süresinin dolmasına izin veren senaryolar için kullanışlı olabilir.
DNS rebinding'i hızlı bir şekilde istismar etmek için [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html) gibi hizmetleri kullanabilirsiniz.
Kendi DNS rebinding sunucunuzu çalıştırmak için **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)) gibi araçları kullanabilirsiniz. Bu, yerel 53/udp bağlantı noktanızı açığa çıkarmanızı, ona işaret eden bir A kaydı oluşturmanızı (örneğin ns.example.com) ve daha önce oluşturulan A alt alan adına işaret eden bir NS kaydı oluşturmanızı (örneğin ns.example.com) içerir. ns.example.com alt alanının herhangi bir alt alanı daha sonra ana bilgisayarınız tarafından çözümlenecektir.
Daha fazla anlama ve deney yapma için [http://rebind.it/singularity.html](http://rebind.it/singularity.html) adresinde halka açık çalışan bir sunucuyu keşfedebilirsiniz.
DNS önbelleğini sular altında bırakarak DNS önbellekleme mekanizmasını atlatmak için kullanılan başka bir teknik DNS rebinding via DNS cache flooding'dir. İşleyişi aşağıdaki gibidir:
1. İlk olarak, kurban bir DNS isteği yapar ve saldırganın IP adresiyle yanıt alır.
2. Önbellekleme savunmasını atlamak için saldırgan bir hizmet çalıştırır. Hizmet çalıştırıcı DNS önbelleğini sular altında bırakır ve önbelleğe alınmış saldırgan sunucu adını siler.
3. Kurbanın tarayıcısı ikinci bir DNS isteği yapar ve bu sefer genellikle yerel ana bilgisayarı işaret eden IP adresi 127.0.0.1 ile yanıt alır.
Servis çalıştırıcısı tarafından DNS önbelleğini sular altında bırakarak, saldırgan DNS çözümleme sürecini manipüle edebilir ve kurbanın tarayıcısının ikinci bir istekte bulunmasını zorlayabilir, bu sefer saldırganın istenen IP adresine çözülür.
Önbellekleme savunmasını atlatmanın başka bir yolu, DNS sağlayıcısında aynı alt alan için birden fazla IP adresi kullanmaktır. İşleyişi aşağıdaki gibidir:
1. Saldırgan, DNS sağlayıcısında aynı alt alan için iki A kaydı (veya iki IP'li tek bir A kaydı) ayarlar.
2. Bir tarayıcı bu kayıtları kontrol ettiğinde, her iki IP adresini de alır.
3. Tarayıcı saldırganın IP adresini ilk olarak kullanmaya karar verirse, saldırgan aynı etki alanına HTTP istekleri gerçekleştiren bir yük yükleyebilir.
4. Ancak saldırgan kurbanın IP adresini elde ettikten sonra, kurbanın tarayıcısına yanıt vermekten vazgeçer.
5. Etki alanının yanıt vermediğini fark eden kurbanın tarayıcısı, ikinci verilen IP adresini kullanmaya devam eder.
6. İkinci IP adresine erişerek, tarayıcı Aynı Köken Politikası'nı (SOP) atlar ve saldırgan bu durumu istismar ederek kurbandan bilgi toplayabilir ve dışarıya sızdırabilir.
Önceki geçiş teknikleri hakkında daha fazla bilgi ve aşağıdaki aracı nasıl kullanacağınız hakkında daha fazla bilgi için [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Konferansı](https://www.youtube.com/watch?v=y9-0lICNjOQ) konuşmasına bakabilirsiniz.
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity), [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding) saldırıları gerçekleştirmek için bir araçtır. Saldırı sunucusunun DNS adının IP adresini hedef makinenin IP adresine yeniden bağlamak ve hedef makinedeki güvenlik açıklarını sömürmek için saldırı yüklerini sunmak için gerekli bileşenleri içerir.
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Genel sunucuların dahili sunuculara erişmek istediğinde her zaman bir ön uçuş isteği göndermek için öneri
<summary><strong>AWS hackleme konusunda sıfırdan kahramana dönüşmek için</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>'ı öğrenin!</strong></summary>
* Şirketinizi HackTricks'te **tanıtmak veya HackTricks'i PDF olarak indirmek** için [**ABONELİK PLANLARINA**](https://github.com/sponsors/carlospolop) göz atın!
* Özel [**NFT'lerden**](https://opensea.io/collection/the-peass-family) oluşan koleksiyonumuz olan [**The PEASS Family**](https://opensea.io/collection/the-peass-family)'yi keşfedin
* 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) **katılın** veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**'da takip edin.**