1998’in sonlarında, teknoloji alanındaki kariyerime yeni başladığımda, saygıdeğer Phrack dergisinde, zayıf girdi temizleme işleminin rain.forest.puppy’nin (Jeff Forristal tarafından kullanılan takma ad) SQL sorgu dizelerini doğrudan arka uca iletmesine nasıl izin verdiğini okudum. Bir Web uygulamasının veritabanı.
Çeyrek yüzyıl sonra, güvenlik meyveleri arasında en düşük seviyedeki SQL enjeksiyonunun hala Dünya Çapında Açık Uygulama Güvenliği Projesi’nin (OWASP) İlk 10 güvenlik açıkları listesinde yer alması talihsiz bir gerçektir. Şimdiye kadarki en kötü saldırılardan biri, Heartland Ödeme Sistemlerinin ihlal edildiği ve 130 milyondan fazla kredi ve banka kartı numarasının ele geçirildiği 2008 yılında gerçekleşti. 2023 yılında Cl0p fidye yazılımı grubu, MOVEit’teki daha önce bilinmeyen SQL enjeksiyon güvenlik açıklarından yararlandı. İlerleme Yazılımı dosya aktarma programıve bir tedarik zinciri saldırısının parçası olarak yüzlerce kurbanı tehlikeye attı.
Ne olduğunu tespit etmek için Progress Software’in yazılım geliştirme yaşam döngüsü veya güvenlik uygulamaları hakkında bilgimiz yok. Bir güvenlik açığı değerlendirme sistemi veya hatta bir hata avlama programı, koddaki SQL enjeksiyon kusurlarını, istismar edilmeden önce potansiyel olarak tespit edebilirken, yapı itibariyle güvenli kod üretmeye odaklanmak, bu güvenlik açığı sınıfını ele almanın daha iyi bir yoludur.
Yöntemler, doğrudan SQL sorgularını iletmek yerine saklı yordamların kullanılmasını ve girişi temizlemek için yazılım kitaplıklarının dahil edilmesini içerir. Bu, üretilen kodun yapım gereği güvenli olmasını sağlar ve ekiplerin daha sonra kalite kontrol veya hata avı yapmasını gerektirmez; her ikisi de pahalı ve hataya açık olabilir.
Sola Kaymak — Eğitime Giden Yol
“İnşaat yoluyla güvenliği sağlamak” burada gerçekten anahtardır ve bu, hem geliştiriciler hem de güvenlik ekipleri için eğitim gerektirir. Sık sık “sola kayma”dan bahsederiz ve kaydırabileceğiniz en sol alan eğitimdir (OpenSSF’nin Güvenli Yazılım Geliştirmenin Temelleri Kursları gibi). Geliştiriciler kod tabanında saklı prosedürleri ve tutarlı giriş temizlemeyi kullanmış olsaydı, MOVEit bu istismardan yapısal olarak kaçınabilirdi. Güvenlik, yalnızca bir kontrol noktası veya piyasaya sürülmeden önce bir SDLC kapısı olarak değil, kod kalitesinin entegre bir parçası olarak yazılım geliştirme yaşam döngüsüne (SDLC) yerleştirilmelidir.
Güvenlik kusurlarının erkenden doğru bir şekilde belirlenmesi, geliştiricilerin bunları sistematik olarak ele almasına olanak tanır. Üretimde, altyapı yoluyla kod olarak sürekli yeniden oluşturma, en az ayrıcalık yürütme, korumalı alan oluşturma ve etki alanı izolasyonu gibi iyi operasyonel uygulamaların sağlanması, tehdit gruplarının istismar edilen hizmetlere kalıcı erişim elde etmemelerini sağlamaya yardımcı olabilir.
Çoğu geliştirici ne yapması gerektiğini biliyor ancak hıza güvenlikten daha çok önem veriyor. Bu nedenle eğitim, güvenli kodlama uygulamalarının değerini ve bu uygulamaları göz ardı etmenin katlanarak artan maliyetlerini içermelidir. Ancak bu eğitim yalnızca geliştiricilerin güvenli bir şekilde kodlamak için gereken zamanı ayırma konusunda desteklendiğini hissetmeleri durumunda etkili olacaktır. Geliştiricilere güvenli bir şekilde kodlama yapmaları söyleniyorsa ancak organizasyon kültürü onları “yavaş” oldukları için dolaylı veya açık bir şekilde cezalandırıyorsa, kesinlikle güvenli olmayan yollara geri döneceklerdir.
Eğitim tek yönlü gitmez. Güvenlik ekiplerinin geliştiricilere çok az bağlamla güvenlik açığı bilgileri sağlaması işleri karmaşık hale getiriyor. Genellikle yazılım geliştirme yaşam döngüsünün sonlarında bir kontrol noktasında düzeltilmesi gereken bir rapor olarak sunulan bu bilgiler, geçerli bulguları yanlış pozitiflerden ayıkladığı için geliştiricinin hızını engeller. Güvenlik ekiplerini daha iyi yazılım mühendisleri olacak şekilde eğitmek, işleme alınamayan güvenlik raporlarının zahmetini azaltmaya ve yazılım mühendislerinin daha iyi kod üretmesine yardımcı olabilir.
Bir Sonraki İhlalin Planlanması
MOVEit güvenlik açığı bunun ne kadar kritik olduğunu gösteriyor her kuruluş Yazılım tedarik zincirini anlayın. Yazılım ve altyapının doğru varlık envanterleri, şirketlerin siber güvenlik olaylarına, ihlallere dönüşmeden önce müdahale edebilmeleri için ön koşuldur; OpenSSF SBOM Everywhere SIG’nin var olmasının nedeni budur.
Elbette sihirli değnekler yok ve yazılım tedarik zincirinin karmaşıklığı, gelecekte daha fazla olayın meydana geleceğini neredeyse garanti ediyor. Şirketlerin, güvenlik ve mühendislik ekiplerinin sorunları panik ve sezgiler yerine iyi bilinen runbook’lar ve prosedürler yoluyla çözmeye hazır olmalarını sağlamaya yardımcı olacak, iyi uygulanmış bir olay müdahale planına sahip olması gerekir.
Gerçekten de, güvenlik sorunlarına yanıt verme yeteneğimiz yıllar içinde çok daha iyi hale gelmiş olsa da, MOVEit’e verilen panikli yanıtlara ilişkin raporlar, hâlâ gidecek uzun bir yolumuzun olduğunun kanıtıdır. Mühendislik ekipleri ve güvenlik ekiplerinin, güvenlik olaylarına müdahale konusunda daha fazla pratik yapması gerekir. Bu, runbook’ların belgelenmesi ve masaüstü alıştırmalar yoluyla düzenli olarak uygulanması anlamına gelir. İster gerçek ister pratik olsun bir olaydan sonra kuruluşlar, iyileştirme alanlarını belirlemek ve bir sonraki olayda daha iyi uygulama sağlamak için bir “sıcak yıkama” veya eylem sonrası raporu geliştirmelidir.
Son olarak, iyi güvenlik, farklı geçmişlere ve bakış açılarına sahip çok disiplinli ekipler aracılığıyla gerçekleştirilen bir takım sporudur. Sorunlarımızı, onlara sebep olan homojen düşünceyle çözemeyiz; Düşünce çeşitliliği önemlidir.
Umuyorum ki, eğer biri 2033’te bu makaleyle karşılaşırsa, “SQL enjeksiyonu bugün nasıl hala sorun oluyor?” yerine “Şükürler olsun ki şirketler güvenlik önlemlerini aldılar” diyecekler.