Revealed content
A1: Broken Object Level Authorization
Revealed content
İlk sırayı, Insecure Direct Object Reference (IDOR) olarak bilinen ve yetkilendirme kontrolünü eksikliği sebebiyle meydana gelen güvenlik açığı alıyor.
Revealed content
Resimdeki örnek üzerinden gidecek olursak:
Revealed content
- Kullanıcı, erişmek istediği dokümanı sunucudan talep ediyor.
- Sunucu, gelen istekteki değere bakıyor. Bu değere referans eden nesneyi veri tabanından sorgulayıp, kullanıcıya cevap dönüyor.
Buraya kadar her şey normal gibi
Peki, kullanıcı kendi sahipliği dışındaki bir dokümanı görüntülemek istediğinde? İşte sorun burada başlıyor.
Eğer sunucu tarafında, kullanıcının erişmek istediği nesneye erişim yetkisinin olup, olmadığı kontrol edilmiyorsa bu güvenlik açığına karşı savunmasız durumda olacaktır. Kullanıcı, “1000” id değerine karşılık gelen doküman yerine, normalde erişim sağlayamaması beklenilen diğer kullanıcılara ait olan dokümanlara erişim sağlayabilir.
Doküman sahiplik bilgilerinin aşağıdaki gibi olduğunu varsayalım;
User1 kullanıcısı ile oturum açtıktan sonra yetki kontrolünün uygun bir şekilde yapılmaması sebebiyle id değeri “1002” olan ve User2 kullanıcısına ait doküman görüntülenebilir.
Örnek istekler:
https://example.com/previewDocument?Id=1000
https://example.com/previewDocument?Id=1002
Korunma Yöntemleri:
Eğer sunucu tarafında, kullanıcının erişmek istediği nesneye erişim yetkisinin olup, olmadığı kontrol edilmiyorsa bu güvenlik açığına karşı savunmasız durumda olacaktır. Kullanıcı, “1000” id değerine karşılık gelen doküman yerine, normalde erişim sağlayamaması beklenilen diğer kullanıcılara ait olan dokümanlara erişim sağlayabilir.
Doküman sahiplik bilgilerinin aşağıdaki gibi olduğunu varsayalım;
User1 kullanıcısı ile oturum açtıktan sonra yetki kontrolünün uygun bir şekilde yapılmaması sebebiyle id değeri “1002” olan ve User2 kullanıcısına ait doküman görüntülenebilir.
Örnek istekler:
https://example.com/previewDocument?Id=1000
https://example.com/previewDocument?Id=1002
Korunma Yöntemleri:
- Sunucu tarafında, kullanıcının yapacağı her işlem için yetki kontrolü sağlanmalıdır. İsteği yapan kullanıcının, erişmek isteğini nesneye erişim yetkisinin olup, olmadığı kontrol edilmelidir.
A2: Broken Authentication
Kimlik doğrulama mekanizması ve bileşenleriyle ilgili problemler bu başlık altında yer almaktadır.
Örnek olarak bu maddeler aşağıdaki gibidir:
Kimlik doğrulama mekanizması ve bileşenleriyle ilgili problemler bu başlık altında yer almaktadır.
Örnek olarak bu maddeler aşağıdaki gibidir:
- Korumasız API’ler
- Zayıf kimlik doğrulama mekanizmaları
- Zayıf imzalama/şifreleme algoritmalarının veya basit/varsayılan parolaların kullanımı
- Captcha veya hesap kitleme mekanizmaların eksikliği sebebiyle kaba kuvvet saldırılarına maruz kalınması
- URL’de bulunan hassas bilgiler (token ve kimlik bilgileri gibi)
- Token problemleri (validasyon ve geçerlilik süreleri gibi)
Örnekler arttırılabilir, genel olarak bu gibi maddeler Broken Authentication başlığı altında yer almaktadır.
Korunma Yöntemleri:
Korunma Yöntemleri:
- Kimlik doğrulama, token oluşturma ve saklama gibi işlemlerde standartların kullanılması önerilmektedir.
- Parola sıfırlama gibi tek kullanımlık oluşturulan bağlantılara özellikle dikkat edilmelidir.
- Kısa ömürlük token’ların kullanılması önerilmektedir.
- Sunucu tarafında, token’ın validasyonu uygun bir şekilde sağlanmalıdır.
- Multi faktör kimlik doğrulama (MFA) kullanılması önerilmektedir.
- Kaba kuvvet saldırılarına karşı istek sınırlaması, hesap kitleme veya captcha gibi mekanizmaların kullanılması önerilmektedir.
A3: Excessive Data Exposure
Kullanıcılar, çağırdıkları API’ler üzerinden çeşitli bilgiler edinebilir. Yapılan hatalardan birisi, kullanıcıya detaylı bir şekilde bilgi verilmesidir. Genellikle tercih edilen yöntem, sunucudan toplu bir şekilde veriyi döndürüp, kullanıcı tarafında filtreleme yapılması ve sadece istenilen bilgilerin kullanıcıya gösterilmesidir. Ancak, kullanıcı tarafında filtreleme yapıldığı için bu yöntem doğru bir yaklaşım değildir. Proxy ile araya girilerek, trafik incelendiğinde, sunucudan dönen cevaptaki tüm bilgiler açığa çıkacaktır.
Korunma Yöntemleri:
Kullanıcılar, çağırdıkları API’ler üzerinden çeşitli bilgiler edinebilir. Yapılan hatalardan birisi, kullanıcıya detaylı bir şekilde bilgi verilmesidir. Genellikle tercih edilen yöntem, sunucudan toplu bir şekilde veriyi döndürüp, kullanıcı tarafında filtreleme yapılması ve sadece istenilen bilgilerin kullanıcıya gösterilmesidir. Ancak, kullanıcı tarafında filtreleme yapıldığı için bu yöntem doğru bir yaklaşım değildir. Proxy ile araya girilerek, trafik incelendiğinde, sunucudan dönen cevaptaki tüm bilgiler açığa çıkacaktır.
Korunma Yöntemleri:
- Kullanıcı tarafında yapılan filtrelemelere asla güvenilmemelidir.
- Uygulamadan veri dönen noktalar incelenmeli, gereksinimi belirleyerek en az miktarda veri döndürülmelidir.
A4: Lack of Resource & Rate Limiting
API çağrıları yapılırken, istek sınırlaması olmaması sunucunun kaynaklarını gereksiz yere tüketerek, servis dışı kalmasına sebep olabilir.
Örneğin:
API çağrıları yapılırken, istek sınırlaması olmaması sunucunun kaynaklarını gereksiz yere tüketerek, servis dışı kalmasına sebep olabilir.
Örneğin:
- Uygulama üzerinde, dosya yükleme fonksiyonu olduğunu düşünelim. Eğer yüklenen dosyanın boyutu, sunucu tarafında sınırlandırılmadıysa, yüksek boyutlu dosyalar yüklenerek sunucunun disk alanını doldurabilir, hizmet dışı kalmasına sebep olabilir.
- Bir diğer örnek, uygulama üzerinde giriş yapılırken OTP kontrolü olduğunu düşünelim. Kullanıcı adı ve parola girişi sonrasında telefonumuza gelen OTP kodunu göndererek, giriş yapıyoruz. Eğer, OTP kodunu talep etmek için çağırdığımız API üzerinde istek sınırlaması yoksa, OTP kodu sürekli talep edilerek, servis gereksiz yere meşgul edilebilir ve normal kullanıcılardan gelen OTP kodu taleplerine cevap veremez hale gelebilir.
Korunma Yöntemleri:
- Yapılan istekler için boyut sınırlaması belirlenerek, sunucu tarafında kontrol edilmelidir.
- Cevapta döndürülecek kayıt sayısı kontrol edilmelidir.
- Belirli bir süre içerisinde API’nin ne sıklıkla çağırılabileceğine sınırlama getirilmelidir.
A5: Broken Function Level Authorization
Büyük ölçekli uygulamalarda, farklı kullanıcı hiyerarşileri, farklı roller ve gruplar bulunmaktadır. Bu durumda, rollerin ve grupların yapabileceği işlemler ve yetkiler birbirinden farklıdır. Yetkilendirmenin uygun bir şekilde kontrol edilmediği durumlarda bu zafiyet ortaya çıkabilir. Örneğin, yönetici rolüne sahip bir kullanıcının yapabileceği bir işlemin, daha düşük bir role sahip kullanıcı tarafından yapılabilmesine neden olabilir.
Örneğin:
Büyük ölçekli uygulamalarda, farklı kullanıcı hiyerarşileri, farklı roller ve gruplar bulunmaktadır. Bu durumda, rollerin ve grupların yapabileceği işlemler ve yetkiler birbirinden farklıdır. Yetkilendirmenin uygun bir şekilde kontrol edilmediği durumlarda bu zafiyet ortaya çıkabilir. Örneğin, yönetici rolüne sahip bir kullanıcının yapabileceği bir işlemin, daha düşük bir role sahip kullanıcı tarafından yapılabilmesine neden olabilir.
Örneğin:
- /api/users/user/myinfo # Kayıtlı kullanıcılar tarafından çağırılabilen ve kullanıcı bilgilerini döndüren endpoint.
- /api/admins/users/all # Yönetici rolüne sahip kullanıcılar tarafından çağırılması beklenilen ve tüm kullanıcıların bilgilerini döndüren endpoint.
Ancak, uygulama üzerinde yetki kontrollerinin uygun bir şekilde yapılmaması nedeniyle, normalde yönetici rolüne sahip kullanıcının çağırarak tüm kullanıcı bilgilerinin döndürüldüğü endpoint, yetkisiz bir kullanıcı tarafından çağırabilir.
Korunma Yöntemleri:
Korunma Yöntemleri:
- Farklı rolleri ve grupları göz önünde bulundurarak, yetkilendirme kontrollerinin uygun bir şekilde sağlanması gerekmektedir.
- Uygulama mekanizmaları varsayılan olarak tüm erişimleri reddetmeli, sadece uygun olan role yönelik işlemlere izin verilmelidir.
Bu içeriği görmek için giriş yapın.