# Broken Authentication

## Broken Authentication Nedir?

Authentication, bir kullanıcının kimliğini doğrulama işlemidir. Kimlik doğrulama mekanizmalarındaki çoğu güvenlik açığı iki yoldan biriyle ortaya çıkar.

* Kimlik doğrulama mekanizmaları brute-force saldırılarına karşı yeterince koruma sağlayamadığı için zayıftır.
* Uygulamadaki mantık hataları veya kötü kodlama, kimlik doğrulama mekanizmalarının bir saldırgan tarafından tamamen atlanmasına izin verir.

<figure><img src="https://3737168764-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3ONffZJjq1KZ6NIRmS0c%2Fuploads%2FSNJWZAcvgNTANIpIbnd8%2F2025-05-24_19-42.png?alt=media&#x26;token=b53fc87c-8549-4dc8-8185-8f7bce09629d" alt=""><figcaption></figcaption></figure>

## Yöntemler

### Hydra Brute-Force

```bash
# Post Auth
hydra -l admin -P /usr/share/wordlists/rockyou.txt example.com http-post-form "/login.php:username=^USER^&password=^PASS^:invalid credentials" -V -t 64

# Basic Auth
hydra -L /usr/share/seclists/Usernames/top-usernames-shortlist.txt  -P /usr/share/seclists/Passwords/2023-200_most_used_passwords.txt 94.237.62.111 http-get / -s 33607
```

### IP Tabanlı Brute-Force Protection

Eğer brute-force koruması IP üzerinden yapıyorsak aşağıdaki başlıklar ile bu koruma atlatılabilir.

```http
X-Forwarded-For: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Client-IP: 127.0.0.1
```

### Doğru Giriş ile Brute-Force Protection Bypass

Eğer doğru giriş yaptığımızda brute-force sayacı sıfırlanıyorsa her brute-force denemesinin arasına doğru girişler koyabiliriz.

### Çoklu Parola ile Brute-Force Protection Bypass

Eğer login isteğinde json veri gönderiliyorsa ve parolanın bir liste olarak gönderilmesine izin veriliyorsa tek bir istek ile brute-force yapabiliriz.

### Client-Side 2FA

Eğer 2FA kontrolü client-side yapılıyorsa sadece yönlendirme ile bu koruma sağlanıyor olabilir. Kullanıcının profil sayfasını 2FA girmeden ziyaret etmeyi deneyebiliriz.

### Brute-Force 2FA

Eğer 2FA kodunda brute-force koruması yok ise ve bu kod kısa ise brute-force deneyebiliriz.

### Parametre Kontrolü

Parola sıfırlama isteğindeki parametreleri kontrol edebiliriz.

### Header ile Poisoning

Eğer parola sıfırlama linki aşağıdaki header kullanılarak üretiliyorsa, kurban linke tıkladığında istek bizim sunucumuza gönderilebilir.

```http
X-Forwarded-Host: <COLLABORATOR>
```

### Parola Sıfırlama ile Brute-Force

Eğer parola sıfırlama isteğinde username parametresi varsa diğer kullanıcılar için brute-force denemesi yapabiliriz.

### Brute-Force Cookie

Eğer kullanıcının session çerezi base64 gibi bir şifreleme kullanıyorsa bu çerez üzerinden brute-force denemeleri yapabiliriz. Login panelinde koruma olsa bile çerez için bir koruma yapılmamış olabilir.

### Şifrelenmiş Bir Kanal Üzerinden Taşınan Kimlik Bilgilerinin Test Edilmesi

Aşağıdaki gibi hassas veriler içeren hiçbir isteğin HTTP tarifiği üzerinden gönderilmemesi gerekir.

* Parolalar veya şifreler
* Body kısmındaki Tokenler
* Çerezlerin içinde Hesap veya şifre sıfırlama kodları

Sunucu bir session tokeni için çerez bilgisi döndürürse, istemcinin çerezi daha sonra şifrelenmemiş kanallar üzerinden ifşa etmesini önlemek için çerez Secure flag de içermelidir.

### Varsayılan Credential Testi <a href="#testing-for-default-credentials" id="testing-for-default-credentials"></a>

Eğer uygulama giriş paneli içeriyorsa varsayılan kullanıcı bilgileri ile giriş yapmayı deneyebiliriz. Ayrıca aşağıdaki gibi çok kullanılar bilgileri deneyebiliriz.

```bash
creds search mysql

+---------------------+-------------------+----------+
| Product             |      username     | password |
+---------------------+-------------------+----------+
| mysql               | admin@example.com |  admin   |
| mysql               |        root       | <blank>  |
| mysql (ssh)         |        root       |   root   |
| mysql               |      superdba     |  admin   |
| scrutinizer (mysql) |    scrutremote    |  admin   |
+---------------------+-------------------+----------+
```

### Zayıf Parolalar

```
admin:password
admin:admin
root:root
root:password
admin:admin1
admin:password1
root:password1
```

### Captcha Mekanizması

* Challange aritmetik veya tahmin edilebilir olmamalı.
* HTTP Response code ile kontrol yapılmamalı.
* Sunucu tarafı mantığı varsayılan olarak başarılı bir çözüme sahiptir.
* CAPTCHA meydan okuma sonucu hiçbir zaman sunucu tarafında doğrulanmaz.&#x20;
* CAPTCHA giriş alanı veya parametresi manuel olarak işlenir ve yanlış bir şekilde doğrulanır veya kaçar.
* CAPTCHA'yı çözmeden istek göndermeyi deneyin.
* Yanlış Captcha ile göndermeyi deneyin.
* Captcha değeri client-side tutuluyor olabilir.
* Zaten kullanılmış bir kodu deneyin.
* Cookie olmadan isteği gönderin belki cookie olmadığında kontrol edilmiyordur.
* Çok adımlı captca varsa direkt son adımı göndermeyi deneyin.
* Belki başka endpointte captcha koruması yoktur. (Örneğin aynı isteğin mobil apisi)

## Önlemler

* Giriş bilgileri her zaman https üzerinden gönderilmeli.
* Giriş bilgileri hiçbir zaman get parametreleri ile gönderilmemeli.
* Güçlü bir parola politikası uygulayın.
* Username enumeration zafiyetini engellemek için yanlış girişlerde her zaman aynı yanıtın döndüğüne emin olun.
* Brute-force saldırılarını engellemek için IP tabanlı rate-limit veya captcha koruması eklenmeli.
* Daha güçlü bir giriş için 2FA mekanizması ekleyin.

## Kaynaklar

* <https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/>
* <https://portswigger.net/web-security/authentication>
