Dün bir okuyucudan IETF Yorum İsteği (RFC’ler) ile ilgili bir e-posta aldım:
“Hackerların RFC’leri okuduğunu duydum. RFC’leri okumaya ve ne aranacağına ilişkin bir kılavuz var mı? RFC’lerde çok fazla bilgi bulunduğundan, bunların üzerinden manuel olarak geçilemiyor.”
— Afolik
Bu harika bir soru ve daha önce duyduğum ancak bir blog yazısında ele almadığım bir soru.
Security.txt spesifikasyonu üzerinde çalışmış biri olarak (yakında RFC 9116 olacak), bir hata ödül avcısı olarak RFC’leri incelerken nelere dikkat edilmesi gerektiği konusunda biraz fikir verebilirim.
RFC’lerin nasıl inceleneceğine dair tavsiyelerime dalmadan önce şunu paylaşmama izin verin: Neden bir hata ödülü avcısı RFC literatürünü incelemek isteyebilir.
Neden?!
RFC’ler, okuyucuların belirli teknolojileri ve protokolleri uygulaması için referans malzemesi görevi görür.
Hata ödülü avcıları için belgeler, standardın yazarları tarafından tanımlanan belirli bir teknolojiye aşina olma fırsatıdır. RFC’ler, üçüncü tarafın tekrarına güvenmek yerine orijinal kaynak görevi görür. RFC’ler, geliştiricilerin uygulamalarını tasarlarken neyi gözden geçirmiş olabileceklerini incelemeye olanak tanır.
Ek olarak RFC’ler, uygulayıcıların spesifikasyondan nerede saptığını görmemize olanak tanır; dolayısıyla potansiyel olarak güvenlik kusurları ortaya çıkar.
Günün sonunda RFC spesifikasyonu yalnızca bir kılavuzdur. Uygulayıcılar teknolojiyi veya protokolü istedikleri gibi geliştirmekte özgürdür. RFC 1149 için güvercinler yerine kurbağaları kullanmayı tercih etmeye karar verirsem bu bana, yani uygulayıcıya bağlıdır.
Dalış yapmadan önce
Okuyucunun vurguladığı gibi Afolikdoğrudan bir RFC belgesine dalmak ilk başta göz korkutucu olabilir.
Başlangıçta, bir konuyu çevredeki sözcükleri tanıyarak gözden geçirmeyi tercih ederim. Örneğin, ICMP RFC’yi okumadan önce, RFC’yi incelemeye başlayacak kadar kendimi rahat hissedene kadar konuyla ilgili birkaç YouTube videosu izleyebilirim.
Hangi terminolojiye bakacağınızdan emin değilseniz, RFC’ler belgenin başlangıcına doğru özel bir “Terminoloji” bölümüyle birlikte gelir.
Sağ; artık RFC’yi okumaya hazırsınız.
Güvenlik Hususları bölüm
RFC 7322’de belirtildiği gibi, tüm RFC’lerin bir Güvenlik Hususları RFC’yi uygularken okuyucuların dikkate alması gereken güvenlik uygulamalarını kapsayan bölüm.
Tüm RFC’ler, spesifikasyonla ilgili güvenlik hususlarının tartışıldığı bir bölüm içermelidir; bkz. “Güvenlik Konularıyla İlgili RFC Metni Yazma Yönergeleri” [BCP72] daha fazla bilgi için.
— RFC 7322, Bölüm 4.8.5
Doğal olarak, hedef teknolojinin güvenliğini inceleyen birinin RFC yazarlarının güvenlikle ilgili değerlendirmelerini okuması mantıklı olacaktır. Örneğin, bir OAuth 2.0 uygulamasının güvenliğini mi test ediyorsunuz? RFC 6749’u inceleyin Güvenlik Hususları bölüm.
Security.txt spesifikasyonu bir “Güvenlik Hususları” bölüm de. Güvenlik hususlarını dikkate almayan okuyucuların ne gibi kusurlara yol açmış olabileceğini düşünebiliyor musunuz?
RFC’nin geçmiş sürümlerini inceleme
Bir uygulamayı hedeflerken, belirli özellikler ve uygulamalar eski RFC spesifikasyonlarını takip ediyor olabilir. Belgenin ön kısmında “Kaldırılan:” bağlantısı bulunduğundan RFC’nin güncelliğini yitirdiğini anlayabilirsiniz.
Okuma sürecini basitleştirmek için RFC’ler bir fark görüntüleyiciyle birlikte gelir. IETF’nin, fark oluşturmayı kolaylaştıran Rfcdiff Aracı adı verilen özel bir aracı vardır.
Zamanınız kısıtlıysa, içindekiler tablosunu farklılaştırmak çoğu zaman bir RFC’den diğerine yapılan değişiklikler hakkında birçok şeyi ortaya çıkarabilir.
Hatalar var
RFC’ler hatalar içerebilir. Yazarlar yalnızca insandır ve bazen yüzlerce düzenleme ve incelemeden sonra bile, bir hata nihai RFC spesifikasyonuna da girer.
Bu sorunu çözmek için IETF’de okuyucuların hataları (örn. hatalar) bildirebileceği hata panoları bulunmaktadır. RFC’de hatalar tespit edildiğinde belgede bir “Hata mevcut” bağlantısı bulunur.
RFC’lerdeki hatalar, geliştiricilerin uygulamalarında hata yapmasına neden olabilir. Güvenlikle ilgili konulardaki hataları gözden geçirmeye değer. Ardından hedefinizin belirli bir hatadan etkilenip etkilenmediğini belirleyin.
İncelediğiniz her RFC için, test edilebilecek güvenlikle ilgili hatalar içeren notlar tutmanızı öneririm. Bu şekilde, gelecekte güvenlikle ilgili bu hataları yeniden keşfetmek için RFC hatalarını tekrar gözden geçirmek zorunda kalmazsınız.
Çözüm
RFC’ler kuru olabilir ve gezinmesi zor olabilir. Umarım e-postaya verilen bu yanıt, hata ödülü avcılarının RFC’leri daha kolay incelemesine yardımcı olur.
Sorunuzun böyle bir blog yazısı şeklinde yanıtlanmasını istiyorsanız, lütfen bana bir e-posta gönderin.