Security.txt Oluşturucu

security.txt, IETF (İnternet Mühendisliği Görev Gücü) tarafından RFC 9116'da resmi olarak standartlaştırılan bir web güvenliği en iyi uygulamasıdır ve web sitelerine güvenlik iletişim bilgilerini yayınlamak için birleşik, standart bir yol sağlamak üzere tasarlanmıştır. Basitçe söylemek gerekirse, web sitesinde sabit bir yola yerleştirilen bir metin dosyasıdır ve güvenlik araştırmacılarına (beyaz şapka hackerlar) şunu söyler: "Web sitemde güvenlik zafiyetleri bulursanız, bizimle iletişime geçme yolu burada, şifreleme açık anahtarımız burada, ifşa politikamız burada, raporlarınızı memnuniyetle karşılarız."

security.txt standardı ortaya çıkmadan önce, web sitelerinin güvenlik iletişim bilgileri düzensizdi. Bazı web sitelerinde hiç güvenlik iletişim bilgisi yoktu, bazıları belirsiz bir sayfada gizlemişti, bazıları yalnızca kimsenin bakmadığı bir info@ e-postası bırakmıştı, bazıları ise güvenlik ekibini bulmak için LinkedIn'de zahmetli aramalar gerektiriyordu. Bu ciddi bir soruna neden oldu: iyi niyetli güvenlik araştırmacıları zafiyet keşfettiklerinde, genellikle bildirmek için doğru kanalı bulamadılar. Sonuç olarak—birçok zafiyet sessizce rafa kaldırıldı, düzeltilmeden bırakıldı, ta ki kötü niyetli hackerlar tarafından keşfedilip istismar edilene kadar. security.txt bu "son mil" sorununu çözmek için doğdu.

security.txt kavramı ilk olarak güvenlik araştırmacıları EdOverflow ve Yakov Shafranovich tarafından 2017'de önerildi ve hızla endüstri genelinde geniş destek kazandı. Nisan 2022'de security.txt, IETF tarafından resmi olarak RFC 9116 olarak onaylandı ve uluslararası kabul görmüş bir web güvenlik standardı haline geldi. Bugün, Google, GitHub, Meta (Facebook), LinkedIn, Cloudflare gibi büyük teknoloji şirketlerinin yanı sıra Birleşik Krallık Hükümeti, ABD CISA (Siber Güvenlik ve Altyapı Güvenliği Ajansı), Fransa Hükümeti, İtalya Hükümeti, Hollanda Hükümeti, Avustralya Siber Güvenlik Merkezi gibi devlet kurumları resmi web sitelerinde security.txt dağıtmış ve diğer kuruluşların benimsemesini herkese açık olarak önermektedir.

security.txt dosyasının temel tasarımı çok basittir—HTTP başlık biçimine benzer şekilde "alan-adı: değer" biçimindeki satırlardan oluşan düz bir metin dosyasıdır. Standart iki zorunlu alan tanımlar: Contact (güvenlik iletişim bilgileri, birden fazla olabilir) ve Expires (dosya sona erme zamanı); ayrıca birkaç isteğe bağlı alan: Encryption (PGP şifreleme açık anahtar URL'si), Acknowledgments (teşekkür sayfası URL'si), Policy (zafiyet ifşa politikası URL'si), Hiring (güvenlik işleri URL'si), Canonical (kurallı dosya URL'si), Preferred-Languages (desteklenen rapor dilleri), CSAF (Ortak Güvenlik Danışma Çerçevesi sağlayıcı meta veri URL'si). Bu basit biçim hem insanların hem de makinelerin kolayca ayrıştırmasını sağlar.

security.txt dağıtmak neden bu kadar önemlidir? İlk olarak, zafiyet bildiriminin önündeki engeli azaltır. Güvenlik araştırmacılarının iletişim bilgilerini bulmak için önemli zaman harcaması gerekmez—doğru raporlama kanalını tek tıkla bulabilirler. İkincisi, bir kuruluşun güvenliğe yönelik proaktif tutumunu gösterir—security.txt'ye sahip bir web sitesi aslında "Güvenliği ciddiye alıyoruz ve sorumlu raporları memnuniyetle karşılıyoruz" diyor. Üçüncüsü, zafiyetlerin herkese açık olarak ifşa edilme veya istismar edilme riskini azaltır: resmi bir kanalla araştırmacılar, kimseye ulaşamadıkları için zafiyetleri doğrudan Twitter veya GitHub'da herkese açık olarak ifşa etmeyi seçmezler. Dördüncüsü, birçok endüstri düzenleyici gereksinimde (finans, sağlık, devlet gibi) bir zafiyet ifşa kanalı oluşturmak uyumluluk gereksinimi haline gelmiştir.

security.txt dağıtırken dikkat edilmesi gereken birkaç önemli ayrıntı vardır. Birincisi, yol doğru olmalıdır: standart yol /.well-known/security.txt'dir ve kök dizine /security.txt olarak bir kopyayı yedek olarak da yerleştirebilirsiniz. Buradaki .well-known dizini RFC 8615 tarafından tanımlanan standart "bilinen kaynaklar" dizinidir, robots.txt gibi diğer standart dosyalar da ilgili konumlara yerleştirilir. İkincisi, HTTPS üzerinden sunulmalıdır—düz metin HTTP güvensiz olarak kabul edilir. Üçüncüsü, Content-Type text/plain olmalıdır, text/html veya diğer türler olmamalıdır. Dördüncüsü, security.txt için çapraz alan adı yönlendirmesi yapmayın—https://example.com/.well-known/security.txt https://other-domain.com/security.txt adresine yönlendirirse, araştırmacılar ve otomatik araçlar bunu şüpheli olarak değerlendirir. Beşincisi, Expires alanını ayarlamayı ve düzenli olarak güncellemeyi unutmayın; süresi dolmuş bir security.txt'nin bilgilerinin güvenilmez olduğu kabul edilir.

Contact alanı security.txt'deki en önemli alandır ve gerçekten vazgeçilmez tek alandır (Expires da zorunludur ancak yalnızca bir zaman damgasıdır). Contact üç URI biçimini destekler: e-posta adresleri için mailto:, web bağlantıları için https:// (güvenlik raporu form sayfaları gibi), telefon numaraları için tel:. En az bir mailto e-postası ve bir https form bağlantısı sağlamanız şiddetle önerilir—formlar bot istenmeyen postasını önler, e-posta ise araştırmacıların doğrudan şifreli rapor göndermesi için daha uygundur. Birden fazla iletişim kişisi birden fazla satırda listelenebilir, örneğin aynı anda hem güvenlik ekibi e-postası, hem güvenlik sorumlusu e-postası hem de üçüncü taraf zafiyet platformu bağlantıları sağlanabilir.

Encryption alanı isteğe bağlı olsa da pratikte çok önemlidir. Güvenlik araştırmacıları ciddi bir zafiyet keşfettiğinde (kullanıcı veri sızıntısı, uzaktan kod yürütme gibi), zafiyet ayrıntılarını düz metin e-postayla göndermek istemezler—çünkü e-posta iletim sırasında birden fazla sunucudan geçer, herhangi bir noktada dinlenebilir. PGP (Pretty Good Privacy) açık anahtar şifrelemesi, güvenli iletişim için endüstri standardıdır. Yalnızca bir PGP anahtar çifti oluşturmanız, açık anahtarı web sitenize yerleştirmeniz (örn. /.well-known/pgp-key.txt konumuna) ve bu URL'yi Encryption alanına girmeniz yeterlidir. Araştırmacılar rapor içeriğini açık anahtarınızla şifreler ve yalnızca ilgili özel anahtarı tutanlar şifreyi çözüp okuyabilir.

