IAST ile Zafiyet İnceleme

IAST ile zaafiyet inceleme işlemine geçmeden önce önceki yazılarımdan IAST nedir başlıklı yazımı inceleyerek bilgi alabilirsiniz.Kısaca IAST  web ve mobil uygulamalarda güvenlik açıklarını uygulama kodu çalışırken  tespit etmek için kullanılan bir güvenlik testi yöntemidir. Bu yazımda uygulamada tespit edilen bir zafiyetin başlangıcından sonuna kadar olan süreci inceleyeceğim.

Sunucu üzerinde kurulu olan tek bir ajan yaptığım taramaya bağlı olarak tüm istekleri yakalamak ve zararlı olanları tespit etmek için çoğalarak derinlemesine bir analiz sürecine başlıyor. Dashboard üzerinden yada oluşturduğunuz proje detaylarından anlık bağlı olan ajan sayısını görebiliyoruz.

Tarama yaptığımız proje detayları ekranında zafiyet skor,sayısı,iast tarafından doğrulanan zafiyetler,api endpointlerimiz ve bağlı bulunan ajan sayısına ait bilgilerin yanında tespit edilen zafiyetlerin kategorize edilmiş listeside yer alıyor. Projeye ait özet bilgilerin yanısıra uygulamamızın hangi otoriteye ne kadar uyumlu olduğuna dair bilgilerde bulunmaktadır.

Uyumluluk listesinin en başında bulunan Dvwa-Policy taradığım projeye özel yazdığım bir policy olduğu için en başta yer almaktadır. Bu kurallar kullandığınız IAST Tool özelliklerine göre değişmektedir.Ben makalede kullanacağım için uygulamamda 5 taneden fazla güvenlik açığı varsa uyumluluk listesinde başarısız olarak listele şeklinde bir kural yazdım.

Kullandığınız iast çözümünün daha güçlü olmasını istiyorsanız bir sast ve sca ile entegre çalıştırarak uçtan uça zafiyet analizide yapabilirsiniz.

Dashboard menüsünde yer alan başlıklardan kısaca bahsederek iast ile zafiyet inceleme sürecine devam edeceğim.

Application Security: Projeye ait detayların yer aldığı bölüm.

Compliance: Proje özelinde yazılmış uyumluluk kurallarının yer aldığı bölüm.

Component Risk: Entegre bir SCA  çözümü tarafından tespit edilen bağımlılık zafiyetlerinin yer aldığı bölüm.

Endpoint Risk: Uygulamada bulunan ve IAST tarafından tespit edilen API ve bu API`ler üzerinde tespit edilen zafiyetlerin listesi.

Code Risk: Entegre bir SAST çözümü tarafından tespit edilen zafiyetlerin yer aldığı bölüm.

Data Flow Map: Uygulama içindeki dahili ve harici servislerin (HTTP,Database vb.) gerçek zamanlı tespit edilmiş ve haritalanmış görselinin bulunduğu bölüm. Örnek ekran görüntüsü aşağıdaki gibidir.

Ve en çok vakit geçereceğimiz ekran;

Vulnerabilities: Projede tespit edilen tüm zafiyetlerin yer aldığı bölüm.

Sağ menüde yer alan diğer ekranlarda projeye ait hassas verileri,entegrasyonları,erişim yetkileri gibi ayarların yapıldığı bölümler olduğu için fazla detaya girmeden iast ile zafiyet inceleme işlemine devam ediyorum.

Zafiyet listesinden seçtiğim ve IAST tarafından da doğrulanmış Cross-site Scripting zafiyetinin detayları ile devam ediyorum.

Yukarıdaki ekran görüntüsünde zafiyetin ne zaman en son ne zaman görüldüğü,kaç kere tarandığı ve doğrulanıp doğrulanmadığı gibi detayların yanında zafiyetin hangi path üzerinde oluştuğu,hangi parametreyi döndürdüğü ve buna ait bilgiler yer alıyor.

Data Flow sekmesinde zafiyetin başlangıcından bitişine kadar yapılan işlemlerin adım adım listesi yer alıyor.

Aşağıdaki veri akış diyagramı, kullanıcı kontrollü girdinin uygulamada nasıl işlendiğini ve bir güvenlik açığına nasıl neden olduğunu göstermektedir.

Verification Proof ekranında iast ile zafiyet inceleme sonrası zafiyetin gerçekliğinin kanıtına ait veriler ve açıklamalar yer almaktadır.

HTTP Request bölümünde yer alan bilgiler doğrultusunda isteğin başlangıç aşaması ve istekten dönen cevabın detaylı analizini yaparak tetiklenen process id (PID) değerine ait detaylarıda inceleyebiliyoruz.

Previous Detections bölümünde bu zafiyetin daha önce kaç kere,hangi versiyonlarda ve hangi PID üzerinde tespit edildiğine dair kanıt listesi yer almaktadır.

Bu bölüme kadar zafiyetin nasıl,nereden hangi payload ile başladığına ve sonucuna kadar olan bilgileri aldıktan sonra geriye zafiyetin kapatılması kalıyor. Kullandığım bir çok üründe Remidation bölümünü yer almasına rağmen makaleyi yazarken kullandığım IAST çözümündeki öneriler kadar açıklayıcı ve kapsamlı olanına denk gelmedim 🙂 Aşağıdaki ekran görüntüsünde önerileri ve bu bu zafiyete ait bazı eğitim videoları bulunmaktadır.

Elbette tüm zafiyetler bu kadar kolay tespit edilip kapatılamıyor.Önemli olan iast ile zafiyet inceleme işlemlerinin nasıl ilerlediğini anlayabilmek.Tabiki tek bir zafiyet inceleyerek IAST`ın gücünü anlamak mümkün olmayacaktır.

Bir çok web uygulama güvenliği çözümünde olduğu gibi iast çözümlerinde de elbette false positive vakalarda karşımıza çıkıyor. Bu oranı düşürmek için kullanılan iast çözümünde mutlaka doğrulama yeteneği başarılı bir şekilde çalışıyor olmalıdır.

Gelelim en önemli konuya (zafiyet doğrulama)

Kullandığım çözüm tespit ettiği zafiyeti doğrulamak için bir kullanıcı gibi davranıp zafiyeti arka planda simule ediyor ve dönen sonucu değerlendirerek zafiyeti skorluyor,doğruluyor ve önerilerde bulunuyor.Testlerimde false positive oranını incelediğimde çok düşük oranlarda da olsa karşılaştığım zamanlar oluyor bu sorunu çözmek için aynı zafiyeti 2. yada 3. defa test ediyorum ben testlerimi yaparken iast ajanlarınında uygulamayı öğrenmesini ve sonucu doğrulamasını hızlandırmış oluyorum.

IAST bir  tespit ve analiz çözümü olduğu için RASP gibi prod ortamında değil staging ortamında çalıştırılmalıdır.

Son olarak web uygulama güvenliği çözümleri yazılım geliştirilen tüm ortamlarda kullanılmalıdır. Waf vb çözümlerle koruma sağlasakta zafiyetli kod her zaman zafiyetli kalacaktır.Önemli olan kodun zafiyetini kapatmaktır.

Faydalı olması dileği ile…