Bir Zafiyet Raporu, bir avcının kendi keşfettiği zafiyetle ilgili belgedir ve bu nedenle bir zafiyet raporunun içeriği, raporun değerine önemli bir katkıda bulunabilir. Bu makalede, zafiyet raporunun farklı bölümlerine ve zafiyet raporu yazarken dikkate almanız, yapılması ve yapılmaması gerekenler hakkında bilgiler vermekteyiz. Eğer siz de bir avcı olmak istiyorsanız veya daha iyi rapor yazmak istiyorsanız, bu makalede zafiyet raporu yazma sürecinde karşılaşabileceğiniz tüm olası zorlukları ele almaya çalıştık. Ayrıca raporunuzun itibarını artırmak için dikkate almanız gereken önemli ve gerekli tüm noktaları sizinle paylaşıyoruz.

Çok önemli ve dikkate değer bir nokta, zafiyet keşfetmeye başlamadan önce her Bug Bounty programının politikasını okumaktır. Bug Bounty programının politikasında, Bug Bounty platformu ile işletme arasında belirlenen, katılım şartları ve programda kullanılabilir araçlar gibi konular belirtilmiştir ve diğer kısıtlamalar ve gereklilikleri içerir ki bunları en iyi şekilde takip etmek, avcının rapor inceleme sürecine yardımcı olabilir.

Rapor yazarken dikkate almanız gereken maddeler şunlardır:

• Zafiyetle ilgili tam açıklama
• Zafiyetin tekrarlanabilmesi için gerekli adımlar
• Zafiyetin risk seviyesi
• Saldırı ve kötüye kullanım senaryosu
• Zafiyetin kanıtı ve nasıl sömürüldüğü
• Zafiyet keşfi ve kullanımındaki araçlar, payload'lar ve kodlar
• İsteğe bağlı ve tamamlayıcı bölümler

Herşeyden önce ne yapılmalı?

Her şeyden önce, belirtildiği gibi, her Bug Bounty programının kurallarını, işletmenin güvenlik değerlendirmesi için belirlenen bölümleri öğrenmek önemlidir. Eğer belirli bir programın kapsamından çıkarak bir zafiyet keşfedilirse, maalesef rapor işleme konmayabilir. Bu nedenle, ilk olarak Bug Bounty programının politikasını okuyun, ardından belirtilen bölümlerde zafiyet keşfi yapın ve aşağıda açıklanan prensiplere göre zafiyet raporunuzu yazın ve raporunuzun onayını bekleyin. Unutulmamalıdır ki bir zafiyet keşfettiğinizde, değerlendirme ekibinin rapor içeriğinizden beklediği, keşfedilen zafiyeti tanımlamanız ve bu zafiyetin sisteme ne tür etkileri olabileceğini ve bu etkilerin sistem üzerindeki potansiyel zararını belgelemenizdir. Bir zafiyet raporu, bazen değerlendirme ekibinden onay alabilir, ancak iyi bir zafiyet raporu, kabul olasılığını artırabilir ve işletme güvenlik ekibinin yanıt verme süresini azaltabilir. Höşgörülü ve özlü ifade, zafiyet raporunuzun değerini artırır.

Bazı durumlarda, öyle bir avcı güvenlik açığı gözlemler ve keşfeder ki bu, sistemdeki normal davranışların bir parçasıdır. Temelde bu güvenlik açığı, bu Bug Bounty programı için geçerli bir güvenlik açığı olarak kabul edilemez, ancak aynı güvenlik açığı başka bir Bug Bounty programında yüksek puan alabilir. Başka bir deyişle, bu kullanım durumları, kontrol altında ve kontrolsüz bir şekilde gerçekleşir ve herhangi bir kötüye kullanım veya sistemde bir soruna neden olmaz. Hatta belirli bir Bug Bounty programının belirlenen kapsamında olmayan bir güvenlik açığı bulabilirsiniz, ancak bu güvenlik açığı ile programın onaylanan bölgeleri arasında bir bağlantı olabilir.

Güvenlik Açığı Raporunu Yazmadan Önce

Güvenlik açığı raporunuzun ilk bakışta dikkat çeken önemli bir bileşeni, raporun başlığıdır. Uygun ve kesin bir başlık, iyi ve prensiplere uygun bir güvenlik açığı raporunun işareti olabilir. Bir güvenlik açığı raporu için başlık seçerken dikkate almanız gereken bazı faktörler vardır. Genel olarak raporladığınız güvenlik açıkları iki durumda olabilir:

1. Doğrudan Bug Bounty programının kurallarının kapsamına giren zafiyetler.

2. Dolaylı olarak Bug Bounty programının kurallarının kapsamına giren zafiyetler.

