Merhabalar, bu konumuzda Node.js ile yazılmış e-commerce rest api uygulamasının güvenliğini test edeceğiz. Analizimizi kaynak kod ve ilgili requestleri göndererek yapacağız.
Uygulamamızın başladığı index.js dosyasını açıp kodları okumaya başlayalım. Ben bu konuda ilk olarak kullanıcı kayıt, giriş ve user rotalarına odaklanacağım.
İlgili satırlarda routes dizini altında user ve auth dosyalarında ilgili işlemler dönüyor. Alt tarafta ise use ile belirtilen “api/auth” ve “api/users” değerleri ise bu rotalar için prefix tanımı diyebiliriz. Şimdi ilk olarak auth rotasından yola çıkalım.
Burada içe aktarılan dosyalarda router, user model, cypto işlemleri için crypto-js kütüphanesi ve olayımızın kahramanı json web token yer alıyor. Şimdi öncelikle user modeline gidip veri tabanı sütunlarımızı inceleyelim.
User tablomuzda username, email, password, isAdmin değerleri user bilgileri için tanımlanmış bulunuyor. isAdmin alanı ise kullanıcılar sisteme kayıt olduğunda default olarak false olarak set ediliyor yani kullanıcı admin değil anlamına geliyor.
Şimdi user rotamızdan devam edelim.
User rotası için tanımlı prefiximiz ile birlikte register rotasını da birleştirirsek “/api/auth/register” rotasına post request gönderildiği taktirde kullanıcı sisteme kayıt oluyor. Burada username, email ve password bilgileri alınıyor. Ayrıca password bilgisi AES ile hashlenerek veritabanında saklanıyor. Kayıt işlemi başarılı ise kullanıcı bilgileri json olarak 201 durum kodu ile dönüyor. Aksi taktirde 500 status kodu ile hata mesajı dönüyor. Bir de postman ile istek gönderip inceleyelim.
Kullanıcı başarıyla kayıt edilmiş oldu.
Şimdi kullanıcı login işlemine bakalım. “/api/auth/login” rotasına post olarak username ve password değerleri gönderilmesi gerekiyor. Öncelikle username veritabanında aranıyor yok ise “wrong credentials!” mesajı dönüyor. Eğer kullanıcı var ise öncelikle o kullanıcıya ait veritabanındaki hash edilmiş parola alınıp decrypt ediliyor. Yani düz hali elde ediliyor ve kullanıcının request de gönderdiği parola bilgisiyle eşleşirse giriş tamamlanıyor aksi durumda “wrong!” veriyor.
Giriş işlemi bu kadar mı değil tabii. Kullanıcı bilgileri doğru ise JWT aracılığıyla token oluşturuluyor. Bu token değerinde ise kullanıcı id ve isAdmin değeri saklanıyor. Sonraki satırlarda da password hariç kullanıcı bilgileri ve token cevap olarak dönüyor.
Yani böyle. Login olan kullanıcının bilgileri token değeriyle birlikte isteğe yanıt olarak sunuldu. Yani bu token değeri aslında kullanıcının kim olduğunu tanımlayacak. Şimdi kayıt olduk, giriş yaptık şimdi giriş yapan kullanıcı işlemlerine devam etsin.
Şimdi user rotasına gidelim.
User rotasında user model, router dışında verifyToken diye bir dosya dahil edilmiş ne halta yarıyor bakacağız şimdilik sallıyoruz.
Bu rota “/api/users/2112131313” vs şeklinde bir put request geldiği zaman kullanıcı bilgilerinin güncellenmesi için var. Requestte password geliyorsa önce hashleniyor daha sonra parametreden gelen id değeri kullanıcı tablosundaki id ile eşleşiyorsa requestin bodysinde yer alan bilgilerle user bilgileri güncelleniyor. İşte işin securitysine burada giriyoruz. Parametrede bir id göndersek bu id veritabanında geçerli olsa o kullanıcı bilgisini istediğimiz gibi güncellememiz mi gerekir? Hayır. Senin kim olduğun önemli. Ahmetken, mehmetin idyi göndersen güncelleyememen gerekir. Acaba bunun kontrolü bu yazılımda yapılmış mı? İşte burada “verifyTokenAndAuthorization” diye bir middleware karşımıza çıkıyoryani yazılımcı bunu tanımlamış. Büyük ihtimalle bu giriş yapan kullanıcının yetkisini kontrol ederek güncellemeye izin veriyor. VerifyToken dosyasına gidiyorum ve beni çeşitli fonksiyonlar karşılıyor.
İlk fonksiyon bu. Kısaca bu zımbırtı da requestin headerına token değerini koy hatta “Bearer asasesassdsa” bilmemne şeklinde koy, ben onu split edeyim sadece tokenı senden alırım diyor. Sen bana tokenı header da gönderdin ama yanlış ise “token is not valid!” derim, doğru ise nextlerim ne yapıyorsan yap hiç göndermezsen de “You are not authenticaed” derim login olunca ben sana token verdim sen onu bana vermezsen ben login olmadın sayarım diyor.
Bir önceki fonksiyon kullanıcının giriş yapıp yapmadığını doğruladı. Bu da yetkisine bakıyor. Requestte parametrede gelen token ile veritabanındaki id değeri eşleşiyorsa veya isAdmin değeri true ise kullanıcı bilgileri güncellensin diyor. Aksi taktirde “yetkisiz işlem” diyor. Yani kullanıcı bilgisini ya oturumu açık olan kullanıcı güncelleyecek ya da admin güncelleyecek. Elini kolunu sallayan güncellerse IDOR zafiyeti söz konusu diyebilirdik, Türkçesiyle yol geçen hanı zafiyeti.
Şimdi bu kaynak kodları okuduk zafiyet olmadığını tespit ettik bu durum hiç hoşumuza gitmedi. Ben statik kod analizi dışında olaya dinamiklikte katayım kafanızda görselleşsin.
Kullanıcı username bilgisini mahmut yapmak istiyor ve cevap olarak giriş yap mesajını alıyor. E yani sen login olduğundaki tokenı adama göster de kabul etsin. İçeri giriş bileti yani.
Tokenı gönderen muradına erer. Bu senaryo diğer user rotaları içinde bu şekilde akıyor. Arada farklı bir fonksiyon ona da bakalım.
Bu da sadece admin olmayı kabul ediyor.
Tüm user bilgilerini görme, user istatistiklerini görme erişimine de sadece admin sahipmiş. Bu konu boyunca adım adım kaynak kod analizi yaparak uygulama güvenliğini incelemiş olduk. E-ticaret uygulamasının auth ve user rotalarının güvenliğini test ettik.
VİDEOLU EĞİTİM
Okuduğunuz için teşekkürler.
Uygulamamızın başladığı index.js dosyasını açıp kodları okumaya başlayalım. Ben bu konuda ilk olarak kullanıcı kayıt, giriş ve user rotalarına odaklanacağım.
İlgili satırlarda routes dizini altında user ve auth dosyalarında ilgili işlemler dönüyor. Alt tarafta ise use ile belirtilen “api/auth” ve “api/users” değerleri ise bu rotalar için prefix tanımı diyebiliriz. Şimdi ilk olarak auth rotasından yola çıkalım.
Burada içe aktarılan dosyalarda router, user model, cypto işlemleri için crypto-js kütüphanesi ve olayımızın kahramanı json web token yer alıyor. Şimdi öncelikle user modeline gidip veri tabanı sütunlarımızı inceleyelim.
User tablomuzda username, email, password, isAdmin değerleri user bilgileri için tanımlanmış bulunuyor. isAdmin alanı ise kullanıcılar sisteme kayıt olduğunda default olarak false olarak set ediliyor yani kullanıcı admin değil anlamına geliyor.
Şimdi user rotamızdan devam edelim.
User rotası için tanımlı prefiximiz ile birlikte register rotasını da birleştirirsek “/api/auth/register” rotasına post request gönderildiği taktirde kullanıcı sisteme kayıt oluyor. Burada username, email ve password bilgileri alınıyor. Ayrıca password bilgisi AES ile hashlenerek veritabanında saklanıyor. Kayıt işlemi başarılı ise kullanıcı bilgileri json olarak 201 durum kodu ile dönüyor. Aksi taktirde 500 status kodu ile hata mesajı dönüyor. Bir de postman ile istek gönderip inceleyelim.
Kullanıcı başarıyla kayıt edilmiş oldu.
Şimdi kullanıcı login işlemine bakalım. “/api/auth/login” rotasına post olarak username ve password değerleri gönderilmesi gerekiyor. Öncelikle username veritabanında aranıyor yok ise “wrong credentials!” mesajı dönüyor. Eğer kullanıcı var ise öncelikle o kullanıcıya ait veritabanındaki hash edilmiş parola alınıp decrypt ediliyor. Yani düz hali elde ediliyor ve kullanıcının request de gönderdiği parola bilgisiyle eşleşirse giriş tamamlanıyor aksi durumda “wrong!” veriyor.
Giriş işlemi bu kadar mı değil tabii. Kullanıcı bilgileri doğru ise JWT aracılığıyla token oluşturuluyor. Bu token değerinde ise kullanıcı id ve isAdmin değeri saklanıyor. Sonraki satırlarda da password hariç kullanıcı bilgileri ve token cevap olarak dönüyor.
Yani böyle. Login olan kullanıcının bilgileri token değeriyle birlikte isteğe yanıt olarak sunuldu. Yani bu token değeri aslında kullanıcının kim olduğunu tanımlayacak. Şimdi kayıt olduk, giriş yaptık şimdi giriş yapan kullanıcı işlemlerine devam etsin.
Şimdi user rotasına gidelim.
User rotasında user model, router dışında verifyToken diye bir dosya dahil edilmiş ne halta yarıyor bakacağız şimdilik sallıyoruz.
Bu rota “/api/users/2112131313” vs şeklinde bir put request geldiği zaman kullanıcı bilgilerinin güncellenmesi için var. Requestte password geliyorsa önce hashleniyor daha sonra parametreden gelen id değeri kullanıcı tablosundaki id ile eşleşiyorsa requestin bodysinde yer alan bilgilerle user bilgileri güncelleniyor. İşte işin securitysine burada giriyoruz. Parametrede bir id göndersek bu id veritabanında geçerli olsa o kullanıcı bilgisini istediğimiz gibi güncellememiz mi gerekir? Hayır. Senin kim olduğun önemli. Ahmetken, mehmetin idyi göndersen güncelleyememen gerekir. Acaba bunun kontrolü bu yazılımda yapılmış mı? İşte burada “verifyTokenAndAuthorization” diye bir middleware karşımıza çıkıyoryani yazılımcı bunu tanımlamış. Büyük ihtimalle bu giriş yapan kullanıcının yetkisini kontrol ederek güncellemeye izin veriyor. VerifyToken dosyasına gidiyorum ve beni çeşitli fonksiyonlar karşılıyor.
İlk fonksiyon bu. Kısaca bu zımbırtı da requestin headerına token değerini koy hatta “Bearer asasesassdsa” bilmemne şeklinde koy, ben onu split edeyim sadece tokenı senden alırım diyor. Sen bana tokenı header da gönderdin ama yanlış ise “token is not valid!” derim, doğru ise nextlerim ne yapıyorsan yap hiç göndermezsen de “You are not authenticaed” derim login olunca ben sana token verdim sen onu bana vermezsen ben login olmadın sayarım diyor.
Bir önceki fonksiyon kullanıcının giriş yapıp yapmadığını doğruladı. Bu da yetkisine bakıyor. Requestte parametrede gelen token ile veritabanındaki id değeri eşleşiyorsa veya isAdmin değeri true ise kullanıcı bilgileri güncellensin diyor. Aksi taktirde “yetkisiz işlem” diyor. Yani kullanıcı bilgisini ya oturumu açık olan kullanıcı güncelleyecek ya da admin güncelleyecek. Elini kolunu sallayan güncellerse IDOR zafiyeti söz konusu diyebilirdik, Türkçesiyle yol geçen hanı zafiyeti.
Şimdi bu kaynak kodları okuduk zafiyet olmadığını tespit ettik bu durum hiç hoşumuza gitmedi. Ben statik kod analizi dışında olaya dinamiklikte katayım kafanızda görselleşsin.
Kullanıcı username bilgisini mahmut yapmak istiyor ve cevap olarak giriş yap mesajını alıyor. E yani sen login olduğundaki tokenı adama göster de kabul etsin. İçeri giriş bileti yani.
Tokenı gönderen muradına erer. Bu senaryo diğer user rotaları içinde bu şekilde akıyor. Arada farklı bir fonksiyon ona da bakalım.
Bu da sadece admin olmayı kabul ediyor.
Tüm user bilgilerini görme, user istatistiklerini görme erişimine de sadece admin sahipmiş. Bu konu boyunca adım adım kaynak kod analizi yaparak uygulama güvenliğini incelemiş olduk. E-ticaret uygulamasının auth ve user rotalarının güvenliğini test ettik.
VİDEOLU EĞİTİM
Okuduğunuz için teşekkürler.
Son düzenleme:
