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

# OAuth to Account takeover

<details>

<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Other ways to support HackTricks:

* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

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

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

OAuth çeşitli versiyonlar sunar, temel bilgilere [OAuth 2.0 dokümantasyonu](https://oauth.net/2/) üzerinden ulaşılabilir. Bu tartışma, yaygın olarak kullanılan [OAuth 2.0 yetkilendirme kodu hibe türü](https://oauth.net/2/grant-types/authorization-code/) üzerine odaklanmaktadır ve **bir uygulamanın başka bir uygulamadaki bir kullanıcının hesabına erişim veya işlem yapmasını sağlayan bir yetkilendirme çerçevesi** sunar (yetkilendirme sunucusu).

_Hayali bir web sitesi olan_ _**https://example.com**_'u düşünün, **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://example.com_ **sosyal medya gönderilerinize erişim izni** isteyecektir. Sonuç olarak, _https://socialmedia.com_ üzerinde **istenen izinleri ve isteği yapan geliştiriciyi** belirten bir onay ekranı görünecektir. Onayınızı verdikten sonra, _https://example.com_ **gönderilerinize sizin adınıza erişim** kazanır.

OAuth 2.0 çerçevesindeki aşağıdaki bileşenleri anlamak önemlidir:

* **resource owner**: **Kaynağınıza erişim izni veren** siz, yani **kullanıcı/varlık**.
* **resource server**: **Kimlik doğrulama sonrası istekleri yöneten sunucu**, örneğin **https://socialmedia.com**.
* **client application**: `resource owner`dan **yetki isteyen uygulama**, örneğin **https://example.com**.
* **authorization server**: `resource owner`ın başarılı kimlik doğrulaması ve yetkilendirmesi sonrası `client application`a **`access tokens` veren sunucu**, örneğin **https://socialmedia.com**.
* **client\_id**: Uygulama için genel, benzersiz bir tanımlayıcı.
* **client\_secret:** `access_tokens` oluşturmak için uygulama ve yetkilendirme sunucusu tarafından bilinen gizli bir anahtar.
* **response\_type**: **İstenen token türünü belirten** bir değer, örneğin `code`.
* **scope**: `client application`ın `resource owner`dan **istediği erişim seviyesi**.
* **redirect\_uri**: Yetkilendirme sonrası kullanıcının **yönlendirileceği URL**. Genellikle önceden kayıtlı yönlendirme URL'si ile uyumlu olmalıdır.
* **state**: Kullanıcının yetkilendirme sunucusuna yönlendirilmesi ve geri dönmesi sırasında **veriyi korumak için kullanılan** bir parametre. **CSRF koruma mekanizması** olarak hizmet etmesi için benzersizliği kritiktir.
* **grant\_type**: **Hibe türünü ve döndürülecek token türünü belirten** bir parametre.
* **code**: `authorization server`dan gelen yetkilendirme kodu, `client_id` ve `client_secret` ile birlikte `access_token` almak için client application tarafından kullanılır.
* **access\_token**: `client application`ın `resource owner` adına API istekleri için kullandığı **token**.
* **refresh\_token**: Uygulamanın **kullanıcıyı yeniden uyarmadan yeni bir `access_token` almasını sağlar**.

### Akış

**Gerçek OAuth akışı** şu şekilde ilerler:

1. [https://example.com](https://example.com) adresine gidip “Sosyal Medya ile Entegre Et” butonuna tıklarsınız.
2. Site, [https://socialmedia.com](https://socialmedia.com) adresine, https://example.com’un uygulamasının gönderilerinize erişmesine izin vermeniz için 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ın ardından, Sosyal Medya `code` ve `state` parametreleri ile `redirect_uri`'ye bir yanıt gönderir:
```
https://example.com?code=uniqueCode123&state=randomString123
```
5. https://example.com bu `code`'u, `client_id` ve `client_secret` ile birlikte, sizin adınıza bir `access_token` elde etmek için sunucu tarafında bir istek yapmak amacıyla kullanır ve bu sayede onayladığınız izinlere erişim sağlar:
```
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
```
6. Son olarak, süreç https://example.com'un `access_token` kullanarak Sosyal Medya'ya API çağrısı yapmasıyla tamamlanır.

## Güvenlik Açıkları <a href="#id-323a" id="id-323a"></a>

### Open redirect\_uri <a href="#cc36" id="cc36"></a>

`redirect_uri`, OAuth ve OpenID uygulamalarında güvenlik için çok önemlidir, çünkü yetkilendirme kodları gibi hassas verilerin yetkilendirme sonrası nereye gönderileceğini yönlendirir. Yanlış yapılandırılırsa, saldırganların bu istekleri kötü niyetli sunuculara yönlendirmesine izin vererek hesap ele geçirmeye olanak tanıyabilir.

Sömürme teknikleri, yetkilendirme sunucusunun doğrulama mantığına bağlı olarak değişir. Katı yol eşleştirmeden, belirtilen alan veya alt dizin içindeki herhangi bir URL'yi kabul etmeye kadar çeşitlilik gösterebilir. Yaygın sömürme yöntemleri arasında açık yönlendirmeler, yol geçişi, zayıf regexlerin kullanılması ve token 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 karşı savunmasızdır. Bu parametreler isteğe bağlıdır ve sunucular arasında destekleri değişiklik gösterir.

Bir OpenID sunucusunu hedefleyenler 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, kullanıcı kimlik doğruladıktan sonra sunucunun yanıtında yansıtılması** ve **XSS'ye karşı savunmasız olması** mümkün olabilir. 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 Uygunsuz Yönetimi <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 **kullanılmaması, statik bir değer olarak kullanılması veya düzgün bir şekilde doğrulanmaması** durumunda ortaya çıkar ve saldırganların CSRF korumalarını atlatmasına olanak tanır.

Saldırganlar, yetkilendirme sürecini kesintiye uğratarak kendi hesaplarını kurbanın hesabıyla ilişkilendirebilir, bu da potansiyel **hesap ele geçirmelerine** yol açar. Bu, OAuth'un **kimlik doğrulama amacıyla** kullanıldığı uygulamalarda özellikle kritiktir.

Bu zafiyetin gerçek dünya örnekleri çeşitli **CTF zorluklarında** ve **hacking platformlarında** belgelenmiştir ve pratik sonuçlarını vurgulamaktadır. Sorun, saldırganların bildirimleri veya ödemeleri kendi hesaplarına yönlendirebileceği **Slack**, **Stripe** ve **PayPal** gibi üçüncü taraf hizmetlerle yapılan entegrasyonlara da uzanır.

CSRF'ye karşı korunmak ve OAuth akışını güvence altına almak için **`state` parametresinin** doğru şekilde yönetilmesi ve doğrulanması çok önemlidir.

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

1. **Hesap Oluşturma Sırasında E-posta Doğrulaması Olmadan**: Saldırganlar, kurbanın e-postasını kullanarak önceden bir hesap oluşturabilir. Kurban daha sonra üçüncü taraf bir hizmeti giriş için kullanırsa, uygulama yanlışlıkla bu üçüncü taraf hesabını saldırganın önceden oluşturduğu hesapla ilişkilendirebilir ve yetkisiz erişime yol açabilir.
2. **Gevşek OAuth E-posta Doğrulamasını Sömürmek**: Saldırganlar, e-postaları doğrulamayan OAuth hizmetlerini kullanarak kendi hizmetlerine kaydolabilir ve ardından hesap e-postasını kurbanınkiyle değiştirebilir. Bu yöntem, ilk senaryoya benzer şekilde yetkisiz hesap erişimi riski taşır, ancak farklı bir saldırı vektörü üzerinden gerçekleşir.

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

Gizli OAuth parametrelerini tanımlamak ve korumak çok önemlidir. **`client_id`** güvenli bir şekilde açıklanabilirken, **`client_secret`**'in ifşa edilmesi önemli riskler taşır. `client_secret` ele geçirilirse, saldırganlar uygulamanın kimliğini ve güvenini kullanarak **kullanıcı `access_token`larını** ve özel bilgileri çalabilir.

Yaygın bir zafiyet, uygulamaların yetkilendirme `code`unu `access_token` ile değiştirme işlemini istemci tarafında yanlışlıkla gerçekleştirmesi durumunda ortaya çıkar. Bu hata, `client_secret`in açığa çıkmasına yol açar ve saldırganların uygulamanın kimliğine bürünerek `access_token` üretmesine 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 statüsünü daha fazla kötüye kullanabilir.

### Client Secret Bruteforce

Bir hizmet sağlayıcının client\_secret'ını kimlik sağlayıcısı ile **bruteforce** yaparak hesapları çalmayı deneyebilirsiniz.\
BF isteği şu şekilde görünebilir:
```
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 leaking Code + State

Müşteri **code ve state** değerlerine sahip olduğunda, **Referer header** içinde yansıtıldığında ve farklı bir sayfaya göz attığında, bu durumda savunmasızdır.

### Access Token Stored in Browser History

**Tarayıcı geçmişine gidin ve access token'ın orada kaydedilip kaydedilmediğini kontrol edin**.

### Everlasting Authorization Code

**Authorization code sadece belirli bir süre yaşamalıdır, böylece bir saldırganın onu çalabileceği ve kullanabileceği zaman penceresi sınırlanır**.

### Authorization/Refresh Token not bound to client

**Authorization code'u alabilir ve farklı bir müşteri ile kullanabilirseniz, diğer hesapları ele geçirebilirsiniz**.

### Happy Paths, XSS, Iframes & Post Messages to leak code & state values

[**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 bug bounty 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 değiştirmek için yeterli izinlere sahip olabileceğini** görebilirsiniz. Bu nedenle, **kullanıcı e-postasını farklı bir kullanıcı e-postası 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[...]

# 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"
}
]
}
```
AWS cognito'yu nasıl kötüye kullanabileceğiniz hakkında daha ayrıntılı bilgi için kontrol edin:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

### Diğer Uygulama Tokenlarını Kötüye Kullanma <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 kod değil) almayı bekleyen OAuth akışları, token'ın uygulamaya ait olup olmadığını kontrol etmezlerse savunmasız olabilirler.

Bu, bir **saldırganın** kendi **uygulamasında Facebook ile giriş yapmayı destekleyen 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 bu token'ı kullanarak kurbanın OAuth uygulamasında kurbanın kullanıcı token'ı ile giriş yapabilir**.

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

### İki bağlantı ve ç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ını sağlamak mümkündü. Bu bilgi bir **çerezde (RU)** saklanacak ve **daha sonraki bir adımda** **kullanıcıya** bu saldırganın ana bilgisayarına erişim izni verip vermek istemediği **sorulacaktır**.

Bu istemi atlatmak için, **returnUrl** kullanarak bu RU çerezini ayarlayacak **Oauth akışını** başlatmak için bir sekme açmak, istem gösterilmeden önce sekmeyi kapatmak ve bu değeri içermeyen yeni bir sekme açmak mümkündü. Daha sonra, **istem saldırganın ana bilgisayarını bildirmeyecek**, ancak çerez ona ayarlanmış olacak, bu nedenle **token yönlendirmede saldırganın ana bilgisayarına 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 oturum açmışlarsa verilen erişimi bir istemde onaylamalarının istenmesini **önlemek** için **`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), son URL'de kodun nerede sağlanmasını istediğinizi 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 fragment parametresi içinde sağlanır `#code=2397rf3gu93f`
* `response_mode=form_post` -> Kod bir POST formu içinde bir `code` adlı input ile sağlanır ve değeri
* `response_mode=web_message` -> Kod bir post mesajında gönderilir: `window.opener.postMessage({"code": "asdasdasd...`

### SSRFs 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'ta Dinamik İstemci Kaydı, **Server-Side Request Forgery (SSRF)** saldırıları için daha az belirgin ancak kritik bir vektör olarak hizmet eder. Bu uç nokta, OAuth sunucularının istemci uygulamaları hakkında ayrıntıları almasına izin verir, bu da kötüye kullanılabilecek hassas URL'leri içerebilir.

**Ana Noktalar:**

* **Dinamik İstemci Kaydı** genellikle `/register` ile eşleştirilir ve POST istekleri aracılığıyla `client_name`, `client_secret`, `redirect_uris` ve logolar veya JSON Web Key Sets (JWKs) için URL'ler gibi ayrıntıları kabul eder.
* Bu özellik, **RFC7591** ve **OpenID Connect Registration 1.0**'da belirtilen ve SSRF'ye karşı potansiyel olarak savunmasız parametrelere uyan özelliklere sahiptir.
* Kayıt süreci, sunucuları birkaç şekilde SSRF'ye maruz bırakabilir:
* **`logo_uri`**: Sunucu tarafından alınabilecek istemci uygulamasının logosu için bir URL, yanlış kullanılırsa SSRF'yi tetikleyebilir veya XSS'ye yol açabilir.
* **`jwks_uri`**: İstemcinin JWK belgesine bir URL, kötü niyetli olarak oluşturulmuşsa, sunucunun saldırgan tarafından kontrol edilen bir sunucuya dış istekler yapmasına neden olabilir.
* **`sector_identifier_uri`**: Sunucunun alabileceği `redirect_uris` JSON dizisine referans verir, bu da bir SSRF fırsatı yaratır.
* **`request_uris`**: İstemci için izin verilen istek URI'larını listeler, sunucu yetkilendirme sürecinin başında bu URI'ları alırsa kötüye kullanılabilir.

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

* 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 sömürü, beyaz liste kontrolleri ile hafifletilebilirken, önceden kayıtlı, saldırgan tarafından kontrol edilen 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ı ise [**muhtemel Yarış Koşulları için bunu okuyun**](race-condition.md).

## 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)

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

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

<details>

<summary><strong>Sıfırdan kahramana AWS hacking öğrenin</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> ile!</strong></summary>

HackTricks'i desteklemenin diğer yolları:

* **HackTricks'te şirketinizin reklamını görmek** veya **HackTricks'i PDF olarak indirmek** istiyorsanız [**ABONELİK PLANLARINI**](https://github.com/sponsors/carlospolop) kontrol edin!
* [**Resmi PEASS & HackTricks ürünlerini**](https://peass.creator-spring.com) edinin
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) koleksiyonumuzu, özel [**NFT'lerimizi**](https://opensea.io/collection/the-peass-family) keşfedin
* **💬 Discord grubuna** [**katılın**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın veya **Twitter'da** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live) **takip edin**.
* **HackTricks'e PR göndererek hacking ipuçlarınızı paylaşın** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına.

</details>