Portswigger : Authentication vulnerabilities

Portswigger : Authentication vulnerabilities Parola Sıfırlama İşlemleri

Parola Sıfırlama İşlemleri

Gerçek hayatta kullanıcıların parolalarını unutması oldukça yaygın bir durum. Bu yüzden çoğu web uygulaması, kullanıcıların parolalarını sıfırlayabilmeleri için bir mekanizma sunar. Ancak parola temelli kimlik doğrulaması bu senaryoda mümkün olmadığından, sitelerin gerçek kullanıcının kendi parolasını sıfırladığından emin olmak için alternatif yöntemlere başvurması gerekir.

Gerçek hayatta kullanıcıların parolalarını unutması oldukça yaygın bir durum. Bu yüzden çoğu web uygulaması, kullanıcıların parolalarını sıfırlayabilmeleri için bir mekanizma sunar. Ancak parola temelli kimlik doğrulaması bu senaryoda mümkün olmadığından, sitelerin gerçek kullanıcının kendi parolasını sıfırladığından emin olmak için alternatif yöntemlere başvurması gerekir.

Bu nedenle, parola sıfırlama özelliği doğası gereği risklidir ve mutlaka güvenli şekilde uygulanmalıdır.

Bu işlev farklı şekillerde tasarlanabilir ve her yöntemin kendine göre farklı zafiyet seviyeleri bulunur.

Parolaların E‑posta ile Gönderilmesi

Aslında güvenli parola yönetimi uygulayan bir sitede, kullanıcının mevcut parolasının e‑posta ile gönderilmesi zaten mümkün olmamalıdır. Bunun yerine bazı siteler, yeni bir parola üretip bunu kullanıcıya e‑posta yoluyla iletir.

Genel olarak, kalıcı parolaların güvenli olmayan kanallar üzerinden gönderilmesi kesinlikle kaçınılması gereken bir durumdur. Böyle bir yöntem kullanılıyorsa, güvenlik yalnızca oluşturulan geçici parolanın çok kısa bir süre içinde geçerliliğini yitirmesine veya kullanıcının parolasını hemen değiştirmesine dayanır. Aksi halde, bu yaklaşım ortadaki adam (Man‑in‑the‑Middle) saldırılarına oldukça açık hale gelir.

E‑postanın kendisi de güvenli bir ortam olarak kabul edilmez. Çünkü gelen kutuları kalıcıdır ve gizli verileri güvenli şekilde saklamak için tasarlanmamıştır. Üstelik birçok kullanıcı, e‑posta kutusunu birden fazla cihazla otomatik olarak senkronize ederek daha da güvensiz kanallar üzerinden erişilebilir hale getirir.

URL Kullanarak Parola Sıfırlama

Parolaları sıfırlamak için daha güvenli bir yöntem, kullanıcılara parola sıfırlama sayfasına yönlendiren benzersiz bir URL göndermektir. Ancak bu yöntemin zayıf uygulanmış bazı versiyonları, hangi hesabın sıfırlandığını belirlemek için kolay tahmin edilebilir parametreler kullanır. Örneğin:

http://vulnerable-website.com/reset-password?user=victim-user

Bu senaryoda, bir saldırgan “user” parametresini bildiği herhangi bir kullanıcı adıyla değiştirerek, o hesaba ait parola sıfırlama sayfasına doğrudan erişebilir. Bu sayfada da hedef kullanıcının parolasını yeniden belirleme şansı elde eder.

Bu nedenle, bu tarz tahmin edilebilir parametreler içeren parola sıfırlama mekanizmaları oldukça risklidir ve kötüye kullanılmaya çok açıktır.

Bu sürecin daha güvenli bir uygulaması, yüksek entropili ve tahmin edilmesi zor bir token oluşturmak ve sıfırlama URL’sini bu token üzerinden tasarlamaktır. En ideal senaryoda, bu URL kullanıcının kimliğine dair hiçbir ipucu vermez.

Örnek bir URL:

http://vulnerable-website.com/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8

Kullanıcı bu URL’yi ziyaret ettiğinde, sistem arka planda bu token’ın var olup olmadığını ve hangi kullanıcının parolasını sıfırlamak için oluşturulduğunu kontrol etmelidir. Token kısa süreli geçerli olmalı ve parola sıfırlandıktan hemen sonra silinmelidir.

Ancak bazı web siteleri, kullanıcı sıfırlama formunu gönderdiğinde token’ı tekrar doğrulamayı ihmal eder. Bu durumda bir saldırgan, kendi hesabı üzerinden sıfırlama formuna gidip token’ı silebilir ve bu sayfayı kullanarak rastgele bir kullanıcının parolasını sıfırlayabilir .

Bu yüzden, token doğrulamasının hem URL ziyaretinde hem de form gönderiminde yapılması kritik önemdedir.

Lab: Password reset broken logic

Bu labda, parola sıfırlama sürecindeki bir mantık hatasını sömürerek hedef kullanıcının parolasını değiştirmemiz isteniyor. Amacımız, Carlos’un parolasını sıfırlamak ve ardından onun “My account” sayfasına erişmek.

Lab bize şu bilgileri veriyor:

Bizim hesabımız: wiener : peter

Kurban kullanıcı: carlos

Görev oldukça net: Parola sıfırlama akışındaki açığı kullanarak Carlos’un şifresini değiştirmek ve hesabına erişmek.

Öncelikle Burp açıkken, sitedeki Forgot your password? bağlantısına tıklayıp kendi kullanıcı adımızı ( wiener ) giriyoruz.

Sonrasında Email client butonundan gönderilen reset mailini açıyoruz. Maildeki link bizi parola sıfırlama sayfasına götürüyor ve burada yeni bir şifre belirleyebiliyoruz.

şifreyi sıfırladım ve burp suite içindeki istekleri incelemeye başladım. Bu adım, bize labın sistem işleyişini incelemek için gerekli veriyi sağlıyor.

Maildeki bağlantının içindeki temp-forgot-password-token parametresinin şifre sıfırlarken hem URL’de hem de body içinde gönderildiğini fark ettim. Bu POST isteğini Repeater’a aldım ve test etmek için hem URL’deki hem de body’deki token değerini tamamen sildim. Buna rağmen şifrem yine değişti. Yani sistem token’ı hiç kontrol etmiyordu.isteği repertera attım ve wiener kullanıcı adını carlos ile değiştirip şifresini değiştirdim ve isteği gönderdim.

Token doğrulaması olmadığı için sistem bu isteği kabul etti ve Carlos’un şifresi benim yazdığım şifreye resetlendi. Son olarak Carlos kullanıcı adı ve belirlediğim şifreyle giriş yapıp “My account” sayfasına girdim.

Aslında bu lab bana, küçük bir mantık hatasının bile ne kadar büyük sonuçlar doğurabileceğini çok net gösterdi. Token’ın POST aşamasında kontrol edilmemesi, şifre sıfırlamayı tamamen güvenilmez hale getiriyor.Gerçek hayatta böyle bir açık olsaydı, herhangi bir saldırgan kolayca kullanıcı hesaplarına erişebilirdi. Bu yüzden password reset mekanizmalarının güvenli tasarlanması gerçekten çok önemli.Bu lab hem mantığını anlamak açısından çok öğreticiydi hem de uygulaması eğlenceliydi. Bir sonraki labda görüşmek üzere