Doğrudan veya dolaylı olarak Bug Bounty programının kapsamına giren zafiyetler için başlık seçerken, aşağıdaki iki formül iyi bir rehber olabilir:

Eğer keşfedilen zafiyet doğrudan Bug Bounty programının kapsamında ise, başlık, zafiyetin adı veya türü, etkilenen fonksiyonun ve zafiyetin önem derecesi sırasıyla birleştirilmiş bir kombinasyon olmalıdır:

Zafiyet adı veya türü + Fonksiyon veya zafiyetin noktası + Zafiyetin önemi veya derecesi

Örnek: "İletişim Bölümünde XSS Açığı Kritik Seviyede"

Eğer keşfedilen güvenlik açığı dolaylı olarak Bug Bounty programının kuralları içindeyse, başlıkta, kurallar dışında keşfedilen zafiyet ve Bug Bounty programının kapsamındaki zafiyetin adı, birbirine bağlanarak başlığın başına yerleştirilmelidir.

Güvenlik Açığı Raporu Yazma

1. Açıklamanın Detaylı Olması

Açık keşfini içeren raporunuzu, keşfedilen zafiyet hakkında detaylı açıklamalarla başlatmak önemlidir. Ayrıca, OWASP gibi güvenilir kaynaklardan zafiyet raporunuza bağlantı eklemek faydalı olacaktır. Örneğin, keşfettiğiniz açık bir SQL Injection türünde ise, zafiyet raporunuzda ilgili zafiyet hakkında güvenilir bir makaleye referans verebilirsiniz.

Çoğu zaman, zafiyetler bir kuruluşun veya şirketin iş alanıyla ilgilidir. Bu tür açıklıklarla karşılaştığınızda, önce sistem veya zafiyete maruz kalan bölümün normal işleyişini açıklayın. Ardından, bu zafiyet nedeniyle sistemin veya diğer kullanıcıların risk altında olduğu tehlikeleri belirtin.

2. Açığın Detaylı Olarak Yeniden Oluşturulma Adımları

Bulunan açığın, değerlendirme ekibi tarafından tam anlaşılır olması gerekir, böylece açığı yeniden oluşturabilirler. Bu nedenle, keşfedilen açığın detaylı bir şekilde yeniden oluşturulma süreci adım adım açıklanmalıdır.

Örneğin:

1. Giriş sayfasına gidin.

2. Şifre sıfırlama bağlantısına tıklayın.

3. Şifre sıfırlama e-postası almak için hedef kullanıcının e-posta adresini girin.

4. Hedef kullanıcının bağlantıya tıklamasını bekleyin.

5. Kullanıcının tıklamasıyla token değeri çıkarılır.

Yukarıdaki adımları metinle açıklamanın tercih edildiği durumlar vardır, ancak bazı durumlarda istek ve yanıt paketi gibi HTTP paketlerinin bir görüntüsünün eklenmesi de faydalı olabilir.

Ayrıca, bazı zafiyetlerin sadece belirli bir ortamda keşfedilebileceğini unutmayın. Bu tür zafiyetler için, zafiyetin keşfedildiği ortamın belirtilmesi önemlidir.

1. Zafiyetin Önem Derecesi

Zafiyetin önem derecesini kesin bir şekilde belirtin; daha iyi ifade etmek gerekirse, Zafiyetin duyarlılığını açıklayın, CVSS puanını doğru bir şekilde hesaplayın ve bu bölümde zafiyet raporuna yer verin. Zafiyetlerin değerlendirilmesi hakkında daha fazla bilgi için aşağıdaki makaleyi okuyabilirsiniz: "Strecan’da Açıklar Nasıl Değerlendirilir? "

2. Saldırı Senaryosu ve Kötüye Kullanım

Bu bölümde, kesinlikle keşfedilen bu zafiyete dayalı olarak bir saldırı senaryosu belirtmelisiniz. Saldırganın bu zafiyeti kullanarak neler yapabileceğini, kullanıcıların veya sunucuların hangi risklere maruz kaldığını veya daha iyi ifade etmek gerekirse, normalde mümkün olmayan hangi eylemlerin gerçekleştirilebileceğini açıklamalısınız. Bir avcı gerçekçi olmalı, gerçekleşen saldırı sürecini ve senaryosunu yazmalı ve teorik düşüncelere ve olasılıklara yönelik yaklaşımlardan kaçınmalıdır. Sonuç olarak, hedefler üzerinde etkili olabilecek belirli saldırılar için tam bir senaryo oluşturmak mümkün olmasa da, bu senaryo güvenlik ekibi ve değerlendirme ekibi tarafından anlaşılır ve kanıtlanabilir olmalıdır. Otomatik araçların saldırı senaryolarını tanımlayamayacağını ve yalnızca bu zafiyetlere ilişkin ek açıklamalar sunabileceğini unutmayın.

