hacktricks/pentesting-web/oauth-to-account-takeover.md

# OAuth ile Hesap Ele Geçirme

<details>

<summary><strong>AWS hackleme konusunda sıfırdan kahramana kadar öğrenin</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Kırmızı Takım Uzmanı)</strong></a><strong>!</strong></summary>

HackTricks'ı desteklemenin diğer yolları:

* **Şirketinizi HackTricks'te reklamını görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* [**Resmi PEASS & HackTricks ürünlerini**](https://peass.creator-spring.com) edinin
* [**PEASS Ailesi'ni**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* **💬 [Discord grubumuza](https://discord.gg/hRep4RUj7f) katılın veya [telegram grubumuza](https://t.me/peass) katılın veya bizi Twitter'da** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)** takip edin.**
* **Hacking püf noktalarınızı paylaşarak PR'lar göndererek** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına katkıda bulunun.

</details>

<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

## Temel Bilgiler <a href="#d4a8" id="d4a8"></a>

OAuth, [OAuth 2.0 belgelerinde](https://oauth.net/2/) erişilebilen çeşitli sürümler sunar. Bu tartışma genellikle yaygın olarak kullanılan [OAuth 2.0 yetkilendirme kodu tahsis türü](https://oauth.net/2/grant-types/authorization-code/) üzerinde odaklanır, bir **uygulamanın başka bir uygulamadaki bir kullanıcının hesabına erişmesine veya işlem yapmasına olanak tanıyan bir yetkilendirme çerçevesi sağlar** (yetkilendirme sunucusu).

Hayali bir web sitesini düşünün _**https://ornek.com**_, tüm sosyal medya gönderilerinizi, özel olanlar da dahil olmak üzere **sergilemek için tasarlanmıştır**. Bunu başarmak için OAuth 2.0 kullanılır. _https://ornek.com_, **sosyal medya gönderilerinize erişim izni** isteyecektir. Sonuç olarak, _https://sosyalmedya.com_ üzerinde bir onay ekranı belirecek ve **istenen izinler ile istekte bulunan geliştirici** belirtilecektir. Onayınızın ardından, _https://ornek.com_, **gönderilerinize sizin adınıza erişme yeteneği kazanır**.

OAuth 2.0 çerçevesi içinde aşağıdaki bileşenleri anlamanız önemlidir:

- **kaynak sahibi**: Siz, **kullanıcı/öğe** olarak, sosyal medya hesabınızın gönderilerine erişim izni verirsiniz.
- **kaynak sunucusu**: Uygulama, `erişim belirteci`ni `kaynak sahibi` adına aldıktan sonra kimlik doğrulama isteklerini yöneten **sunucu**, örneğin **https://sosyalmedya.com**.
- **istemci uygulaması**: `kaynak sahibi`nden yetki isteyen **uygulama**, örneğin **https://ornek.com**.
- **yetkilendirme sunucusu**: `kaynak sahibi`nin başarılı kimlik doğrulamasını ve yetkilendirmeyi sağladıktan sonra `erişim belirteçlerini` `istemci uygulamasına` veren **sunucu**, örneğin **https://sosyalmedya.com**.
- **client\_id**: Uygulama için genel, benzersiz bir tanımlayıcı.
- **client\_secret:** Yalnızca uygulama ve yetkilendirme sunucusu tarafından bilinen gizli bir anahtar, `erişim belirteçleri` oluşturmak için kullanılır.
- **response\_type**: İstenen **token türünü belirten** bir değer, örneğin `code`.
- **scope**: `istemci uygulamasının` `kaynak sahibinden` istediği **erişim seviyesi**.
- **redirect\_uri**: Yetkilendirme sonrası kullanıcının yönlendirileceği **URL**. Genellikle önceden kayıtlı yönlendirme URL'siyle uyumlu olmalıdır.
- **state**: Kullanıcının yetkilendirme sunucusuna yönlendirilirken ve oradan geri dönerken **verileri korumak için bir parametre**. Benzersizliği, **CSRF koruma mekanizması** olarak hizmet etmesi için önemlidir.
- **grant\_type**: **Tahsis türünü ve döndürülecek token türünü belirten** bir parametre.
- **code**: `yetkilendirme sunucusundan` alınan yetkilendirme kodu, `istemci uygulaması` tarafından `client_id` ve `client_secret` ile birlikte kullanılarak `erişim belirteci` elde etmek için kullanılır.
- **access\_token**: `istemci uygulamasının` API isteklerinde kullanacağı **token** `kaynak sahibi` adına.
- **refresh\_token**: Uygulamanın **kullanıcıya tekrar soru sormadan yeni bir `erişim belirteci` almasını sağlar**.

### Akış

**Gerçek OAuth akışı** şu şekilde devam eder:

1. [https://ornek.com](https://ornek.com) adresine giderek "Sosyal Medya ile Entegre Ol" düğmesini seçersiniz.
2. Site, ardından https://ornek.com'un uygulamasının gönderilerinize erişmesine izin vermeniz için [https://sosyalmedya.com](https://sosyalmedya.com) adresine bir istek gönderir. İstek şu şekilde yapılandırılmıştır:
```
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
```
3. Ardından bir onay sayfası ile karşılaşırsınız.

4. Onayınızı takiben, Sosyal Medya, `redirect_uri`'ye `code` ve `state` parametreleri ile bir yanıt gönderir:
```
https://example.com?code=uniqueCode123&state=randomString123
```
5. https://example.com, bu `code`'u, `client_id` ve `client_secret`'ı birlikte kullanarak sizin adınıza bir sunucu tarafı isteği yapar ve sizin onayladığınız izinlere erişim sağlayan bir `access_token` alır:
```
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
```
6. Son olarak, işlem, https://example.com'un `access_token`'ını kullanarak bir API çağrısı yaparak Sosyal Medya'ya erişir.

## Zafiyetler <a href="#323a" id="323a"></a>

### Açık redirect\_uri <a href="#cc36" id="cc36"></a>

`redirect_uri`, OAuth ve OpenID uygulamalarında güvenlik açısından önemlidir, çünkü hassas verileri, örneğin yetkilendirme kodlarını, yetkilendirme sonrası nereye gönderileceğini yönlendirir. Yanlış yapılandırılmışsa, saldırganların bu istekleri kötü amaçlı sunuculara yönlendirmesine izin vererek hesap ele geçirmesine olanak tanıyabilir.

Sömürü teknikleri, yetkilendirme sunucusunun doğrulama mantığına bağlı olarak değişir. Bunlar, katı yol eşleştirmesinden belirli etki alanı veya alt dizindeki herhangi bir URL'i kabul etmeye kadar uzanabilir. Yaygın sömürü yöntemleri arasında açık yönlendirmeler, yol geçişi, zayıf regexlerin sömürülmesi ve belirteç hırsızlığı için HTML enjeksiyonu bulunur.

`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 duyarlıdır. Bu parametreler isteğe bağlıdır ve destekleri sunucular arasında değişir.

Bir OpenID sunucusunu hedefleyenler için keşif ucu 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ı listeleyebilir. Bu ayrıntılar, sunucunun kayıt ucu noktasını ve diğer yapılandırma özelliklerini tanımlamada 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) muhtemelen yönlendirme **URL'sinin**, kullanıcı kimlik doğrulamasından sonra sunucunun yanıtında **yansıtıldığı** ve **XSS'ye duyarlı** olduğu olabilir. Test etmek için olası yük:
```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
```
### CSRF - Durum parametresinin yanlış işlenmesi <a href="#bda5" id="bda5"></a>

OAuth uygulamalarında, **`state` parametresinin** yanlış kullanımı veya ihmal edilmesi, **Cross-Site Request Forgery (CSRF)** saldırılarının riskini önemli ölçüde artırabilir. Bu zafiyet, `state` parametresinin ya **kullanılmaması, sabit bir değer olarak kullanılması veya doğru şekilde doğrulanmaması** durumunda ortaya çıkar ve saldırganların CSRF korumalarını atlamasına izin verir.

Saldırganlar, yetkilendirme sürecini ele geçirerek kendi hesaplarını kurbanın hesabıyla bağlantılı hale getirerek potansiyel **hesap ele geçirmelerine** yol açabilir. Bu özellikle OAuth'nin **kimlik doğrulama amaçlı** kullanıldığı uygulamalarda son derece kritiktir.

Bu zafiyetin gerçek dünya örnekleri çeşitli **CTF meydan okumalarında** ve **hacking platformlarında** belgelenmiş ve pratik sonuçlarını vurgulamıştır. Sorun, **Slack**, **Stripe** ve **PayPal** gibi üçüncü taraf hizmetlerle entegrasyonlara da uzanır, burada saldırganlar bildirimleri veya ödemeleri kendi hesaplarına yönlendirebilirler.

**`state` parametresinin** doğru şekilde işlenmesi ve doğrulanması, CSRF'ye karşı korunma ve OAuth akışını güvence altına alma açısından hayati öneme sahiptir.

### Hesap Ele Geçirme Öncesi <a href="#ebe4" id="ebe4"></a>

1. **Hesap Oluştururken E-posta Doğrulaması Olmadan**: Saldırganlar, kurbanın e-postasını kullanarak önceden bir hesap oluşturabilirler. Eğer kurban daha sonra giriş yapmak için üçüncü taraf bir hizmet kullanırsa, uygulama bu üçüncü taraf hesabını yanlışlıkla saldırganın önceden oluşturduğu hesapla ilişkilendirebilir ve yetkisiz erişime yol açabilir.

2. **Geçerli Olmayan OAuth E-posta Doğrulamasını Sömürme**: Saldırganlar, e-postaları doğrulamayan OAuth hizmetlerini sömürebilir ve kendi servislerine kaydolup daha sonra hesap e-postasını kurbanın e-postasıyla değiştirebilirler. Bu yöntem, ilk senaryoya benzer şekilde yetkisiz hesap erişimine yol açar, ancak farklı bir saldırı vektörü aracılığıyla gerçekleşir.

### Sırların Açığa Çıkarılması <a href="#e177" id="e177"></a>

Gizli OAuth parametrelerini tanımlamak ve korumak hayati önem taşır. **`client_id`** güvenle açıklanabilirken, **`client_secret`**'in açıklanması önemli riskler oluşturur. Eğer `client_secret` tehlikeye atılırsa, saldırganlar uygulamanın kimliğini ve güvenini sömürerek kullanıcı `access_token`'larını ve özel bilgileri **çalabilirler**.

Uygulamaların yetkilendirme `code`'unun `access_token` ile değiş tokuşunu sunucu tarafında değil istemci tarafında yanlış şekilde işlemesi durumunda yaygın bir zafiyet ortaya çıkar. Bu hata, `client_secret`'in açığa çıkmasına yol açar ve saldırganların uygulama adına `access_token`'lar oluşturmasına olanak tanır. Dahası, sosyal mühendislik aracılığıyla saldırganlar, OAuth yetkilendirmesine ek kapsamlar ekleyerek uygulamanın güvenilir durumunu daha da kötüye kullanabilirler.

### İstemci Sırrı Kaba Kuvvet Saldırısı

Kimlik sağlayıcı ile hizmet sağlayıcısının **istemci_sırrını kaba kuvvet** ile deneyebilir ve hesapları çalmaya çalışabilirsiniz.\
BF'ye yönelik istek benzer olabilir:
```
POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
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 sızdıran Code + State

Müşteri **code ve state**'e sahip olduktan sonra, farklı bir sayfaya göz attığında **Referer başlığında yansıtılıyorsa**, zayıf bir durumdadır.

### Erişim Belirteci Tarayıcı Geçmişinde Saklanıyor

Tarayıcı geçmişine gidin ve **erişim belirtecinin orada kaydedilip kaydedilmediğini kontrol edin**.

### Sonsuz Yetkilendirme Kodu

**Yetkilendirme kodu, saldırganın çalıp kullanabileceği zaman penceresini sınırlamak için sadece belirli bir süre yaşamalıdır**.

### Yetkilendirme/Yenileme Belirteci müşteriye bağlı değil

Eğer **yetkilendirme kodunu alabilir ve farklı bir müşteriyle kullanabilirseniz, diğer hesapları ele geçirebilirsiniz**.

### Mutlu Yollar, XSS, İframe'ler ve Kod & State değerlerini sızdırmak için Post Mesajları

**[Bu yazıyı 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/) görebilirsiniz ki **AWS Cognito**'nun kullanıcıya geri verdiği **belirtecin**, kullanıcı verilerini **üzerine yazma iznine sahip olabileceği**. Bu nedenle, **farklı bir kullanıcı e-postası için kullanıcı e-postasını değiştirebilirseniz**, başkalarının hesaplarını **ele geçirebilirsiniz**.
```bash
# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}
```
### Diğer Uygulamaların Token'larının Kötüye Kullanımı <a href="#bda5" id="bda5"></a>

[**Bu yazıda belirtildiği gibi**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), **token** (ve bir kod değil) bekleyen OAuth akışları, token'ın uygulamaya ait olup olmadığını kontrol etmezse savunmasız olabilir.

Bu, çünkü bir **saldırgan**, kendi uygulamasında **OAuth'yi destekleyen ve Facebook ile giriş yapan bir uygulama oluşturabilir**. Ardından, bir kurbanın Facebook'ta **saldırganın uygulamasında oturum açtığında**, saldırgan, **kurbanın OAuth uygulamasına verilen kullanıcı token'ını alabilir ve bu token'ı kullanarak kurbanın OAuth uygulamasına kurbanın kullanıcı token'ı ile oturum açabilir**.

{% hint style="danger" %}
Bu nedenle, saldırgan, kullanıcının kendi OAuth uygulamasına erişmesini sağlarsa, token'ın verildiği uygulama kimliğine bakılmaksızın token bekleyen ve token'ın uygulama kimliğine verilip verilmediğini kontrol etmeyen uygulamalarda kurbanın hesabını ele geçirebilecektir.
{% endhint %}

### İki bağlantı ve çerez <a href="#bda5" id="bda5"></a>

[**Bu yazıda belirtildiği gibi**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), bir kurbanın **dönüş URL'si**ni saldırganın ana bilgisayarına işaret eden bir sayfayı açmasını sağlamak mümkündü. Bu bilgi bir **çerezde (RU)** saklanacak ve **daha sonra** **prompt**, **kullanıcıya** bu saldırganın ana bilgisayarına erişim vermek isteyip istemediğini **soracaktır**.

Bu prompt'u atlamak için, **dönüş URL'sini** kullanan bu RU çerezini ayarlayacak **Oauth akışını başlatmak için bir sekme açmak**, prompt gösterilmeden önce sekme kapatmak ve bu değeri olmadan yeni bir sekme açmak mümkündü. Ardından, **prompt, saldırganın ana bilgisayarından bahsetmeyecek**, ancak çerez ona ayarlanacak, böylece **token yönlendirmede saldırganın ana bilgisayarına gönderilecektir**.

### SSRF parametreleri <a href="#bda5" id="bda5"></a>

Bu tekniğin daha fazla ayrıntısı için **[bu araştırmayı kontrol edin](https://portswigger.net/research/hidden-oauth-attack-vectors)**.

OAuth'da Dinamik İstemci Kaydı, özellikle **Sunucu Tarafı İstek Sahtekarlığı (SSRF)** saldırıları için daha az açık ancak kritik bir vektör olarak hizmet verir. Bu uç nokta, OAuth sunucularının hassas URL'leri de içeren istemci uygulamaları hakkında ayrıntılar almasına olanak tanır.

**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 Kümesi (JWK'ler) için URL'ler gibi ayrıntıları kabul eder.
- Bu özellik, **RFC7591** ve **OpenID Connect Registration 1.0** tarafından belirlenen özelliklere uyar ve SSRF'ye açık olabilecek parametreleri içerir.
- Kayıt süreci, sunucuları yanlışlıkla SSRF'ye maruz bırakabilir:
- **`logo_uri`**: Sunucu tarafından alınabilecek istemci uygulamasının logosu için bir URL, SSRF'yi tetikleyebilir veya URL yanlış işlenirse XSS'e yol açabilir.
- **`jwks_uri`**: İstemcinin JWK belgesine bir URL, kötü amaçlı olarak oluşturulursa, sunucunun saldırganın kontrol ettiği bir sunucuya çıkış istekleri yapmasına neden olabilir.
- **`sector_identifier_uri`**: Bir JSON dizisine `redirect_uris` referans verir, sunucu bunu alarak SSRF fırsatı yaratabilir.
- **`request_uris`**: İstemci için izin verilen istek URI'lerini listeler, sunucunun yetkilendirme sürecinin başında bu URI'leri alması durumunda sömürülebilir.

**Sömürü Stratejisi:**

- SSRF, `logo_uri`, `jwks_uri` veya `sector_identifier_uri` gibi parametrelerde kötü amaçlı URL'lerle yeni bir istemci kaydedilerek tetiklenebilir.
- Doğrudan `request_uris` üzerinden sömürü belki de beyaz liste kontrolleri ile hafifletilebilir, ancak önceden kaydedilmiş, saldırgan tarafından kontrol edilen bir `request_uri` sağlamak, yetkilendirme aşamasında SSRF'yi kolaylaştırabilir.