Pentestposter Sendromu

Merhabalar! Uzun bir aradan sonra, kendim için bir farklılığa giderek doğrudan teknik bilgiler içermeyen yeni bir yazı ile birlikte dönüş yapıyorum.

3 yılı aşkın süredir sahada aktif olarak sızma testleriyle (internal/external) uğraşan ve masanın hem danışmanlık hem de kurumsallık tarafını tecrübe etme şansı bulmuş birisi olarak zaman geçtikçe bizzat kendim deneyimlediğim ve zaman zaman OffSec alanında çalışan arkadaşlarda da gözlemlediğimi düşündüğüm bazı durumlardan bahsetmek, aynı döngüye girmiş veya ileride girebilecek olan herkese bir nebze yardımı dokunabilmesi veya en azından onları düşünmeye itebilmesi için böyle bir yazıyı ele almak istedim.

<> trust is your enemy!

Öncelikle, en azından “mentalite” olarak CTF playerlarının ve Bug Hunter’ların birbirlerine bir Pentester’dan daha yakın olduğuna eminim hemfikirizdir. Peki siz bir pentester olarak CTF platformlarında veya etkinliklerinde soruları çözerken kullandığınız taktik, teknik, komut veya soruyu çözebilmek adına yaptığınız detaylı araştırmaların ne kadarını real life sızma testlerinde uygulayabiliyorsunuz?

Pentester olarak çalışıyorsanız yüksek ihtimal ile sizlerde birçoğunu uygulamıyor/yapmıyor olabilirsiniz. Çünkü işin bilincinde dahi olmadan bir süre sonra (yüzlerce sızma testi projesi gerçekleşirdikten veya yüzlerce uygulamayı analiz ederek inceledikten sonra) yazılım geliştiricilere, testini gerçekleştirdiğiniz firmalara (özellikle ismi bilinen, büyük firmalara) güven duymaya başlayarak; “ya bu kadarı da olmaz” diye bir düşünceye kapılıp gidebiliyoruz.

Örneğin, çok sayıda ve birbirinden farklı e-ticaret, bankacılık vb. uygulamalarına yönelik sızma testleri yaparak zaman geçirdikçe, aynı sektörde faaliyet gösteren farklı bir kurum için gerçekleştirilen sızma testi sırasında Pentester için otomatik olarak güven duygusu devreye girebiliyor ve bu durum bakış açımızı sınırlandırabiliyor. Bu nedenle oluşan bu güven (veya siz ne demek isterseniz) duygusunun Pentester ve Bug Hunter olarak çalışan kişiler arasındaki temel farklılıkları oluşturan bir çizgi olduğunu düşünüyorum.

Tabii ki sızma testlerinde zafiyetlerin tamamının tespit edilememesi doğal olabilir. Sonuçta Sızma Testleri; firmalar için testlerin gerçekleştirildiği zaman aralığındaki “anlık” resmin ortaya çıkmasını sağlarken, Ödül Avcılığı ise sürekliliği olduğu için testlerin daima devam ettiği ve en önemlisi farklı insanların yani farklı bakış açılarının testlere dahil olmasını sağlayan bir iş modeli oluyor. Neyse burada sızma testi ve ödül avcılığının farklarından bahsetmeme gerek yoktur herhalde. Anlatmaya çalıştığım konu için birkaç örnek senaryo verebilirsem daha sağlıklı olacak sanırım.

X bankasının sızma testleri yapılırken:
-> Koskoca X bankası, EFT işleminde IDOR olması mümkün değildir herhalde. Burada ve diğer fonksiyonlarda daha complex zafiyetler tespit etmeye odaklansam iyi olacak.

Y adlı e-Ticaret firmasının sızma testleri yapılırken:
-> Sepete ürün eklerken tutarı negatif değer olarak gönderip ürünü bedavaya alamam herhalde, bir iki şekilde denedim zaten izin vermiyor. Hem bu uygulamayı bu zamana kadar çok kişi test etmiştir zaten.

Dikkat çekmek istediğim konuyu doğru şekilde kafanızda canlandırabilmişimdir umarım, neyse devam edelim.