3. Zafiyetin Kanıtlanması ve Exploit Yöntemi

Tamamen açık ve net bir şekilde ifade edilmesi gereken konulardan biri, zafiyetin nasıl sömürüldüğüdür. Örneğin, XSS zafiyetinde, saldırı senaryosuyla birlikte exploit kodunun yerleştirilmesi zorunludur. XSS zafiyeti raporu için sadece alert(1) rapor etmemeye dikkat edin. Önemli ve dikkate değer bir nokta, saldırı senaryosu olmadan yapılan bir zafiyet raporunun değersiz olduğudur. Bu nedenle, saldırı senaryosu, bir zafiyet raporunun en temel bölümlerinden biridir. Ayrıca, zafiyetin nasıl sömürüldüğüne ve kötüye kullanıldığına dair bilgi verilmeden yapılan bir zafiyet raporu da değersizdir. Bu nedenle, zafiyetin nasıl sömürüldüğünün açıklanması, bir zafiyet raporunun en önemli bölümlerinden biridir.

4. Zafiyet bulmak için kullanılan araçlar ve kodlar

Kullanılan tüm araçlar ve kodlar zafiyet raporuna eklenmelidir. Bu bölümde hack araçlarının adlarını vermek değersizdir. Zafiyetin keşfi için özel olarak yazılmış kod veya araçları belirtmelisiniz.

5. İsteğe Bağlı ve Tamamlayıcı Bölümler

Saldırı sürecinden resim ve videoların yüklenmesi, inceleme sürecine yardımcı olabilir.

Eklenen video ayrıca şunları içermelidir:

• Mümkün olduğunca kısa olmalıdır.
• Uygun kaliteye sahip olmalıdır.
• Yüksek bir dosya boyutuna sahip olmamalıdır.
• Çeşitli konular içermemeli ve diğer bir deyişle sadece bir konuya odaklanmalıdır.

Unutmayın ki fotoğraf ve videolar yalnızca Strecan paneline raporlama amacıyla yüklenmelidir. Paylaşım alanlarına yüklenmesi, Strecan kurallarına göre zafiyet bilgilerinin genel olarak yayınlanması olarak kabul edilecek ve ödül alma sürecinizin askıya alınmasına ve hukuki sonuçlara yol açabilecektir.

Ayrıca, zafiyetin çözümüne dair bir çözüm önerisini raporunuza eklemenizi öneririz. Keşfedilen zafiyet ve ilgili saldırı hakkındaki bağlantıları raporunuzun sonunda belirtebilirsiniz. Son olarak, yazdığınız raporu kontrol etmek ve eksiklikleri bulmak için saldırıyı kendi başınıza tekrarlayın, böylece nihai zafiyet raporunuzun kapsamlı ve optimize edilmiş bir versiyonunu gönderebilirsiniz.

İstenen ve Beklenen Rapor Örnekleri

Aşağıdaki bağlantılar, yazarların söz konusu ilkeleri titizlikle takip ettikleri ve raporlarında belirli noktalara dikkat ettikleri raporlara aittir. Bu raporlarda, açıkça görülen bir kalite seviyesine ulaşmış ve yüksek kaliteli bir raporun özelliklerine sahip oldukları fark edilen bazı önemli noktalar vardır:

Jüri ekibinin insan olduğunu unutmayın:

Mümkün olduğunca basit bir dil kullanın. Kısaltma, deyim ve benzeri öğelerden kaçının, çünkü sadece metni karmaşık hale getirir ve okuyucuyu zorlar. Unutmayın ki hepimiz hatalar yapabiliriz. Eğer raporunuzun değerlendirme sürecinin herhangi bir aşamasında bir hata meydana gelirse veya dikkatsizlik olursa, ilgili kişiyle iletişime geçin ve sorununuzu sabırla açıklayın. Uyumazlıklar kaçınılmazdır, ancak bir avcı olarak, net ve anlaşılır bir güvenlik açığı raporu yazarak bu uyumsuzluk olasılığını en aza indirebilirsiniz. Bu şekilde, güvenlik açığı keşfi uzmanlığınızı göstermenin yanı sıra iletişim becerilerinizi de sergilemiş olursunuz. Bu makalede ele aldığımız konular, avcılar tarafından sıkça karşılaşılan sorunlardır. Umarız bu bilgileri paylaşarak rapor inceleme sürecindeki zaman kayıplarını ve yanlış rapor sayısını azaltabiliriz.