Aslında erişim kontrolleri açıklıkları için yapılacaklar kısmen daha önceki adımlarla (oturum yönetimi, kullanıcı tanılama kontrolleri vs.) ilgilidir. Ancak erişim kontrolleri odaklı bir çalışma yaparken aşağıdaki prosedürleri ya önceki adımların çıktılarından ya da bu noktada gerçekleştirerek daha kapsamlı bir sonuca varabiliriz. Öncelikle erişim kontrolleriyle ilgili şu soruları sorarak başlayabiliriz:
- Uygulama fonksiyonları kullanıcılara sadece kendilerine ait olan ve sunucu tarafından saklanan toplam verinin bir kısmına mı erişmeye izin veriyor?
- Farklı seviyelerdeki kullanıcılar (örneğin müdürler, ekip liderleri, ziyaretçiler, vs.) uygulamanın farklı ve/veya sınırlı fonksiyonlarına mı erişebiliyorlar?
- Uygulama yöneticileri (administrators) uygulamanın konfigürasyon ve izlemesi için uygulama tarafından sağlanan fonksiyonaliteyi mi kullanıyor?
- Uygulama fonksiyonalitesi içinde mevcut kullanıcı haklarınızı yükseltecek bir fonksiyon belirlediniz mi?
Yukarıda da bahsettiğimiz gibi erişim kontrollerini test etmenin en kolay ve kapsamlı yolu uygulama kaynaklarına birden fazla kullanıcıyla erişmek, daha sonra bir kullanıcının ulaşabildiği kaynaklara başka (düşük haklı veya erişim yetkisi olmayan) bir kullanıcıyla illegal olarak erişilip erişilemediğini test etmektir. Bunun için aşağıdaki denetim prosedürü uygulanabilir:
- Eğer uygulama kullanıcı seviyesine göre farklı fonksiyonaliteye erişime izin veriyorsa önce güçlü bir kullanıcı koduyla tüm erişilebilir fonksiyonalite belirlenmeli, daha sonra daha düşük haklara sahip bir kullanıcıyla bu fonksiyonaliteye erişilmeye çalışılmalıdır.
- Eğer uygulama aynı seviyedeki kullanıcılar için farklı doküman kaynaklarına erişimi kontrol ediyorsa, yatay erişim kontrolü denetimi için birinci kullanıcının eriştiği bir dokümana ikinci kullanıcı ile aynı URL veya POST parametreleri ile erişilebilip erişilemediği test edilmelidir.
- Yukarıdaki testleri gerçekleştirmek için bir örümcekten faydalanılabilir. Önce yönetici kullanıcısıyla taranan web uygulama linklerine normal kullanıcının oturum token’ı kullanılarak otomatik olarak erişilmeye çalışılabilir. Böylece kısıtlı alanlara normal kullanıcının da erişip erişemediği denetlenebilir, ancak test sonuçlarının yorumlanması için uygulamanın davranışı da önemlidir. Örneğin uygulama erişilemeyecek kaynaklara erişmek istenmesi durumunda 200 OK yanıtı dönüyor ancak içeriğinde hata mesajı veriyor olabilir.
Eğer tek bir kullanıcı kodu veya hiçbir geçerli kullanıcı koduna sahip değilsek daha farklı ve daha fazla bir denetim prosedürü uygulamamız gerekir. Aslında kapsamlı bir denetim yapmak için uygulama fonksiyonalitesinin ötesinde unutulan eski fonksiyonalite, yayınlanmaması gereken ancak yayınlanmış diğer içerik (örneğin test edilen ancak henüz kullanıma alınmamış fonksiyonalite) zaten belirlenmeye çalışılmalıdır. Bununla ilgili denetim adımları (linkleri takip ederek web içeriğini belirleme, kaba kuvvet saldırısı, vs.) daha önceki aşamalarda belirtilmişti. Farklı kullanıcı kodlarına sahip değilsek izleyebileceğimiz denetim prosedürü aşağıdaki gibidir:
- Daha önce açıklandığı gibi içerik tespiti yapıldıktan sonra farklı fonksiyonalite sağlayan sayfalara gönderilen isteklere “admin=true” gibi parametreler URL içinde veya POST parametreleri arasında gönderilir.
- Uygulamanın Referer başlığına güvenerek bazı fonksiyonaliteye erişim hakkı verip vermediği kontrol edilir. Erişim hakkı olan sayfalara giden istekteki Referer başlığının içeriği boşaltılarak kontrolün bu başlığa dayanıp dayanmadığı belirlenir. Eğer bu durumda erişim hakkı vermiyorsa uygulama bu değere güvenerek güvenlik açığı doğuruyor olabilir.
- İstemci tarafına gönderilen HTML ve JavaScript gözden geçirilerek gizlenmiş fonksiyonalite olup olmadığı araştırılır.
Tüm erişilebilir fonksiyonalite belirlendikten sonra uygulama aynı tipteki kaynaklar içinde (dokümanlar siparişler, e-postalar, kişisel bilgiler gibi) kullanıcıları belli kaynaklara erişim konusunda kısıtlıyorsa bunlara erişim için gerekli kontrollerin uygulanıp uygulanmadığı aşağıdaki adımlarla denetlenebilir:
- Uygulamanın doküman numarası hesap numarası, sipariş numarası gibi belirteçlerle kaynakları isimlendirdiği durumlarda mevcut kullanıcıyla erişilemeyen kaynak ID’lerine ulaşılmaya çalışılır.
- Eğer ID’ler kısa zamanda üretilebilecek uzunluktaysa kaba kuvvet saldırısıyla başka kullanıcılara ait kaynakların isimlerinin tespit edilmesine ve bu kaynaklara ulaşılmaya çalışılabilir. Eğer kaba kuvvet saldırısı mümkün görünmüyorsa ID bilgileri tahmin edilmeye çalışılabilir.
- Eğer ID’ler tahmin edilebiliyor ve erişim kontrolleri yetersizse otomatik yöntemler kullanılarak mümkün olduğunca çok dokümana ulaşılabilir. Bu tür bir saldırının çok etkili olabileceği durumlardan biri kişisel bilgiler içeren doküman veya kaynaklara erişilmesi ve kısa zamanda çok sayıda kişisel bilgiye ulaşılmasıdır (özlük bilgisi, kredi kartı bilgisi, password, vs.). Bu tür bilgiler kullanıcı ekranında password formatında gösterilse bile gerçekte bu bilgi sunucudan istemciye iletiliyor olabilir.
Erişim kontrolünün uygulandığı her durumda erişilen URL’e doğrudan ulaşıldığında doğru kullanıcı için erişimin sağlanması denetlenmelidir. Kullanıcı tanılama saldırılarında belirtildiği gibi eğer bir veriye ulaşmak için çok aşamalı adımların geçilmesi gerekiyorsa doğrudan ara veya son adımlara ulaşmanın mümkün olup olmadığı denetlenmelidir.
<<Önceki Bölüm Sonraki Bölüm>>
BTRiskBLOG, BTRİSK Bilgi Güvenliği ve BT Yönetişim Hizmetleri şirketi personeli tarafından geliştirilen Pentest (Sızma Testi), ISO27001, BT Denetimi ve bilgi güvenliği hakkında herşeyi bulabileceğiniz blog'dur.
