Eresus Guard'ı Neden Geliştirdik: Gürültüsüz DAST ve Yetki Testi

Açıklama: Eresus Security'nin kurucusuyum ve Eresus Guard'ı biz geliştiriyoruz. Bu yazı bir ürün tanıtımı; ama ürünü değil, çözmeye çalıştığı problemleri anlatıyor. Ürünün ne olduğunu ve ne olmadığını Eresus sayfasında ayrıca bulabilirsiniz.

Uygulama güvenliğinde en büyük sorun çoğu zaman araç eksikliği değil. Elimizde yeterince tarayıcı var. Sorun, onların ürettiği sonuçların bir ekibin gerçekten harekete geçebileceği şeylerle örtüşmemesi. Sızma testlerinde ve ekiplerle çalışırken üç sorunu tekrar tekrar gördük.

1. Araçlar parçalı, sonuçlar dağınık#

Dinamik test için bir araç, kaynak kod için başka, bağımlılıklar için bir üçüncüsü, sırlar için dördüncüsü. Her birinin kendi arayüzü, kendi veri modeli, kendi "kritik" tanımı var. Ekip, bulguları tek bir yerde görmek için entegrasyon yazıp bakımını yapıyor. Güvenlik işi, tablo birleştirme işine dönüşüyor.

Eresus Guard'da dinamik ve statik analizi tek platformda, tek veri modelinde topladık. Bir bulgunun hangi katmandan geldiğini görebilmek önemli; ama beş farklı ekranı gezmek zorunda kalmamak daha önemli.

2. Yanlış pozitif gürültüsü#

Bir tarayıcı iki yüz bulgu raporladığında ve bunların çoğu sömürülemiyorsa, geliştirici bir sonraki raporu açmaz. Gerçek açık, gürültünün içinde kaybolur. CI/CD hattına sokulan bir tarayıcı sahte alarmlarla build'i kırdığında ise çözüm genelde tarayıcıyı kapatmak olur.

Bu yüzden doğrulamaya yatırım yaptık: bulguyu kanıtlayan tekrarlanabilir HTTP istekleri ve yanıta bakarak anlaşılamayan açıklar için bant dışı doğrulama (OAST). Aşağıda neden gerektiğini anlatıyorum.

Ama şunu açıkça söyleyeyim: sıfır yanlış pozitif vaat etmiyoruz. Doğrulama gürültüyü azaltır, insan değerlendirmesini ortadan kaldırmaz. Bunu vaat eden bir güvenlik ürününe şüpheyle yaklaşın.

Kör açıklar ve OAST#

Kör bir komut enjeksiyonunda ya da SSRF'de uygulama yanıtında hiçbir iz görmezsiniz. İstek başarılı olur, sayfa normal döner. Tek kanıt, sunucunun sizin kontrol ettiğiniz bir adrese dışarıdan istek atmasıdır.

POST /api/import HTTP/1.1
Host: app.example.com
Content-Type: application/json
 
{"url": "https://abc123.oast.example/"}

Yanıt 200 OK ve gövde boş olabilir. Ama abc123.oast.example adresi, hedef sunucudan bir DNS sorgusu veya HTTP isteği alırsa, SSRF'yi yanıta bakmadan kanıtlamış olursunuz. Bu, "yanıt süresi uzadı, belki açıktır" tahmininden çok daha sağlam bir kanıt. (Yukarıdaki istek kavramı göstermek için yazılmış genel bir örnektir, ürün çıktısı değildir.)

3. Modern API'ler ve kimlik doğrulama#

Bugünün uygulamaları statik sayfalar değil. Tek sayfalık arayüzler, arkada onlarca API ve her istekte değişen yetki bağlamı var. IDOR ve BOLA (nesne düzeyinde yetkilendirme) açıklarını yakalamak için tek bir kullanıcı olarak taramak yetmez; aynı isteği iki farklı kullanıcının bağlamında karşılaştırmak gerekir:

Kullanıcı A (hesap 1001):  GET /api/orders/9001  -> 200, A'nın siparişi
Kullanıcı B (hesap 1002):  GET /api/orders/9001  -> 200, A'nın siparişi   <-- açık
Kullanıcı B (hesap 1002):  GET /api/orders/9001  -> 403                   <-- beklenen

Bir tarayıcı bu açığı ancak iki oturumu aynı anda tutup yanıtları kıyaslayabiliyorsa görebilir. Eresus Guard'ı üretim öncesi ortamlarda çok oturumlu, kimlik doğrulamalı test yapacak şekilde tasarladık.

Ne olduğumuz, ne olmadığımız#

Yapay zekâ ile her şeyin çözüldüğü iddiasından uzak durmaya çalışıyoruz. Eresus Guard, deterministik tarama kurallarına ve sınırları belli, doğrulanabilir otomasyona dayanan bir güvenlik mühendisliği ürünü.

Dürüst sınırlar:

• Bir WAF değil; trafiği engellemez, açıkları test eder.
• Ticari ve kapalı kaynak; çevrimdışı (air-gapped) lisans modu yok.
• İnsan değerlendirmesinin yerini almaz.
• Lisans yalnızca yazılım platformunu kapsar. Manuel sızma testi, red team ve danışmanlık, Eresus Security'nin ayrı sözleşmelerle verdiği hizmetlerdir.

Ürünün tamamı, kimler için olduğu ve olmadığı Eresus sayfasında. Ürün sitesi: guard.eresussec.com.