HTTP Basic Authentication
HTTP Basic Authentication
User rate limiting
Web sitelerinin brute-force saldırılarını önlemek için kullandığı yöntemlerden biri de kullanıcı bazlı istek sınırlandırmadır. Bu yöntemde, kısa bir süre içinde çok fazla giriş denemesi yapılması IP adresinizin engellenmesine neden olur. Genellikle bu engel şu yöntemlerden biriyle kaldırılabilir:
Belirli bir süre geçtikten sonra otomatik olarak
Bir yönetici tarafından manuel olarak
Kullanıcı tarafından bir CAPTCHA doğrulamasını başarıyla tamamladıktan sonra manuel olarak
Kullanıcı bazlı istek sınırlandırma, kullanıcı adı enumerasyonuna ve hizmet reddi (DoS) saldırılarına daha az açık olduğu için bazen hesap kilitlemeye göre tercih edilir. Ancak yine de tamamen güvenli değildir. Daha önceki bir labda gördüğümüz gibi, bir saldırgan görünür IP adresini manipüle ederek bu engeli çeşitli yollarla aşabilir.
Limit, kullanıcının IP adresinden gönderilen HTTP isteklerinin hızına bağlı olduğundan, tek bir istekle birden fazla şifre denemeyi mümkün kılacak bir yöntem bulabilirseniz bu koruma da atlatılabilir.
HTTP Basic Authentication
Eski bir yöntem olmasına rağmen, basit yapısı ve kolay uygulanabilirliği sayesinde HTTP Basic Authentication hâlâ bazı sistemlerde kullanılabilmektedir. Bu yöntemde sunucu, istemciye bir kimlik doğrulama token’ı gönderir. Bu token, kullanıcı adı ve şifrenin birleştirilip Base64 formatında kodlanmasıyla oluşturulur.
Tarayıcı bu token’ı saklar ve yönetir. Daha sonra yapılan tüm isteklerde bu token otomatik olarak Authorization başlığına şu şekilde eklenir:
Authorization: Basic base64(username:password)
HTTP Basic Authentication, çeşitli sebeplerden dolayı genel olarak güvenli bir kimlik doğrulama yöntemi olarak kabul edilmez. Öncelikle, her istekte kullanıcının giriş bilgilerini tekrar tekrar göndermesi gerekir. Site HSTS kullanmıyorsa, bu kimlik bilgileri ortadaki adam (MITM) saldırılarında kolayca ele geçirilebilir.
‼️HSTS, kullanıcıların kimlik bilgileri ve diğer hassas verilerinin HTTP üzerinden iletilip ele geçirilmesini önlemek için kullanılan bir güvenlik önlemidir. Özellikle HTTP Basic Authentication gibi yöntemlerde HSTS yoksa, parolalar MITM saldırılarına açık kalır.
Ayrıca HTTP Basic Authentication çoğu zaman brute-force koruması da sunmaz. Token tamamen statik değerlerden oluştuğu için, brute-force saldırılarına karşı savunmasız kalabilir.
HTTP Basic Authentication, özellikle oturumla ilgili zafiyetlere — başta CSRF olmak üzere — karşı da oldukça açıktır ve kendi başına herhangi bir koruma sağlamaz.
Bazı durumlarda, zafiyet içeren HTTP Basic Authentication’ı istismar etmek saldırgana ilk bakışta önemsiz gibi görünen bir sayfaya erişim sağlayabilir. Ancak bu bile ek bir saldırı yüzeyi oluşturur. Dahası, bu şekilde ele geçirilen kimlik bilgileri çoğu zaman başka, daha kritik sistemlerde yeniden kullanıldığı için çok daha ciddi güvenlik risklerine yol açabilir.
Bu bölümde, çok faktörlü kimlik doğrulama (MFA) mekanizmalarında ortaya çıkabilen bazı zafiyetleri inceleyeceğiz. Ayrıca, çok faktörlü kimlik doğrulamadaki bu zafiyetleri nasıl istismar edebileceğinizi göstermek için birkaç etkileşimli lab da sağladık.
Birçok web sitesi kullanıcıları doğrulamak için yalnızca parola kullanan tek faktörlü kimlik doğrulamaya dayanır. Ancak bazıları, kullanıcıların kimliklerini birden fazla doğrulama faktörüyle kanıtlamasını ister.
Çoğu web sitesi için biyometrik faktörlerin doğrulanması pratik değildir. Ancak “bildiğiniz bir şey” ve “sahip olduğunuz bir şey”e dayalı hem zorunlu hem de isteğe bağlı iki faktörlü kimlik doğrulama (2FA) kullanımı giderek daha yaygın hale geliyor. Bu yöntem genellikle kullanıcının hem geleneksel bir parola hem de sahip olduğu fiziksel bir cihazdan üretilen geçici bir doğrulama kodu girmesini gerektirir.
Bir saldırganın bazen parola gibi bilgi tabanlı tek bir faktörü ele geçirmesi mümkün olsa da, aynı anda başka bir doğrulama faktörünü — özellikle de sistem dışı (out-of-band) bir kaynaktan geleni — ele geçirmesi çok daha düşük bir ihtimaldir. Bu nedenle iki faktörlü kimlik doğrulama, tek faktörlü kimlik doğrulamaya kıyasla ölçülebilir biçimde daha güvenlidir.
Ancak tüm güvenlik önlemlerinde olduğu gibi, 2FA da uygulandığı kadar güvenlidir. Kötü uygulanmış iki faktörlü doğrulama, tıpkı tek faktörlü doğrulama gibi kırılabilir veya tamamen atlatılabilir.
Ayrıca çok faktörlü kimlik doğrulamanın gerçek faydalarının ancak birden fazla farklı faktör doğrulandığında ortaya çıktığını unutmamak gerekir. Aynı faktörü iki farklı yolla doğrulamak gerçek anlamda iki faktörlü kimlik doğrulama değildir. E-posta tabanlı 2FA buna bir örnektir. Kullanıcı hem parola hem de doğrulama kodu giriyor olsa da, bu doğrulama koduna erişmek yalnızca e-posta hesabının giriş bilgilerinin bilinmesine bağlıdır. Yani bilgi tabanlı doğrulama faktörü aslında iki kez doğrulanmış olur.
Two-factor authentication tokens
Doğrulama kodları genellikle kullanıcının fiziksel bir cihazdan okuduğu kodlardır. Günümüzde pek çok yüksek güvenlikli web sitesi, bu amaç için kullanıcılara özel olarak tasarlanmış cihazlar sunar. Örneğin, çevrim içi bankacılık veya iş dizüstü bilgisayarınıza erişirken kullanılan RSA token’ları veya tuş takımlı doğrulama cihazları. Bu cihazlar yalnızca güvenlik için tasarlanmış olmakla kalmaz, aynı zamanda doğrulama kodunu doğrudan kendileri üretme avantajına sahiptir.
Benzer şekilde, Google Authenticator gibi özel mobil uygulamaların kullanılması da oldukça yaygındır.
Buna karşılık, bazı web siteleri doğrulama kodlarını kullanıcının telefonuna SMS olarak gönderir. Teknik olarak hâlâ “sahip olduğunuz bir şey” faktörünü doğrulasa da, bu yöntem kötüye kullanıma daha açıktır. Öncelikle kod, cihazın kendisi tarafından üretilmek yerine SMS üzerinden iletilir. Bu durum, kodun iletim sırasında ele geçirilme ihtimalini ortaya çıkarır.
Ayrıca SIM değiştirme (SIM swapping) riski de vardır. Bu saldırıda bir saldırgan, kurbanın telefon numarasına sahip sahte bir SIM kart edinir. Böylece kurbana gönderilen tüm SMS mesajları — doğrulama kodu dahil — saldırganın eline geçer.
Bypassing two-factor authentication
Bazen iki faktörlü kimlik doğrulama o kadar hatalı şekilde uygulanır ki, tamamen atlatılabilir hale gelir.
Eğer kullanıcı önce parola girmeye yönlendiriliyor, ardından ayrı bir sayfada doğrulama kodu girmesi isteniyorsa, kullanıcı doğrulama kodunu girmeden önce fiilen “oturum açmış” sayılabilir. Bu durumda, ilk doğrulama adımını tamamladıktan sonra doğrudan yalnızca giriş yapılmış kullanıcıların erişebildiği sayfalara geçiş yapıp yapamayacağınızı test etmek faydalı olur.
Bazı durumlarda, web sitesinin ilgili sayfayı yüklemeden önce ikinci adımı gerçekten tamamlayıp tamamlamadığınızı kontrol etmediğini görebilirsiniz.
Lab: 2FA simple bypass
Bu lab bize 2 kullanıcı hesabı vermiş 1. hesap bize ait olan 2. hesap kurban . 2fa bypass kullanarak bizim kurban hesabına giriş yapmamız bekleniyor
İlk olarak kendi hesabıma giriş yaptım. 2FA doğrulama kodu e‑posta ile geldiği için, Email client butonuna tıklayıp mail kutuma geçtim ve kodu gördüm.
Ardından hesabımın /my-account sayfasına gidip URL’yi özellikle not aldım çünkü birazdan işime yarayacaktı.
https://0ab9001f0433af7980aed59900170087.web-security-academy.net/my-account?id=wiener
Sonra hesabımdan çıkış yaparak kurban kullanıcıya geçtim. Elimde geçerli kullanıcı adı ve şifre olduğu için giriş adımını sorunsuz tamamladım. Fakat ikinci adımda (2FA kodu ekranında) durduruldum.
İşte zafiyet tam burada ortaya çıkıyor. 2FA ekranında beklemek yerine, URL’yi manuel olarak değiştirdim ve daha önce not aldığım /my-account yoluna direkt gittim.
Sayfa herhangi bir doğrulama yapılmadan yüklendi ve böyle carlos kullanıcısına 2 faktörlü doğrulama yapmadan giriş yapabildim.
Hatalı iki aşamalı doğrulama mantığı (Flawed two-factor verification logic)
Bazen iki aşamalı doğrulama (2FA) sürecindeki hatalı mantık nedeniyle, kullanıcı ilk aşamadaki giriş adımını başarıyla tamamlasa bile, web sitesi ikinci adımı tamamlayan kişinin gerçekten aynı kullanıcı olup olmadığını yeterince doğrulamaz. Örneğin, kullanıcı giriş sürecinin ilk adımında normal kullanıcı adı ve şifresiyle oturum açar:
POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
username=carlos&password=qwerty
Bu adımın ardından kullanıcıya hesabıyla ilişkili bir cookie atanır ve giriş sürecinin ikinci adımına yönlendirilir:
HTTP/1.1 200 OK
Set-Cookie: account=carlos
GET /login-steps/second HTTP/1.1
Cookie: account=carlos
Kullanıcı doğrulama kodunu gönderdiğinde, sunucu hangi hesabın doğrulanmaya çalışıldığını anlamak için bu cookie değerini kullanır:
POST /login-steps/second HTTP/1.1 Host: vulnerable-website.com Cookie: account=carlos … verification-code=123456
Bu durumda bir saldırgan, kendi hesabıyla giriş yapabilir ancak doğrulama kodunu gönderirken cookie içindeki account değerini istediği herhangi bir kullanıcı adıyla değiştirerek işlem yapabilir:
POST /login-steps/second HTTP/1.1 Host: vulnerable-website.com Cookie: account=victim-user … verification-code=123456
Eğer saldırgan doğrulama kodunu brute‑force ile tahmin edebiliyorsa, bu durum son derece tehlikelidir. Çünkü sadece kullanıcı adını bilerek herhangi bir kullanıcının hesabına erişim sağlayabilir. Bu süreçte kullanıcının şifresini bilmesine bile gerek kalmaz.