Policy alanı Zafiyet İfşa Politikanız (Vulnerability Disclosure Policy, VDP) sayfasına bağlantı verir, bu da araştırmacı güveni oluşturmanın anahtarıdır. İyi bir VDP şunları açıkça belirtmelidir: test kapsamı (hangi sistemler test kapsamındadır ve hangileri değildir), izin verilen test yöntemleri (örn. SQL enjeksiyonu/XSS testine izin verilir ancak DDoS/sosyal mühendislik/gerçek kullanıcı verilerine erişim yasaktır), taahhüt edilen yanıt süreleri (örn. "Raporların alındığını 3 iş günü içinde onaylayacağız"), ödül sunup sunmadığınız, yasal güvenli liman taahhütleri (kurallara uyan iyi niyetli araştırmacılara dava açmayacağınızı açıkça belirtmek). Uluslararası olarak başvurulabilecek birçok VDP şablonu vardır ve ABD CISA ayrıca açık kaynaklı bir VDP şablonu sağlar.

Güvenlik iletişiminin ötesinde, security.txt'nin birkaç "sürpriz" alanı daha vardır. Acknowledgments alanı bir Güvenlik Şeref Listesi oluşturur—zafiyet bulmanıza yardımcı olan araştırmacılara herkesin önünde teşekkür etmek, bu onların çalışmalarını tanımak ve aynı zamanda bir topluluk oluşturma yöntemidir. Hiring alanı ise çok zekice bir tasarımdır: web sitenizdeki zafiyetleri bulan kişiler doğası gereği mükemmel güvenlik yetenekleridir ve security.txt'ye işe alım bağlantısı yerleştirmek, güvenlik yeteneklerini işe almak için en kesin kanaldır. Birçok şirket security.txt aracılığıyla mükemmel güvenlik mühendisleri işe almıştır. Canonical alanı ise bir güvenlik önlemidir—saldırganların security.txt'nizi diğer alan adlarında sahtecilik yapmasını önler.

Yaygın istenmeyen posta endişesi konusunda, pratikte security.txt dağıtan çoğu kuruluş istenmeyen postada belirgin bir artış olmadığını bildirmektedir. Bunun nedeni: birincisi, istenmeyen posta gönderenler genellikle security.txt tarayarak e-posta adresi elde etmez; ikincisi, doğrudan mailto e-postası yerleştirmek yerine https:// form bağlantıları kullanılabilir ve formlara CAPTCHA eklenmesi botları tamamen engelleyebilir; üçüncüsü, özel güvenlik e-postaları (örn. security@) genellikle sıkı istenmeyen posta filtrelemesi ile yapılandırılır. Buna karşılık, bir güvenlik iletişim kanalı eksikliği nedeniyle kaçırılan ciddi zafiyet raporlarının maliyeti, olası küçük miktarlardaki istenmeyen posta artışından çok daha fazladır.

Bu oluşturucu, RFC 9116 standardına sıkı sıkıya bağlı olarak oluşturulmuştur ve tüm çıktı biçimleri normalleştirilmiştir: Contact alanı önekleri otomatik olarak tanır, Expires alanı standart ISO 8601 UTC zaman biçimini kullanır ve Preferred-Languages, kullandığınız dile göre otomatik olarak ayarlanır. Oluşturulan içerik doğrudan kopyalanıp /.well-known/security.txt yoluna hiçbir değişiklik yapılmadan dağıtılabilir. Ek olarak, tüm yapılandırma tarayıcınızda yerel olarak yapılır ve hiçbir sunucuya gönderilmez—güvenlik iletişim bilgileriniz her zaman cihazınızda kalır. security.txt dağıtmak yalnızca 5 dakika sürer, ancak oluşturduğu güvenlik iletişim kanalı gelecekte ciddi bir güvenlik olayından kaçınmanıza yardımcı olabilir.