mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/external-recon-meth
This commit is contained in:
parent
638426a97f
commit
5a62c9a1fb
@ -2,16 +2,13 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Artık kapsamımızdaki varlıkların listesini oluşturduğumuza göre, bazı OSINT düşük-hanging meyvelerini arama zamanı.
|
||||
|
||||
### Zaten sızıntıları arayan platformlar
|
||||
|
||||
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
|
||||
|
||||
### Github'daki api anahtarları sızıntıları
|
||||
### Git repos ve dosya sisteminde gizli bilgileri bulmak için araçlar
|
||||
|
||||
- [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog)
|
||||
- [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)
|
||||
- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker)
|
||||
- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield)
|
||||
- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository)
|
||||
- [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets)
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber)
|
||||
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
|
||||
|
@ -4,32 +4,32 @@
|
||||
|
||||
## Basic Information <a href="#d4a8" id="d4a8"></a>
|
||||
|
||||
OAuth, çeşitli versiyonlar sunar ve temel bilgiler [OAuth 2.0 belgeleri](https://oauth.net/2/) adresinde mevcuttur. Bu tartışma, yaygın olarak kullanılan [OAuth 2.0 yetkilendirme kodu grant türü](https://oauth.net/2/grant-types/authorization-code/) etrafında dönmektedir ve **bir uygulamanın başka bir uygulamadaki bir kullanıcının hesabına erişmesini veya işlemler gerçekleştirmesini sağlayan bir yetkilendirme çerçevesi** sunar (yetkilendirme sunucusu).
|
||||
OAuth, çeşitli versiyonlar sunar ve temel bilgiler [OAuth 2.0 belgeleri](https://oauth.net/2/) adresinde mevcuttur. Bu tartışma, yaygın olarak kullanılan [OAuth 2.0 yetkilendirme kodu hibe türü](https://oauth.net/2/grant-types/authorization-code/) etrafında dönmektedir ve **bir uygulamanın başka bir uygulamadaki bir kullanıcının hesabına erişmesini veya eylemler gerçekleştirmesini sağlayan bir yetkilendirme çerçevesi** sunar (yetkilendirme sunucusu).
|
||||
|
||||
Hayali bir web sitesi _**https://example.com**_ düşünün; bu site, **tüm sosyal medya paylaşımlarınızı**, özel olanlar da dahil, **sergilemek** için tasarlanmıştır. Bunu başarmak için OAuth 2.0 kullanılmaktadır. _https://example.com_, **sosyal medya paylaşımlarınıza erişim** izni talep edecektir. Sonuç olarak, _https://socialmedia.com_ üzerinde, **talep edilen izinler ve talebi yapan geliştirici** hakkında bilgi veren bir onay ekranı belirecektir. Onayınızla, _https://example.com_, **sizin adınıza paylaşımlarınıza erişim** yetkisi kazanır.
|
||||
Hayali bir web sitesi _**https://example.com**_ düşünün, bu site **tüm sosyal medya paylaşımlarınızı**, özel olanlar da dahil, **sergilemek** için tasarlanmıştır. Bunu başarmak için OAuth 2.0 kullanılmaktadır. _https://example.com_, **sosyal medya paylaşımlarınıza erişim** izni talep edecektir. Sonuç olarak, _https://socialmedia.com_ üzerinde, **talep edilen izinler ve talebi yapan geliştirici** hakkında bilgi veren bir onay ekranı belirecektir. Onayınızla, _https://example.com_, **paylaşımlarınıza sizin adınıza erişim** sağlama yetkisi kazanır.
|
||||
|
||||
OAuth 2.0 çerçevesindeki aşağıdaki bileşenleri anlamak önemlidir:
|
||||
OAuth 2.0 çerçevesi içindeki aşağıdaki bileşenleri anlamak önemlidir:
|
||||
|
||||
- **resource owner**: Siz, **kullanıcı/varlık** olarak, sosyal medya hesabınızdaki paylaşımlar gibi kaynaklarınıza erişim izni verirsiniz.
|
||||
- **resource server**: **Erişim token'ını** `resource owner` adına güvence altına aldıktan sonra kimlik doğrulama isteklerini yöneten **sunucu**, örneğin, **https://socialmedia.com**.
|
||||
- **resource owner**: Siz, **kullanıcı/varlık** olarak, sosyal medya hesabı paylaşımlarınız gibi kaynaklarınıza erişim izni verirsiniz.
|
||||
- **resource server**: Uygulama, `access token` alarak `resource owner` adına kimlik doğrulama taleplerini yöneten **sunucu**, örneğin, **https://socialmedia.com**.
|
||||
- **client application**: `resource owner`'dan yetkilendirme talep eden **uygulama**, örneğin, **https://example.com**.
|
||||
- **authorization server**: `resource owner`'ın başarılı bir şekilde kimlik doğrulamasını yaptıktan sonra `client application`'a **`access tokens`** veren **sunucu**, örneğin, **https://socialmedia.com**.
|
||||
- **authorization server**: `resource owner`'ın başarılı bir şekilde kimlik doğrulamasını yaptıktan sonra `client application`'a `access tokens` veren **sunucu**, örneğin, **https://socialmedia.com**.
|
||||
- **client_id**: Uygulama için kamuya açık, benzersiz bir tanımlayıcı.
|
||||
- **client_secret:** Sadece uygulama ve yetkilendirme sunucusu tarafından bilinen, `access_tokens` oluşturmak için kullanılan gizli bir anahtar.
|
||||
- **response_type**: **Talep edilen token türünü** belirten bir değer, örneğin `code`.
|
||||
- **scope**: `client application`'ın `resource owner`'dan talep ettiği **erişim seviyesi**.
|
||||
- **redirect_uri**: Kullanıcının yetkilendirmeden sonra yönlendirileceği **URL**. Bu genellikle önceden kaydedilmiş yönlendirme URL'si ile uyumlu olmalıdır.
|
||||
- **state**: Kullanıcının yetkilendirme sunucusuna yönlendirilmesi sırasında ve sonrasında **verileri korumak için** bir parametre. Benzersizliği, **CSRF koruma mekanizması** olarak hizmet vermesi açısından kritik öneme sahiptir.
|
||||
- **grant_type**: **Verilecek token türünü ve grant türünü** belirten bir parametre.
|
||||
- **code**: `authorization server`'dan alınan yetkilendirme kodu; `client application` tarafından `access_token` almak için `client_id` ve `client_secret` ile birlikte kullanılır.
|
||||
- **access_token**: `resource owner` adına API istekleri için **client application** tarafından kullanılan **token**.
|
||||
- **grant_type**: **Hibe türünü ve döndürülecek token türünü** belirten bir parametre.
|
||||
- **code**: `authorization server`'dan alınan yetkilendirme kodu, `client application` tarafından `access_token` almak için `client_id` ve `client_secret` ile birlikte kullanılır.
|
||||
- **access_token**: `resource owner` adına API talepleri için `client application` tarafından kullanılan **token**.
|
||||
- **refresh_token**: Uygulamanın **kullanıcıyı yeniden istemeden yeni bir `access_token` almasını** sağlar.
|
||||
|
||||
### Flow
|
||||
|
||||
**Gerçek OAuth akışı** şu şekilde ilerler:
|
||||
|
||||
1. [https://example.com](https://example.com) adresine gidiyorsunuz ve “Sosyal Medya ile Entegre Ol” butonunu seçiyorsunuz.
|
||||
1. [https://example.com](https://example.com) adresine gidersiniz ve “Sosyal Medya ile Entegre Ol” butonunu seçersiniz.
|
||||
2. Site, https://example.com uygulamasının paylaşımlarınıza erişim izni talep etmek için [https://socialmedia.com](https://socialmedia.com) adresine bir istek gönderir. İstek şu şekilde yapılandırılmıştır:
|
||||
```
|
||||
https://socialmedia.com/auth
|
||||
@ -40,7 +40,7 @@ https://socialmedia.com/auth
|
||||
&state=randomString123
|
||||
```
|
||||
3. Ardından bir onay sayfası ile karşılaşırsınız.
|
||||
4. Onayınızın ardından, Sosyal Medya `code` ve `state` parametreleri ile birlikte `redirect_uri`'ye bir yanıt gönderir:
|
||||
4. Onayınızın ardından, Sosyal Medya `redirect_uri`'ye `code` ve `state` parametreleri ile bir yanıt gönderir:
|
||||
```
|
||||
https://example.com?code=uniqueCode123&state=randomString123
|
||||
```
|
||||
@ -58,38 +58,38 @@ Host: socialmedia.com
|
||||
|
||||
`redirect_uri`, OAuth ve OpenID uygulamalarında güvenlik için kritik öneme sahiptir, çünkü yetkilendirme kodları gibi hassas verilerin yetkilendirme sonrası nereye gönderileceğini yönlendirir. Yanlış yapılandırıldığında, saldırganların bu istekleri kötü niyetli sunuculara yönlendirmesine izin verebilir ve hesap ele geçirme olanağı tanır.
|
||||
|
||||
Sömürü teknikleri, yetkilendirme sunucusunun doğrulama mantığına bağlı olarak değişir. Katı yol eşleşmesinden, belirtilen alan veya alt dizin içindeki herhangi bir URL'yi kabul etmeye kadar değişiklik gösterebilir. Yaygın sömürü yöntemleri arasında açık yönlendirmeler, yol geçişi, zayıf regex'lerin istismarı ve token hırsızlığı için HTML enjeksiyonu yer alır.
|
||||
Sömürü teknikleri, yetkilendirme sunucusunun doğrulama mantığına bağlı olarak değişir. Katı yol eşleşmesinden, belirtilen alan veya alt dizin içindeki herhangi bir URL'yi kabul etmeye kadar değişebilir. Yaygın sömürü yöntemleri arasında açık yönlendirmeler, yol geçişi, zayıf regexlerin istismarı ve token çalmak için HTML enjeksiyonu yer alır.
|
||||
|
||||
`redirect_uri` dışında, `client_uri`, `policy_uri`, `tos_uri` ve `initiate_login_uri` gibi diğer OAuth ve OpenID parametreleri de yönlendirme saldırılarına karşı hassastır. Bu parametreler isteğe bağlıdır ve sunucular arasında destekleri değişiklik gösterir.
|
||||
`redirect_uri` dışında, `client_uri`, `policy_uri`, `tos_uri` ve `initiate_login_uri` gibi diğer OAuth ve OpenID parametreleri de yönlendirme saldırılarına karşı hassastır. Bu parametreler isteğe bağlıdır ve destekleri sunucular arasında değişiklik gösterir.
|
||||
|
||||
OpenID sunucusunu hedef alanlar için, keşif uç noktası (`**.well-known/openid-configuration**`) genellikle `registration_endpoint`, `request_uri_parameter_supported` ve "`require_request_uri_registration`" gibi değerli yapılandırma ayrıntılarını listeler. Bu ayrıntılar, kayıt uç noktasını ve sunucunun diğer yapılandırma özelliklerini belirlemede yardımcı olabilir.
|
||||
|
||||
### Yönlendirme uygulamasında XSS <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Bu hata ödülü raporunda belirtildiği gibi [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) yönlendirme **URL'sinin sunucunun yanıtında yansıtılması** mümkün olabilir, bu da **XSS'ye karşı savunmasızdır**. Test etmek için olası yük:
|
||||
Bu hata ödülü raporunda belirtildiği gibi [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) yönlendirme **URL'sinin, kullanıcı kimlik doğruladıktan sonra sunucunun yanıtında yansıtılması** mümkün olabilir ve bu durum **XSS'ye karşı savunmasızdır**. Test etmek için olası yük:
|
||||
```
|
||||
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
|
||||
```
|
||||
### CSRF - State parametresinin yanlış yönetimi <a href="#bda5" id="bda5"></a>
|
||||
|
||||
OAuth uygulamalarında, **`state` parametresinin** kötüye kullanımı veya atlanması, **Cross-Site Request Forgery (CSRF)** saldırılarının riskini önemli ölçüde artırabilir. Bu zafiyet, `state` parametresi **kullanılmadığında, statik bir değer olarak kullanıldığında veya düzgün bir şekilde doğrulanmadığında** ortaya çıkar ve saldırganların CSRF korumalarını aşmasına olanak tanır.
|
||||
OAuth uygulamalarında, **`state` parametresinin** kötüye kullanımı veya atlanması, **Cross-Site Request Forgery (CSRF)** saldırılarının riskini önemli ölçüde artırabilir. Bu zafiyet, `state` parametresinin **kullanılmaması, statik bir değer olarak kullanılması veya kullanıcı oturumu ile doğru bir şekilde doğrulanmaması veya ilişkilendirilmemesi** durumunda ortaya çıkar ve saldırganların CSRF korumalarını aşmasına olanak tanır.
|
||||
|
||||
Saldırganlar, yetkilendirme sürecini kesintiye uğratarak kendi hesaplarını bir mağdurun hesabıyla ilişkilendirebilir, bu da potansiyel **hesap ele geçirmelerine** yol açar. Bu, OAuth'un **kimlik doğrulama amaçları** için kullanıldığı uygulamalarda özellikle kritik öneme sahiptir.
|
||||
Saldırganlar, yetkilendirme sürecini keserek kendi hesaplarını bir mağdurun hesabıyla ilişkilendirmek için bunu istismar edebilir, bu da bir kullanıcının saldırgana ait neredeyse tamamlanmış bir oauth akışıyla giriş yapmasını sağlayarak potansiyel **hesap ele geçirmelerine** yol açar. Bu, OAuth'un **kimlik doğrulama amaçları** için kullanıldığı uygulamalarda özellikle kritik öneme sahiptir.
|
||||
|
||||
Bu zafiyetin gerçek dünya örnekleri, çeşitli **CTF yarışmaları** ve **hackleme platformları** üzerinde belgelenmiştir ve pratik etkilerini vurgulamaktadır. Sorun, **Slack**, **Stripe** ve **PayPal** gibi üçüncü taraf hizmetlerle entegrasyonlara da uzanmakta, burada saldırganlar bildirimleri veya ödemeleri kendi hesaplarına yönlendirebilmektedir.
|
||||
Bu zafiyetin gerçek dünya örnekleri, çeşitli **CTF yarışmaları** ve **hackleme platformlarında** belgelenmiştir ve pratik etkilerini vurgulamaktadır. Sorun, saldırganların bildirimleri veya ödemeleri kendi hesaplarına yönlendirebileceği **Slack**, **Stripe** ve **PayPal** gibi üçüncü taraf hizmetlerle entegrasyonlara da uzanmaktadır.
|
||||
|
||||
**`state` parametresinin** doğru bir şekilde yönetimi ve doğrulanması, CSRF'ye karşı korunmak ve OAuth akışını güvence altına almak için kritik öneme sahiptir.
|
||||
**`state` parametresinin** doğru yönetimi ve doğrulanması, CSRF'ye karşı korunmak ve OAuth akışını güvence altına almak için kritik öneme sahiptir.
|
||||
|
||||
### Hesap Ele Geçirmeden Önce <a href="#ebe4" id="ebe4"></a>
|
||||
|
||||
1. **Hesap Oluşturma sırasında E-posta Doğrulaması Olmadan**: Saldırganlar, mağdurun e-posta adresini kullanarak önceden bir hesap oluşturabilir. Eğer mağdur daha sonra bir üçüncü taraf hizmeti ile giriş yaparsa, uygulama bu üçüncü taraf hesabını saldırganın önceden oluşturduğu hesapla yanlışlıkla ilişkilendirebilir ve yetkisiz erişime yol açabilir.
|
||||
2. **Gevşek OAuth E-posta Doğrulamasını Kötüye Kullanma**: Saldırganlar, e-postaları doğrulamayan OAuth hizmetlerini kötüye kullanarak kendi hizmetleriyle kaydolabilir ve ardından hesap e-posta adresini mağdurunki ile değiştirebilir. Bu yöntem, ilk senaryoya benzer şekilde yetkisiz hesap erişimi riski taşır, ancak farklı bir saldırı vektörü aracılığıyla.
|
||||
2. **Gevşek OAuth E-posta Doğrulamasını İstismar Etme**: Saldırganlar, e-postaları doğrulamayan OAuth hizmetlerini istismar edebilir; kendi hizmetleriyle kaydolup ardından hesap e-posta adresini mağdurunki ile değiştirebilirler. Bu yöntem, ilk senaryoya benzer şekilde yetkisiz hesap erişimi riski taşır, ancak farklı bir saldırı vektörü aracılığıyla.
|
||||
|
||||
### Gizli Bilgilerin Açığa Çıkması <a href="#e177" id="e177"></a>
|
||||
|
||||
Gizli OAuth parametrelerini tanımlamak ve korumak çok önemlidir. **`client_id`** güvenle ifşa edilebilirken, **`client_secret`** ifşa edilmesi önemli riskler taşır. Eğer `client_secret` ele geçirilirse, saldırganlar uygulamanın kimliğini ve güvenini kötüye kullanarak **kullanıcı `access_tokens`** ve özel bilgileri çalabilir.
|
||||
Gizli OAuth parametrelerini tanımlamak ve korumak çok önemlidir. **`client_id`** güvenle ifşa edilebilirken, **`client_secret`** ifşa edilmesi önemli riskler taşır. Eğer `client_secret` ele geçirilirse, saldırganlar uygulamanın kimliğini ve güvenini istismar ederek **kullanıcı `access_tokens`** ve özel bilgileri çalabilirler.
|
||||
|
||||
Uygulamaların yetkilendirme `code`'unu `access_token` ile istemci tarafında değil, sunucu tarafında yanlışlıkla yönetmesi durumunda yaygın bir zafiyet ortaya çıkar. Bu hata, `client_secret`'in açığa çıkmasına yol açar ve saldırganların uygulamanın kimliğini kullanarak `access_tokens` oluşturmasına olanak tanır. Ayrıca, sosyal mühendislik yoluyla, saldırganlar OAuth yetkilendirmesine ek kapsamlar ekleyerek ayrıcalıkları artırabilir ve uygulamanın güvenilir durumunu daha da kötüye kullanabilir.
|
||||
Uygulamaların yetkilendirme `code`'unu `access_token` ile istemci tarafında değil, sunucu tarafında yanlışlıkla ele alması durumunda yaygın bir zafiyet ortaya çıkar. Bu hata, `client_secret`'in açığa çıkmasına yol açar ve saldırganların uygulamanın kimliğini kullanarak `access_tokens` oluşturmasına olanak tanır. Ayrıca, sosyal mühendislik yoluyla, saldırganlar OAuth yetkilendirmesine ek kapsamlar ekleyerek ayrıcalıkları artırabilir ve uygulamanın güvenilir durumunu daha da istismar edebilirler.
|
||||
|
||||
### Client Secret Bruteforce
|
||||
|
||||
@ -104,9 +104,9 @@ Connection: close
|
||||
|
||||
code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]
|
||||
```
|
||||
### Referer Header leaking Code + State
|
||||
### Referer Header sızdıran Kod + State
|
||||
|
||||
Müşteri **kod ve durum** bilgilerini aldıktan sonra, eğer bu bilgiler **Referer başlığında yansıyorsa** ve farklı bir sayfaya geçiş yapıyorsa, o zaman bu sistem zayıf.
|
||||
Müşteri **kod ve state**'e sahip olduğunda, eğer bu **Referer header içinde yansıyorsa** ve farklı bir sayfaya gittiğinde, o zaman bu açık bir durumdadır.
|
||||
|
||||
### Tarayıcı Geçmişinde Saklanan Erişim Token'ı
|
||||
|
||||
@ -120,13 +120,13 @@ Müşteri **kod ve durum** bilgilerini aldıktan sonra, eğer bu bilgiler **Refe
|
||||
|
||||
Eğer **yetkilendirme kodunu alabilir ve bunu farklı bir istemci ile kullanabilirseniz, diğer hesapları ele geçirebilirsiniz**.
|
||||
|
||||
### Mutlu Yollar, XSS, Iframe'ler ve Kod & Durum Değerlerini Sızdırmak için Post Mesajları
|
||||
### Mutlu Yollar, XSS, Iframe'ler ve Kod & State değerlerini sızdırmak için Post Mesajları
|
||||
|
||||
[**Bu gönderiyi kontrol edin**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)
|
||||
|
||||
### AWS Cognito <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Bu hata ödül raporunda: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) **AWS Cognito** tarafından kullanıcıya geri verilen **token'ın** **kullanıcı verilerini üzerine yazmak için yeterli izinlere sahip olabileceğini** görebilirsiniz. Bu nedenle, eğer **bir kullanıcı e-posta adresini farklı bir kullanıcı e-posta adresi ile değiştirebilirseniz**, diğer hesapları **ele geçirebilirsiniz**.
|
||||
Bu hata ödül raporunda: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) **AWS Cognito**'nun kullanıcıya geri verdiği **token**'ın **kullanıcı verilerini üzerine yazmak için yeterli izinlere sahip olabileceğini** görebilirsiniz. Bu nedenle, eğer **bir kullanıcı e-posta adresini farklı bir kullanıcı e-posta adresi ile değiştirebilirseniz**, diğer hesapları **ele geçirebilirsiniz**.
|
||||
```bash
|
||||
# Read info of the user
|
||||
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
|
||||
@ -143,7 +143,7 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ
|
||||
]
|
||||
}
|
||||
```
|
||||
Daha fazla bilgi için AWS cognito'yu nasıl kötüye kullanacağınızı kontrol edin:
|
||||
Daha ayrıntılı bilgi için AWS cognito'yu nasıl kötüye kullanacağınızı kontrol edin:
|
||||
|
||||
{{#ref}}
|
||||
https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html
|
||||
@ -153,27 +153,27 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat
|
||||
|
||||
[**bu yazıda bahsedildiği gibi**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), **token** (ve kod değil) almayı bekleyen OAuth akışları, token'ın uygulamaya ait olduğunu kontrol etmedikleri takdirde savunmasız olabilir.
|
||||
|
||||
Bu, bir **saldırganın** kendi uygulamasında **OAuth destekleyen ve Facebook ile giriş yapan bir uygulama** oluşturabileceği anlamına gelir. Ardından, bir kurban Facebook ile **saldırganın uygulamasına** giriş yaptığında, saldırgan **kullanıcının uygulamasına verilen OAuth token'ını alabilir ve bunu kurbanın kullanıcı token'ı ile kurbanın OAuth uygulamasında giriş yapmak için kullanabilir**.
|
||||
Bu, bir **saldırganın** kendi uygulamasında **OAuth destekleyen ve Facebook ile giriş yapan bir uygulama** oluşturabileceği anlamına gelir. Daha sonra, bir kurban **saldırganın uygulamasında** Facebook ile giriş yaptığında, saldırgan **kullanıcının uygulamasına verilen OAuth token'ını alabilir ve bunu kurbanın OAuth uygulamasında kurbanın kullanıcı token'ı ile giriş yapmak için kullanabilir**.
|
||||
|
||||
> [!DİKKAT]
|
||||
> Bu nedenle, eğer saldırgan kullanıcıyı kendi OAuth uygulamasına eriştirmeyi başarırsa, token bekleyen ve token'ın kendi uygulama kimliğine verilip verilmediğini kontrol etmeyen uygulamalarda kurbanın hesabını ele geçirebilir.
|
||||
|
||||
### İki Bağlantı & Çerez <a href="#bda5" id="bda5"></a>
|
||||
|
||||
[**bu yazıya göre**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), bir kurbanın saldırganın ana bilgisayarına işaret eden bir **returnUrl** ile bir sayfa açması mümkün olmuştur. Bu bilgi **çerezde (RU)** saklanacak ve **sonraki adımda** **istem** kullanıcının o saldırganın ana bilgisayarına erişim vermek isteyip istemediğini **soracaktır**.
|
||||
[**bu yazıya göre**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), bir kurbanın saldırganın ana bilgisayarına işaret eden bir **returnUrl** ile bir sayfa açmasını sağlamak mümkündü. Bu bilgi **bir çerezde (RU)** saklanacak ve **sonraki adımda** **istem** kullanıcının o saldırganın ana bilgisayarına erişim vermek isteyip istemediğini **soracaktır**.
|
||||
|
||||
Bu istemi atlatmak için, **returnUrl** kullanarak bu RU çerezini ayarlamak için **Oauth akışını** başlatmak üzere bir sekme açmak, istem gösterilmeden önce sekmeyi kapatmak ve bu değeri içermeyen yeni bir sekme açmak mümkündü. Böylece, **istem saldırganın ana bilgisayarından bahsetmeyecek**, ancak çerez ona ayarlanacak, bu nedenle **token saldırganın ana bilgisayarına** yönlendirme sırasında gönderilecektir.
|
||||
Bu istemi atlatmak için, **returnUrl** kullanarak bu RU çerezini ayarlamak için **Oauth akışını** başlatmak üzere bir sekme açmak, istem gösterilmeden önce sekmeyi kapatmak ve bu değeri içermeyen yeni bir sekme açmak mümkündü. Böylece, **istem saldırganın ana bilgisayarından bahsetmeyecek**, ancak çerez ona ayarlanacak, bu nedenle **token saldırganın ana bilgisayarına yönlendirme sırasında gönderilecektir**.
|
||||
|
||||
### İstem Etkileşimi Atlatma <a href="#bda5" id="bda5"></a>
|
||||
|
||||
[**bu videoda açıklandığı gibi**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), bazı OAuth uygulamaları, kullanıcıların platformda zaten giriş yapmışlarsa webde verilen erişimi onaylamaları için bir istemde sorulmasını **önlemek** amacıyla **`prompt`** GET parametresini None (**`&prompt=none`**) olarak belirtmeye izin verir.
|
||||
[**bu videoda açıklandığı gibi**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), bazı OAuth uygulamaları, kullanıcıların platformda zaten oturum açmışlarsa webde verilen erişimi onaylamak için bir istemde sorulmasını **önlemek** amacıyla **`prompt`** GET parametresini None (**`&prompt=none`**) olarak belirtmeye izin verir.
|
||||
|
||||
### response_mode
|
||||
|
||||
[**bu videoda açıklandığı gibi**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), kodun son URL'de nerede sağlanacağını belirtmek için **`response_mode`** parametresini belirtmek mümkün olabilir:
|
||||
|
||||
- `response_mode=query` -> Kod bir GET parametresi içinde sağlanır: `?code=2397rf3gu93f`
|
||||
- `response_mode=fragment` -> Kod URL parçası parametresi içinde sağlanır `#code=2397rf3gu93f`
|
||||
- `response_mode=fragment` -> Kod URL parça parametresi içinde sağlanır `#code=2397rf3gu93f`
|
||||
- `response_mode=form_post` -> Kod, `code` adında bir girdi ile bir POST formu içinde sağlanır ve değer
|
||||
- `response_mode=web_message` -> Kod bir post mesajında gönderilir: `window.opener.postMessage({"code": "asdasdasd...`
|
||||
|
||||
@ -181,43 +181,65 @@ Bu istemi atlatmak için, **returnUrl** kullanarak bu RU çerezini ayarlamak iç
|
||||
|
||||
[**bu blog yazısına göre**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), bu, OAuth üzerinden **kullanıcı adı** ve **şifre** ile giriş yapmayı sağlayan bir OAuth akışıdır. Bu basit akış sırasında, kullanıcının gerçekleştirebileceği tüm eylemlere erişim sağlayan bir **token** dönerse, bu token kullanılarak 2FA atlatılabilir.
|
||||
|
||||
### Açık yönlendirmeye dayalı web sayfasında ATO <a href="#bda5" id="bda5"></a>
|
||||
### Açık yönlendirme temelinde yönlendirme ile ATO <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Bu [**blog yazısı**](https://blog.voorivex.team/oauth-non-happy-path-to-ato), bir **açık yönlendirmeyi** referans değerinden yararlanarak OAuth'u ATO için nasıl kötüye kullanmanın mümkün olduğunu yorumlamaktadır. Saldırı şu şekildedir:
|
||||
Bu [**blog yazısı**](https://blog.voorivex.team/oauth-non-happy-path-to-ato), bir **açık yönlendirmeyi** referans değerinden yararlanarak OAuth'u ATO için nasıl kötüye kullanabileceğini yorumlamaktadır. Saldırı şu şekildedir:
|
||||
|
||||
1. Kurban saldırganın web sayfasına erişir
|
||||
1. Kurban saldırganın web sayfasına erişir.
|
||||
2. Kurban kötü niyetli bağlantıyı açar ve bir açıcı, **saldırganın web sitesi** referansını kullanarak `response_type=id_token,code&prompt=none` ek parametreleri ile Google OAuth akışını başlatır.
|
||||
3. Açıcı, sağlayıcı kurbanı yetkilendirdikten sonra, onları `redirect_uri` parametresinin değerine (kurban web) 30X kodu ile geri gönderir ve bu hala saldırganın web sitesini referans olarak tutar.
|
||||
4. Kurban **web sitesi, referansa dayalı açık yönlendirmeyi tetikler** ve kurban kullanıcıyı saldırganın web sitesine yönlendirir, çünkü **`respose_type`** **`id_token,code`** olduğundan, kod saldırgana URL'nin **parçasında** geri gönderilecektir ve bu da onun kurbanın sitesinde Google aracılığıyla kullanıcının hesabını ele geçirmesine olanak tanır.
|
||||
3. Açıcı, sağlayıcı kurbanı yetkilendirdikten sonra, onları `redirect_uri` parametresinin değerine (kurban webi) 30X kodu ile geri gönderir ve bu hala saldırganın web sitesini referans olarak tutar.
|
||||
4. Kurban **web sitesi, referansa dayalı açık yönlendirmeyi tetikler** ve kurban kullanıcıyı saldırganın web sitesine yönlendirir, çünkü **`respose_type`** **`id_token,code`** olduğundan, kod saldırgana URL'nin **parçasında** geri gönderilecektir ve bu da onun kurbanın hesabını Google üzerinden ele geçirmesine olanak tanır.
|
||||
|
||||
### SSRF'lerin parametreleri <a href="#bda5" id="bda5"></a>
|
||||
|
||||
[**Bu araştırmayı kontrol edin**](https://portswigger.net/research/hidden-oauth-attack-vectors) **Bu tekniğin daha fazla ayrıntısı için.**
|
||||
|
||||
OAuth'taki Dinamik İstemci Kaydı, güvenlik açıkları için daha az belirgin ama kritik bir vektör olarak **Sunucu Tarafı İstek Sahteciliği (SSRF)** saldırılarına hizmet eder. Bu uç nokta, OAuth sunucularının istemci uygulamaları hakkında, kötüye kullanılabilecek hassas URL'ler de dahil olmak üzere ayrıntılar almasına olanak tanır.
|
||||
OAuth'taki Dinamik İstemci Kaydı, güvenlik açıkları için daha az belirgin ama kritik bir vektör olarak **Sunucu Tarafı İstek Sahteciliği (SSRF)** saldırılarına hizmet eder. Bu uç nokta, OAuth sunucularının istemci uygulamaları hakkında ayrıntılar almasına olanak tanır; bu, kötüye kullanılabilecek hassas URL'leri içerir.
|
||||
|
||||
**Ana Noktalar:**
|
||||
|
||||
- **Dinamik İstemci Kaydı**, genellikle `/register` ile eşleştirilir ve `client_name`, `client_secret`, `redirect_uris` ve POST istekleri aracılığıyla logolar veya JSON Web Anahtar Setleri (JWK'ler) için URL'ler gibi ayrıntıları kabul eder.
|
||||
- Bu özellik, **RFC7591** ve **OpenID Connect Kaydı 1.0**'da belirtilen spesifikasyonlara uyar ve SSRF'ye karşı potansiyel olarak savunmasız olabilecek parametreleri içerir.
|
||||
- Kayıt süreci, istemcileri birkaç şekilde SSRF'ye maruz bırakabilir:
|
||||
- **`logo_uri`**: Sunucu tarafından alınabilecek istemci uygulamasının logosu için bir URL, bu da SSRF'yi tetikleyebilir veya URL yanlış yönetilirse XSS'ye yol açabilir.
|
||||
- **`jwks_uri`**: İstemcinin JWK belgesine giden bir URL, kötü niyetle oluşturulursa, sunucunun saldırgan kontrolündeki bir sunucuya dışa dönük istekler yapmasına neden olabilir.
|
||||
- **`sector_identifier_uri`**: Sunucunun alabileceği `redirect_uris` JSON dizisini referans alır ve bu da SSRF fırsatı yaratır.
|
||||
- **`request_uris`**: İstemci için izin verilen istek URI'lerini listeler, bu da sunucu bu URI'leri yetkilendirme sürecinin başında alırsa kötüye kullanılabilir.
|
||||
- **Dinamik İstemci Kaydı**, genellikle `/register` ile eşleştirilir ve `client_name`, `client_secret`, `redirect_uris` ve POST istekleri aracılığıyla logolar veya JSON Web Key Sets (JWK'ler) için URL'ler gibi ayrıntıları kabul eder.
|
||||
- Bu özellik, **RFC7591** ve **OpenID Connect Registration 1.0**'da belirtilen spesifikasyonlara uyar; bu, SSRF'ye karşı potansiyel olarak savunmasız parametreleri içerir.
|
||||
- Kayıt süreci, birkaç şekilde sunucuları SSRF'ye maruz bırakabilir:
|
||||
- **`logo_uri`**: Sunucu tarafından alınabilecek istemci uygulamasının logosu için bir URL; bu, SSRF'yi tetikleyebilir veya URL yanlış yönetilirse XSS'ye yol açabilir.
|
||||
- **`jwks_uri`**: İstemcinin JWK belgesine giden bir URL; kötü niyetle oluşturulursa, sunucunun saldırgan kontrolündeki bir sunucuya dışa dönük istekler yapmasına neden olabilir.
|
||||
- **`sector_identifier_uri`**: Sunucunun alabileceği `redirect_uris` JSON dizisini referans alır ve bu, SSRF fırsatı yaratır.
|
||||
- **`request_uris`**: İstemci için izin verilen istek URI'lerini listeler; bu, sunucu bu URI'leri yetkilendirme sürecinin başında alırsa kötüye kullanılabilir.
|
||||
|
||||
**Kötüye Kullanım Stratejisi:**
|
||||
|
||||
- SSRF, `logo_uri`, `jwks_uri` veya `sector_identifier_uri` gibi parametrelerde kötü niyetli URL'lerle yeni bir istemci kaydederek tetiklenebilir.
|
||||
- SSRF, `logo_uri`, `jwks_uri` veya `sector_identifier_uri` gibi parametrelerde kötü niyetli URL'ler ile yeni bir istemci kaydederek tetiklenebilir.
|
||||
- `request_uris` aracılığıyla doğrudan kötüye kullanım, beyaz liste kontrolleri ile azaltılabilirken, önceden kaydedilmiş, saldırgan kontrolündeki bir `request_uri` sağlamak, yetkilendirme aşamasında SSRF'yi kolaylaştırabilir.
|
||||
|
||||
## OAuth sağlayıcıları Yarış Koşulları
|
||||
|
||||
Test ettiğiniz platform bir OAuth sağlayıcısıysa [**olası Yarış Koşullarını test etmek için bunu okuyun**](race-condition.md).
|
||||
Test ettiğiniz platform bir OAuth sağlayıcısıysa [**Olası Yarış Koşullarını test etmek için bunu okuyun**](race-condition.md).
|
||||
|
||||
## Değiştirilebilir İddialar Saldırısı
|
||||
|
||||
OAuth'ta, sub alanı bir kullanıcıyı benzersiz olarak tanımlar, ancak formatı Yetkilendirme Sunucusuna göre değişir. Kullanıcı tanımlamasını standart hale getirmek için bazı istemciler e-posta veya kullanıcı tanıtıcıları kullanır. Ancak bu risklidir çünkü:
|
||||
|
||||
- Bazı Yetkilendirme Sunucuları, bu özelliklerin (örneğin e-posta) değişmez kalmasını sağlamaz.
|
||||
- Bazı uygulamalarda—**"Microsoft ile Giriş"** gibi—istemci, e-posta alanına dayanır; bu alan **Entra ID'de kullanıcı tarafından kontrol edilir** ve doğrulanmaz.
|
||||
- Bir saldırgan, kendi Azure AD organizasyonunu (örneğin, doyensectestorg) oluşturarak bunu Microsoft girişi yapmak için kullanabilir.
|
||||
- Sub'da saklanan Nesne Kimliği (Object ID) değişmez ve güvenli olsa da, değiştirilebilir bir e-posta alanına bağımlılık, bir hesap ele geçirmeyi mümkün kılabilir (örneğin, victim@gmail.com gibi bir hesabı ele geçirmek).
|
||||
|
||||
## İstemci Karışıklığı Saldırısı
|
||||
|
||||
Bir **İstemci Karışıklığı Saldırısı**'nda, OAuth İkili Akışını kullanan bir uygulama, nihai erişim token'ının özel olarak kendi İstemci Kimliği için oluşturulduğunu doğrulamakta başarısız olur. Bir saldırgan, Google’ın OAuth İkili Akışını kullanan bir kamu web sitesi kurar, binlerce kullanıcıyı oturum açmaya kandırarak saldırganın sitesine yönelik erişim token'larını toplar. Bu kullanıcıların, token'ın İstemci Kimliği'ni doğrulamayan başka bir savunmasız web sitesinde de hesapları varsa, saldırgan toplanan token'ları kullanarak kurbanları taklit edebilir ve hesaplarını ele geçirebilir.
|
||||
|
||||
## Kapsam Yükseltme Saldırısı
|
||||
|
||||
**Yetkilendirme Kodu Verme** türü, kullanıcı verilerini iletmek için güvenli sunucu-sunucu iletişimini içerir. Ancak, eğer **Yetkilendirme Sunucusu**, Erişim Token'ı İsteği'ndeki bir kapsam parametresine dolaylı olarak güveniyorsa (RFC'de tanımlanmayan bir parametre), kötü niyetli bir uygulama, daha yüksek bir kapsam talep ederek bir yetkilendirme kodunun ayrıcalıklarını yükseltebilir. **Erişim Token'ı** oluşturulduktan sonra, **Kaynak Sunucusu** bunu doğrulamalıdır: JWT token'ları için, bu JWT imzasını kontrol etmeyi ve client_id ve scope gibi verileri çıkarmayı içerir; rastgele dize token'ları için, sunucu, token'ın ayrıntılarını almak için Yetkilendirme Sunucusu'na sorgu yapmalıdır.
|
||||
|
||||
## Yönlendirme Şeması Kaçırma
|
||||
|
||||
Mobil OAuth uygulamalarında, uygulamalar **özel URI şemaları** kullanarak Yetkilendirme Kodları ile yönlendirmeleri alır. Ancak, bir cihazda birden fazla uygulama aynı şemayı kaydedebileceğinden, yalnızca meşru istemcinin yönlendirme URI'sini kontrol ettiği varsayımı ihlal edilir. Örneğin Android'de, `com.example.app://` gibi bir Intent URI, şemaya ve bir uygulamanın intent-filter'ında tanımlanan isteğe bağlı filtrelere göre yakalanır. Android'in intent çözümlemesi geniş olabileceğinden—özellikle yalnızca şema belirtilmişse—bir saldırgan, yetkilendirme kodunu kaçırmak için dikkatlice hazırlanmış bir intent filtresi ile kötü niyetli bir uygulama kaydedebilir. Bu, kullanıcı etkileşimi yoluyla (birden fazla uygulama intent'i işlemek için uygun olduğunda) veya aşırı belirgin filtreleri kötüye kullanan atlatma teknikleri aracılığıyla **bir hesap ele geçirmeyi** mümkün kılabilir.
|
||||
|
||||
## Referanslar
|
||||
|
||||
- [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1)
|
||||
- [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
|
||||
- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
@ -4,13 +4,13 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
Arka uç/ön uç nasıl davranıyorsa, bir saldırgan **garip unicode karakterleri aldığında** **korumaları atlayabilir ve rastgele karakterler enjekte edebilir**. Bu, XSS veya SQLi gibi **enjeksiyon zafiyetlerini kötüye kullanmak için** kullanılabilir.
|
||||
Arka uç/ön uç nasıl davranıyorsa, **garip unicode karakterleri aldığında** bir saldırgan **korumaları atlayabilir ve rastgele karakterler enjekte edebilir**. Bu, XSS veya SQLi gibi **enjeksiyon zafiyetlerini kötüye kullanmak için** kullanılabilir.
|
||||
|
||||
## Unicode Normalization
|
||||
|
||||
Unicode normalizasyonu, **unicode karakterlerinin ascii karakterlerine normalleştirildiği** durumlarda gerçekleşir.
|
||||
Unicode normalizasyonu, **unicode karakterlerinin ascii karakterlerine normalleştirilmesi** sırasında gerçekleşir.
|
||||
|
||||
Bu tür bir zafiyetin yaygın bir senaryosu, sistemin kullanıcının **girişini kontrol ettikten sonra** bir şekilde **değiştirmesi** durumunda ortaya çıkar. Örneğin, bazı dillerde **girişi büyük veya küçük harfe dönüştürmek** için basit bir çağrı, verilen girişi normalleştirebilir ve **unicode ASCII'ye dönüştürülecek** yeni karakterler üretebilir.\
|
||||
Bu tür bir zafiyetin yaygın bir senaryosu, sistemin kullanıcının **girişini kontrol ettikten sonra** bir şekilde **değiştirmesi** durumunda ortaya çıkar. Örneğin, bazı dillerde **girişi büyük veya küçük harfe dönüştürmek** için yapılan basit bir çağrı, verilen girişi normalleştirebilir ve **unicode ASCII'ye dönüştürülecek** yeni karakterler üretebilir.\
|
||||
Daha fazla bilgi için kontrol edin:
|
||||
|
||||
{{#ref}}
|
||||
@ -19,18 +19,18 @@ unicode-normalization.md
|
||||
|
||||
## `\u` to `%`
|
||||
|
||||
Unicode karakterleri genellikle **`\u` ön eki** ile temsil edilir. Örneğin, `㱋` karakteri `\u3c4b`dir ([buradan kontrol edin](https://unicode-explorer.com/c/3c4B)). Eğer bir arka uç **`\u` ön ekini `%`'ye dönüştürürse**, ortaya çıkan dize `%3c4b` olacaktır, bu da URL çözüldüğünde: **`<4b`** olur. Ve, görebileceğiniz gibi, bir **`<` karakteri enjekte edilmiştir**.\
|
||||
Eğer arka uç zayıfsa, bu tekniği **herhangi bir tür karakteri enjekte etmek için** kullanabilirsiniz.\
|
||||
Unicode karakterleri genellikle **`\u` ön eki** ile temsil edilir. Örneğin, `㱋` karakteri `\u3c4b`dir ([buradan kontrol edin](https://unicode-explorer.com/c/3c4B)). Eğer bir arka uç **`\u` ön ekini `%`'ye dönüştürürse**, ortaya çıkan dize `%3c4b` olacaktır ki, URL çözüldüğünde: **`<4b`** olur. Ve, görebileceğiniz gibi, bir **`<` karakteri enjekte edilmiştir**.\
|
||||
Eğer arka uç zayıfsa, bu tekniği **herhangi bir karakteri enjekte etmek için** kullanabilirsiniz.\
|
||||
Gerekli karakterleri bulmak için [https://unicode-explorer.com/](https://unicode-explorer.com/) adresini kontrol edin.
|
||||
|
||||
Bu zafiyet aslında bir araştırmacının bulduğu bir zafiyetten gelmektedir, daha derin bir açıklama için [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg) adresine bakın.
|
||||
|
||||
## Emoji Injection
|
||||
|
||||
Arka uçlar, **emoji aldıklarında** tuhaf bir şekilde davranır. Bu, araştırmacının `💋img src=x onerror=alert(document.domain)//💛` gibi bir yükle XSS elde etmeyi başardığı [**bu yazıda**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) olan durumdur.
|
||||
Arka uçlar, **emoji aldıklarında** tuhaf bir şekilde davranır. Bu, araştırmacının `💋img src=x onerror=alert(document.domain)//💛` gibi bir yük ile XSS elde etmeyi başardığı [**bu yazıda**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) olan durumdur.
|
||||
|
||||
Bu durumda, hata, sunucunun kötü niyetli karakterleri kaldırdıktan sonra **UTF-8 dizesini Windows-1252'den UTF-8'e dönüştürmesiydi** (temelde giriş kodlaması ve kodlamadan dönüştürme uyuşmazlığı). Bu, düzgün bir < vermez, sadece tuhaf bir unicode verir: `‹`\
|
||||
``Bu çıktıyı aldılar ve **şimdi UTF-8'den ASCII'ye tekrar dönüştürdüler**. Bu, `‹`'yi `<'ye **normalleştirdi**, bu da bu sistemdeki istismarın nasıl çalışabileceğidir.\
|
||||
Bu durumda, hata, sunucunun kötü niyetli karakterleri kaldırdıktan sonra **Windows-1252'den UTF-8'e UTF-8 dizesini dönüştürmesiydi** (temelde giriş kodlaması ve dönüştürme kodlaması uyuşmazlığı). Bu, düzgün bir < vermez, sadece tuhaf bir unicode verir: `‹`\
|
||||
``Bu çıktıyı alıp **şimdi UTF-8'den ASCII'ye dönüştürdüler**. Bu, `‹`'yi `<'ye **normalleştirdi** ve bu, bu sistemdeki istismarın nasıl çalışabileceğidir.\
|
||||
İşte olanlar:
|
||||
```php
|
||||
<?php
|
||||
@ -47,4 +47,18 @@ Emoji listeleri:
|
||||
- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
|
||||
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)
|
||||
|
||||
## Windows En İyi Uyum/Kötü Uyum
|
||||
|
||||
**[bu harika yazıda](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)** açıklandığı gibi, Windows'un **En İyi Uyum** adında bir özelliği vardır; bu özellik, ASCII modunda görüntülenemeyen unicode karakterlerini benzeri ile **değiştirir**. Bu, arka uç **belirli bir karakter** beklerken farklı bir karakter alması durumunda **beklenmedik davranışlara** yol açabilir.
|
||||
|
||||
En iyi uyum karakterlerini **[https://worst.fit/mapping/](https://worst.fit/mapping/)** adresinde bulmak mümkündür.
|
||||
|
||||
Windows genellikle unicode dizelerini ASCII dizelerine, yürütmenin son aşamalarından biri olarak dönüştürdüğünden (genellikle "W" ile biten bir API'den "A" ile biten bir API'ye geçiş yaparak, örneğin `GetEnvironmentVariableA` ve `GetEnvironmentVariableW`), bu durum saldırganların, en son ASCII karakterlerine dönüştürülecek unicode karakterleri göndererek korumaları aşmalarına olanak tanır; bu da beklenmedik eylemler gerçekleştirebilir.
|
||||
|
||||
Blog yazısında, **karakterlerin kara listeye alınması** ile düzeltilebilecek zafiyetleri aşmak için önerilen yöntemler, [“/“ (0x2F) ile eşlenen karakterler](https://worst.fit/mapping/#to%3A0x2f) ve [“\“ (0x5C) ile eşlenen karakterler](https://worst.fit/mapping/#to%3A0x5c) kullanarak **yol geçişlerini** istismar etmek veya PHP'nin `escapeshellarg` veya Python'un `subprocess.run` gibi shell escape korumalarını aşmak için bir liste kullanarak yapılmıştır; bu, örneğin, çift tırnaklar yerine **tam genişlikte çift tırnaklar (U+FF02)** kullanılarak, sonunda 1 argüman gibi görünen şeyin 2 argümana dönüştüğü şekilde gerçekleştirilmiştir.
|
||||
|
||||
**Bir uygulamanın zayıf olması için "W" Windows API'lerini kullanması, ancak bir "A" Windows API'sini çağırması gerekir, böylece unicode dizisinin "En İyi Uyum"u oluşturulur.**
|
||||
|
||||
**Birçok keşfedilen zafiyet, bu sorunu kimin düzelteceği konusunda anlaşmazlık olduğu için düzeltilemeyecektir.**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user