CTF çözerken zaten bir zafiyet olduğunun bilinciyle sunuculara/uygulamalara yaklaşıyoruz ve bu sebeple uygulama üzerindeki her bir fonksiyonun veya sunucu üzerinde çalışan bütün servislerin en derinine/dibine kadar inerek inceliyor, zafiyeti tespit edip sömürene kadar araştırmaya ve kazmaya devam ediyoruz. Peki ya sızma testlerinde? Pentester olarak bir süre geçirildikten sonra pentesterların da kendine has bir Imposter Sendromu‘na yakalandığını düşünüyorum. Bu sendromu da siber güvenlik sektörüne özel, yeni bir terim ile dile getirelim diyorum, mesela; Pentestposter Sendromu. Tamam bu sefer isim pek yaratıcı olmadı ama en azından yazı içerisinde işimizi görür, bizi idare eder sanırım. Imposter sendromunun ise aslında ne olduğunu öğrenmek isterseniz aşağıdaki videoya kısaca göz atabilirsiniz.

What is imposter syndrome and how can you combat it? – Elizabeth Cox

Zihninizde bu tarz negatif düşünceler dolanmaya başladığında derhal Pentestposter Sendromu’ndan çıkın. Sızma testlerinde “yok ya bu kadar basit bir kontrolü yapmamış olamazlar” veya “sunucunun backup dosyalarını gidip web dizininde yayınlamamışlardır” gibi düşüncelere kapılmayın çünkü o kontrol eklenmiyor. Ofansif siber güvenliğe ilk adımınızı atmaya başladığınız zamanlardaki (kimine göre paranoyak denilebilecek) düşüncelerinizin sizden kopmasına izin vermemeye çalışın. Yapılan işlerde/projelerde insanları birbirinden ayıran temel özelliklerden birisi de farklı düşünce yapısı oluyor. Sonuçta paranoyak düşünceler ile standart işleyişin dışında işlemler yapılmasaydı uygulamalarda, ürünlerde ve hatta protokollerin kendisinde bile zafiyetler tespit edilebilir miydi? Ne demişler, Always think outside the box.

<> what can we do?

Tabii ki birçok konuda olduğu gibi burada da işin başı aslında mental sağlık fakat bu yazıda ben bu konulara değinmeyeceğim. O yüzden:

Checklist, checklist and little bit cheatsheet!

Kendinize sürekli kullanabileceğiniz bir checklist hazırlayarak; enumeration, fuzzing, passive/active taramalar ve manual kontrollerinizde bu adımları es geçmemeyi deneyebilirsiniz.

Ama bu aşamada da dikkat edilmesi gereken önemli bir konu var: “TEKDÜZELEŞMEK“

Kendinize sağlam, içeriği eksiksiz bir checklist hazırladığınızı düşünüyorsunuz diyelim. Hazırladığınız bu checklisti kendinize baseline olarak belirlediniz ve testlerinizi bu çizgiden şaşmadan yapıyorsunuz. Evet, bu işi bir baseline olmadan yapmak kesinlike faydalı değil fakat kendinize hazırladığınız bu çizginin dezavantajı da sizi “tekdüzeleştirebilecek” olması. Sonuçta sadece checklist üzerinden gidilerek yapılan standart kontroller sızma testleri için yeterli olmayacaktır. Uygulamanın çalışma yapısını ve iş akışını anlayarak, testi bu bilgilere göre gerçekleştirmeli kısacası sistemin kendisini özel hissetmesini sağlamalıyız. (:

Tekdüzeleşmenin de önüne geçebilmek adına; örneğin katıldığınız yeni bir CTF etkinliğinde veya disclosure olmuş bir bounty raporu okuduğunuzda öğrendiğiniz farklı bir metodoloji (hatta x toolu için değişik bir parametre kullanıldığını görmenizi bile listeye dahil edebilirsiniz) olması halinde bu bilgileri doğrudan checklist veya cheatsheetinize bir madde olarak ekleyin ve kontrol listenizi güncel tutmaya çalışın. Tabii ki en önemli kısım aslında yukarıda bahsettiğim şekilde uygulamanın/sistemin çalışma mantığını anlayarak bunun üzerine testlere yoğunlaşmak.

<> let’s do some enumeration

Danışman olarak çalışıyorsunuz diyelim, evet belki projede kapsamınız devasa ve size verilen adam/gün süreniz uygulamalarda sadece butonlara birer kez tıklasanız bitiyor. Bu tarz durumlarda hazırladığınız checklist ve cheatsheetler ile işlem basamaklarını birer süreç haline getirerek; fuzzing, enumeration ve dinamik taramalarınızı sağlıklı şekilde gerçekleştirmek projenizdeki temellerin sağlam atılmasını sağlayacaktır.

Testlerin ilerleyen aşamasında ise burada yaptığınız çalışmaların çıktılarını özümseyerek inceledikten sonra önemli olabileceğini gördüğünüz bilgileri bir kenara not alabilir, ve projeniz hakkında genel bir bakış açısına sahip şekilde testlerinize devam edebilirsiniz. Çalışmalarınızın sonucunda kullanılan web teknolojilerini, dizin ve endpointleri, subdomainleri veya dinamik taramalarda tespit edilen zafiyetleri görmek uygulama hakkında genel bir bakış açısı edinmenizi sağlayacaktır.

Bu konu bizim için önemli çünkü bürünülen ruh hali sebebiyle test sırasında bakış açıları sınırlanabiliyor. Bakış açılarının sınırlanması da basit zafiyet kontrollerinin es geçilerek daha complex zafiyetlerin aranmasına sebep olabiliyor. Enumeration adımlarının bir sisteme dayalı veya standardize edilerek gerçekleştirilmesi üzerinizde oluşan büyük kapsam stresini ve pentestposter sendromunu azaltarak uygulamalarda ki basit zafiyetlerin var olmadığına yönelik düşüncelerin de kaybolmasına yardımcı olacaktır.

Eğer test ettiğiniz uygulama kapsamlı ve sıkı bir SSDLC (Secure Software Development Lifecycle) döngüsünden geçmese dahi SSDLC ile birlikte aşağıdaki aşamaların birçoğu open-source çözümler ile gerçekleştirilebilmektedir.

• Patch management,
• Source code analysis,
• 3rd party library ve plugin (SBOM) versiyon kontrolleri.

Bu sebeple testler sırasında open-source veya ürünler ile yapılan dinamik taramaların sonucunda direkt olarak zafiyet tespit edilme olasılığı gün geçtikçe azalmaktadır çünkü DAST araçları ile tespit edilebilen zafiyetlerin çoğunluğu SSDLC aşamalarında tespit edilerek öncesinde aksiyonlar alınabilmektedir.

DevSecOps süreçlerinden geçen uygulamalarda testler gerçekleştirilirken fuzzing hala en önemli aşamalardan birisidir. Çünkü SSDLC süreçlerine dahil edilmiş fuzzing adımında yapılan kontrollerin çıktıları diğer SSDLC aşamalarının çıktılarına göre daha belirsiz olabilmektedir. Bunun sebebi: SSDLC süreçlerinde Fuzzing, DAST gibi aşamaların genellikle uygulamaların test ortamları (UAT, preprod vs.) üzerinde gerçekleştirilmesidir.

Burada oluşabilecek eksikliği anlamlandırabilmek adına örnek bir senaryo kurgulayalım.
-> SSDLC süreçlerinden başarıyla geçmiş bir uygulama olsun. SSDLC süreçlerinde zafiyet yaratabilecek bir durum tespit edilmemişti fakat ilgili uygulama canlı ortama deploy edilirken sistem ekipleri tarafından web dizinine yanlışlıkla backup vb. gibi hassas olabilecek dosyalar eklenirse veya normalde internet üzerinden erişim sağlanamaması gereken endpointler olursa bunlar nasıl tespit edilebilir?

Evet, fuzzing ve enumeration adımları ile. Örneğini vermeye çalıştığım gibi oluşabilecek çeşitli senaryoların tespitleri için doğrudan manual ve dinamik testlere yoğunlaşırken enumeration ve fuzzing adımlarını atlamamaya dikkat edebilirsiniz. Dinamik tarama araçları bırakın size sadece uygulama hakkında bazı bilgileri sağlasın, sizse elde ettiğiniz bu bilgileri harmanlayarak kullanın.

Keşif ve inceleme adımları tamam, artık manual kontrollere geçebiliriz. Manual kontrollere geçmeden önce ilk olarak en önemli noktayı netleştirmemiz gerekiyor; uygulama nasıl çalışıyor, iş akışı nasıl ilerliyor?

<> understanding how to work this damn application?

Uygulamalar üzerinde kritik seviyeli zafiyetler genellikle iş akış süreçlerindeki eksiklikler kaynaklı ortaya çıkmaktadır. Bu sebeple test edilecek uygulamanın öncelikle nasıl çalıştığını ve iş akışının nasıl ilerlediğini kavramak önemli olmaktadır. Bu bilgiler öğrenildikten sonra gerçekleştirilen manuel incelemeler ile birlikte injection veya business logic zafiyetleri görece daha kolaylıkla tespit edilebilir duruma gelecektir.

Geliştirilen yeni nesil uygulamaların en önemli özelliklerinden birisi çok katmanlı yapılar halinde çalışıyor olmasıdır. Bu özellik günlük yaşantımızda kullandığımız uygulamaları oldukça kullanışlı hale getirdiği gibi gerekli kontroller sağlanmadığı taktirde oluşabilecek business logic zafiyetlerinin de önünü açmaktadır.

Yine örnek bir senaryoda:
-> Step 1: Uygulamada oturum açtınız, ürünleri sepete attınız, sepetiniz için 100 liralık bir ücret oluştu ve ödeme aşamasına geçtiniz. Bu işlemleri yapılabilmenizin sağlanması için sunucu tarafında a1b2c3d4 değerine sahip bir token oluştu ve aslında uygulama sunucusu bu token değeri üzerinden sepet ücretini kontrol ediyor diyelim.

-> Step 2: Sonraki aşamada 2000 liralık farklı bir sepet oluşturup ödeme aşamasına giderken HTTP isteği içerisindeki token değerini ilk oluşturduğumuz sepetteki a1b2c3d4 değeri olarak değiştirerek gönderirsek 2000 liralık sepeti 100 lira gibi bir tutar ödeyerek satın alabilir miyiz?

Evet, uygulamanın iş akışı (business logic) kurgusu bu şekilde yapıldıysa ve back-end üzerinde gerekli validasyonlar sağlanmadıysa alabiliriz. Bu tür senaryolar göz önüne alındığında testleri gerçekleştirilen uygulamalarda çok katmanlı yapıları anlamak, süreç ve akışların nasıl olduğuna dair bir özeti beynimizde şekillendirerek testleri bu bakış açısıyla gerçekleştirmek oldukça değerli olmaktadır.

Peki uygulamayı nasıl inceleyebiliriz? Neler yaparak uygulamanın çalışma yapısını ve arka planda işleyen business akışına daha çok hakim olabiliriz?

for white-box

White-box test gerçekleştiriyorsanız uygulamanın use-case dokümanlarını, API dokümanlarını ve uygulamanın mimari yapısını anlatan dokümanları inceleyerek başlanması çok yararlı olacaktır. Bu dokümanlar uygulamanın nasıl çalıştığı, kaç farklı endpoint/fonksiyon içerdiği, uygulamada kaç farklı rol olduğu ve authentication/authorization adımlarının nasıl gerçekleştiği hakkında önemli bilgileri doğrudan görmenizi sağlayacaktır.

Testlerinize manual olarak başlamadan önce elde ettiğiniz bilgiler üzerinden tehdit modellemeleri yaparak zafiyet olabileceğini düşündüğünüz noktaları inceleyebilirsiniz. Ek olarak uygulama üzerinde kritik öneme sahip olan bazı fonksiyonları (Ödeme adımı, dosya yükleme, XML ile veri iletimi vb.) yine işbu dokümanları inceleyerek görebilir ve ilgili fonksiyonlar için detaylı test ve kontroller yapılması gerektiğine yönelik notlarınızı alabilirsiniz.

Bu dokümanlara ek olarak uygulamanın Quality assurance (QA) testleri için hazırlanmış olan bir taslak var ise bunu da talep edebilir, uygulama üzerinden tetiklenebilecek bütün fonksiyonları ve çeşitli alanlara girilmesi gereken data setlerini inceleyebilirsiniz.

Uygulama üzerinde bulunan kullanıcı rollerinin hangi işlemleri yapıp yapamayacağını, fonksiyonların nereden tetiklendiğini ve uygulamanın nasıl çalıştığını anladıktan sonra manuel testlere başlanabilir.

for black-box

Black-box olarak gerçekleştirilen testlerde uygulamanın çalışma yapısını anlayabilmek için öncelikle uygulamada zaman geçirmeliyiz. İlk olarak uygulama üzerinde normal bir kullanıcı gibi gezinerek farklı senaryolarda uygulamanın nasıl davrandığını inceleyebiliriz.

Uygulama üzerinde minimum 2 adet kullanıcı oluşturup, kullanıcı oluşturma adımlarında yine birbirinden farklı testleri deneyebilirsiniz. Oluşturduğumuz bu kullanıcıları sonrasında IDOR, CSRF gibi çeşitli zafiyetleri test ederken kullanabiliriz. Uygulamaya giriş yaparak farklı ekranlar ve sekmeler arasında gezinip, gördüğümüz bütün butonlara tıklayarak uygulamanın normal işleyişini anlayabiliriz. Bu aşamalara ek olarak uygulama üzerinde bir satın alma, para gönderimi gibi uygulamanın temel işlevi ne ise gerçekleştirmeliyiz.

Yaptığımız işlemlerin sonunda ilgili fonksiyonlar tetiklendikten sonra ne tür HTTP istekleri yapıldığı, HTTP istekleri içerisinde hangi parametreler olduğu ve bu HTTP isteklerine sunucu arafından ne tür response’lar döndüğünü detaylı şekilde inceleyebiliriz. Yine uygulamanın HTML, JavaScript ve CSS dosyalarını, back-end sunucusuyla nasıl etkileşime geçtiğini inceleyerek uygulamanın iş mantığını anlamak daha kolay olacaktır.

Örneğin eğer bir mobil uygulamaya yönelik sızma testleri yapıyorsak, APK veya IPA dosyalarının içeriklerini inceleyerek uygulamanın işleyişine dair çeşitli bilgileri edinebiliriz.

Test ettiğimiz uygulama, farklı web servisleri veya API’lerle etkileşime geçiyorsa, bu API’ler üzerinde de çeşitli fuzzing işemleri gerçekleştirerek farklı endpointlerin keşfedilmesi, keşfedilen endpointlerden nasıl yanıtlar döndüğünü ve verilerin nasıl işlendiğini inceleyerek sistemin genel çalışma yapısı hakkında bilgileri öğrenebiliriz.

Elde edilen bütün bilgiler ile birlikte uygulama üzerinde testlere başlanabilir.

<> business logic test mentality

Business Logic odaklı testler yapmak istediğinizde sizlerde Rapid7 tarafından yayınlanan aşağıdaki dokümanı baz alarak çeşitli test ve kontrolleri gerçekleştirebilirsiniz. Doküman içerisinde detayları yer alan 10 konu başlığı üzerine kontrollerin gerçekleştirilmesinden sonra uygulamadaki business logic testlerinin bir kısmını tamamlamış olacaksınızdır.

Daha öncelerinde gerçekleştirdiğim çeşitli business logic odaklı testler sırasında aldığım bazı notlarımı örnek saldırı senaryoları ile birlikte olmak üzere ‘+’ olarak yazıya dahil ederek paylaşmak istedim.

Rapid7 – AV1: Yetkilendirme ve Kimlik Doğrulama Kontrolleri
Uygulamaların kendi erişim kontrol mekanizmaları ve erişim ayrıcalıkları bulunmaktadır. Örneğin normal bir kullanıcı oturum açtığı uygulamada sadece sayfaları görüntüleyebilir veya yorum yapabiliyorken uygulamadaki admin kullanıcısı görüntülenen sayfaları silebilme ve yapılan yorumları kaldırabilme yetkilerine sahiptir. Saldırganlar, yapacağı çeşitli işlemler ile normal kullanıcı hesabına fazladan yetkiler tanımlayabilir bu sayede normalde uygulama üzerinde yetkisi olmayan işlemler yapabilir, yetkisiz olarak verilere erişir duruma gelebilir.

✓ X kullanıcısına normalde kendisinin sahip olmadığı bir yetki tanımı gerçekleştirebilir mi?
✓ X kullanıcısı uygulama üzerinde normalde yetkisi olmayan işlemler gerçekleştirerek farklı ekranları görüntüleyebilir mi?

Rapid7 – AV2: Yetkisiz Şekilde Hassas Bilgilere veya Yönetici Kullanıcı Rollerine Erişim Sağlanması
HTTP GET ve POST istekleri içerisinde sıklıkla “id” veya “value” gibi parametrelerle karşılaşılmaktadır. Bu parametrelerin yer aldığı isteklerde gönderilen değerler kolay tahmin edilebiliyorsa ve farklı bir kontrol mekanizması & parametresi kullanılmıyorsa; bu durumdan yola çıkılarak başka kullanıcıların verileri görüntülenebilir veya farklı işlemler gerçekleştirilebilir. (IDOR, BOLA vs.)
✓ HTTP istekleri içerisinde giden parametrelerin değerleri değiştirilerek başka kullanıcılara ait işlemler gerçekleştirilebilir mi?
✓ Parametreler üzerinde yapılan manipülasyonlar sonucunda diğer kullanıcılara ait çeşitli verilere erişim sağlanabilir mi?

Rapid7 – AV3: Çerez (Cookie) Manipülasyonları
Oturum çerezleri; kullanıcının uygulama üzerinde dolanırken yaptığı işlem ve bilgileri barındırmaktadır. Cookie’ler kimlik doğrulama (authentication) işleminden sonra kullanıcıya tanımlanır. Eğer bu çerezlerin değerleri tahmin edilebiliyor veya decode edilebiliyorsa olası bir mantıksal güvenlik açığı ortaya çıkmaktadır. Cookie değerleri tahmin edilerek veya farklı yöntemlerle değerleri elde edilip kullanılarak uygulamada bir kullanıcıya farklı yetki veya erişim izinleri tanımlanabilir.
✓ Cookie değiştirilerek uygulama üzerinde farklı bir kullanıcının hesabına geçiş sağlanabilir mi?
✓ Cookie değerleri manipüle edilerek uygulama üzerinde yetki yükseltilebilir mi?

Rapid7 – AV4: LDAP Injection
LDAP protokolü kullanılarak kimlik ve yetki doğrulama işlemleri otomatik olarak gerçekleştirilebildiğinden LDAP parametrelerinde çeşitli manipülasyonlar ile saldırılar gerçekleştirilebilmektedir.
✓ LDAP ile çalışan uygulamalarda ilgili parametrelere "*" veya buna benzer LDAP filtre karakterleri eklenerek uygulama üzerinden farklı LDAP bilgileri ele geçirilebilir mi, LDAP queryleri enjekte edilebilir mi?

Rapid7 – AV5: Business Flow Kısıtlamalarından Yararlanma
İş akışına göre yapılan kısıtlamalar uygulamalar için oldukça önemli olmaktadır. Uygulama üzerinde ilgili kontrol değişkenleri gizlenmeden/şifrelenmeden HTTP isteği üzerinde görüntülenebiliyor ve back-end tarafında gerekli validasyonlar yapılmıyorsa proxy üzerinden kolaylıkla istekler manipüle edilebilir ve çeşitli business logic zafiyetleri tetiklenebilir.
✓ Front-end'de eklenmiş girdi kontrolleri var ise Proxy ile araya girilerek bu engellemeler bypass edilebiliyor mu? (max length, min lenght, file size vs.)
✓ Back-end'de eklenmiş girdi kontrolleri var ise çeşitli manipülasyonlar ile bu engellemeler bypass edilebiliyor mu? (max length, min lenght, file size vs.)

Rapid7 – AV6: Business Flowların Atlatılabilmesi
Uygulamaların kendilerine has çeşitli iş akışları bulunmaktadır. Uygulamalarda bazı iş akışı adımlarının atlanarak bir sonraki adıma geçilmesi gibi işlemler uygulama tarafında çeşitli hata ve zafiyetlerin tespit edilmesine yol açabilmektedir. Aynı işlemler uygulama üzerinde yetkisiz erişime veya bilgi sızıntısına da yol açabilmektedir.
✓ HTTP isteği içerisinde bulunan parametrelerde çeşitli değişiklikler yapılarak iş akışına aykırı işlemler gerçekleştirilebilir mi?

Rapid7 – AV7: Client Tarafında Yapılabilecek Kontroller
Uygulamalarda Javascript veya farklı teknolojiler ile istemci tarafında yapılan validasyonlar kolaylıkla atlatılabilmektedir. Ek olarak bu uygulamalarda ilgili js komutları farklı metodlar ile birlikte debug edilerek elde edilebilmesi halinde uygulamada iş mantığı akışlarının ve kontrollerinin nasıl olduğuna dair çeşitli bilgiler doğrudan elde edilebilir.
✓ Uygulama üzerinde DOM'lar var mı? DOM'lar üzerinden çeşitli zafiyetler tespit edilebiliyor mu?
✓ Tarayıcı üzerinde depolanan verilerde anormal bir durum var mı? Session ve diğer yapılar güvenli şekilde mi tutuluyor?

Rapid7 – AV8: Kullanıcı Identity Yapılarının Kontrol Edilmesi
Uygulamalar üzerinde ‘UserID’ gibi kimlikleri belirten parametreler Cookie veya ek olarak farklı token değerleriyle birlikte korunmaya çalışılmaktadır. Yetersiz tasarlanan ve geliştirilen uygulamalarda bu tür kimlik parametreleri istemci tarafından değiştirilebilir ve sunucu tarafında oturum çerezi(session cookie) veya farklı kontrol mekanizmaları ile kontrol edilmediği durumlarda farklı kullanıcıların hesabına yetkisiz olarak erişim elde etmek mümkün hale gelebilir.
✓ Örnek senaryoda; banka numarası veya bir userID değerinin basit bir algoritma ile encode/hash işlemi yapıldığı gözlemlenirse farklı bir kullanıcıya ait olabilecek değerler de aynı algoritma ile hashlenip kullanılarak farklı bir kullanıcının hesabının ele geçirilmesi senaryosu uygulanabilir mi?

Rapid7 – AV9: Yetkisiz Dosya ve URL Erişimi Kontrolleri
Uygulamalarda dışarı aktar (export) fonksiyonu ile birlikte oluşan dosyaların içerisinde uygulamaya, kuruma ait çeşitli hassas veriler bulunabilmektedir. Bir kullanıcı, verilerini seçeceği dosya formatında dışarı çıkartabilir(export) ve bu dosyayı indirebilir. Bu fonksiyon üzerinde doğru ve güvenli kontrol adımları gerçekleştirilmiyor ise hassas veriler saldırgan kişiler tarafından ele geçirilebilir. Saldırgan dosyanın indirileceği URL’i tahmin edebilir ve aslında başkası için oluşturulan dosya indirme bağlantısını kullanarak önceden oluşturulmuş dosyayı elde edebilir.
✓ Uygulama üzerinde çalışan URL'lere yetkisiz bir kullanıcı ile veya authentication olmadan erişim sağlanabiliyor mu?
✓ Uygulama üzerinden dosya indirilirken, X adına veya ID değerine sahip dosyayı indirmek yerine normalde erişilmemesi gereken Y adına veya ID değerine sahip rapor indirilebilir mi?
✓ Dosyanın indirilmesini sağlayan URL üzerinde dizin listeleme gibi çeşitli zafiyetler kontrol edilerek diğer dosyalara erişim sağlanabilir mi?
✓ Dosyanın indirilmesini sağlayan URL'de bulunan parametrelerde fuzzing yapılarak farklı dosyalara erişim sağlanabilir mi?
✓ Dosyanın indirilmesini sağlayan URL'e anonim olarak erişim sağlanabilir mi veya dosya indirilebilir mi?

Rapid7 – AV10: Business Logic üzerinden Hizmet Reddi (DoS) Saldırıları
Uygulama üzerinde kurgulanan yapılar doğru şekilde çalışmıyorsa saldırganlar tarafından bu durum kötüye kullanılarak hizmet reddine sebep olabilecek çeşitli saldırılar gerçekleştirilebilir. Örnek senaryoda bir uygulamada çalışan fonksiyon çeşitli parametreler ile birlikte sonsuz döngüye sokulabilir ve en sonunda sunucunun kaynakları tükendiğinde uygulama erişilemez/kullanılamaz duruma gelebilir.
✓ Uygulama üzerinde bilet veya koltuk satışı yapılıyorsa uçuşa veya sinema salonuna ait bütün koltuklar saldırgan tarafından tutulabilir mi?
✓ Uygulama üzerinde kullanıcı adı varlığı tespit edilebiliyor ve kullanıcılara yönelik kaba-kuvvet saldırıları sonucunda hesaplar bloke duruma geçiyor ise uygulamaya kayıtlı bütün kullanıcılar devre dışı bırakılabilir mi?
✓ Uygulama üzerinde tetiklenen fonksiyonlar ile SMS Bombing veya Mail Bombing gerçekleştirilebilir mi?
✓ Dosya yükleme alanlarında maximum size kontrolleri var mı? Maximum size kontrolleri yok ise yüksek boyutlu bir dosya upload edilerek web sunucusu crash ettirilebilir mi?
✓ CAPTCHA gibi kontrolsüz form göndermeyi engelleyecek önlemler alınan fonksiyonlarda CAPTCHA atlatılabiliyor mu? CAPTCHA atlatılarak gönderilecek istekler sonucunda uygulama veya sunucu DoS'a uğrayabilir mi?

Artık yazıyı noktalayabiliriz. Umarım oradaki birilerine yararı dokunur.

Referanslar

[01]: Rapid7 – Top 10 Business Logic Attack Vectors

0x046