On yıldan fazla bir süredir enjeksiyon güvenlik açıkları, Açık Web Uygulama Güvenliği Projesi tarafından tutulan 2010, 2013 ve 2017 İlk 10 listesinde diğer tüm güvenlik açıklarından daha ciddi kabul edilen, kritik derecede tehlikeli yazılım kusurları listelerinde tam anlamıyla üst sıralarda yer aldı.
Ancak uyarılar yine de sorunları ortadan kaldırmayı başaramadı. Geçtiğimiz yıl Cl0p grubu, MoveIT'in dosya aktarım uygulamasında önceden bilinmeyen bir SQL enjeksiyon güvenlik açığını kullanan şirketlerden veri çaldı. Mart ayı sonlarında Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), uygulama güvenliği uzmanlarının da değerlendirdiği gibi, şirketlere güvenlik sorununu ortadan kaldırma çabalarını iki katına çıkarma çağrısında bulundu. 13 farklı 'affedilemez' güvenlik açığı sınıfından biri programcıların geliştirme sırasında yakalaması gerekenler.
Ajans, 25 Mart tarihli danışma belgesinde, “Son yirmi yılda SQLi açıklarına ilişkin yaygın bilgi ve belgelemenin yanı sıra etkili hafifletme yöntemlerinin bulunmasına rağmen, yazılım üreticileri bu kusura sahip ürünler geliştirmeye devam ediyor ve bu da birçok müşteriyi riske atıyor” dedi. “SQLi gibi güvenlik açıkları, en az 2007'den bu yana başkaları tarafından 'affedilemez' bir güvenlik açığı olarak değerlendiriliyor.”
Uygulama güvenliği firması Snyk'in geliştirici ilişkileri başkanı Randall Degges, enjeksiyon güvenlik açıklarının temelinde girdi temizleme eksikliği yatmaktadır; uygulama değişken girdi aldığında, bu girdinin bozulma riski her zaman vardır, diyor.
“Programlamanın var olmasından bu yana bu bir sorun olmasına rağmen, bu kadar zaman geçmesine rağmen hâlâ ilk 10 güvenlik açığı arasında yer almasının nedeni, girdiyi kullanmanın sonsuz sayıda yolunun bulunması ve girdiyi zamanı temizlemenin çoğu zaman zor olmasıdır” diyor.
Bu özel sorunu ortadan kaldırmak isteyen yazılım geliştiricileri için bunu nasıl yapacağınızı burada bulabilirsiniz.
1. Kendinizi ve Başkalarını Eğitin
İlk adım her zaman eğitimdir. OWASP'ta var SQL enjeksiyonu hakkında kısa bilgi sayfası, güvenlik açığının nasıl tespit edileceği ve güvenli kod oluşturma yolları. Bazı web uygulaması çerçeveleri, React'ınki gibi bazı işlevlerin riskini netleştirmek için API adlarını kullanarak geliştiricileri programlama sırasında eğitmeyi amaçlamaktadır. 'tehlikeli bir şekildeSetInnerHTML' Uygulama güvenliği test firması PortSwigger'ın araştırma direktörü James Kettle, bu işlevin işe yaradığını söylüyor.
Buna ek olarak, geliştiricilerin güvenli kod kullanma konusunda açık kaynaklı yazılım üreticilerine (özellikle de iyi incelenmemiş bileşenlere) güvenmemeleri gerektiğini ve çevrimiçi eğitimlerin de genellikle güvensiz olduğunu söylüyor.
Kettle, “Bence asıl sorun, çok sayıda güvensiz API'nin bulunması ve API'yi kullanan herkesin varsayılan olarak savunmasız olması” diyor. “Daha modern güvenli API'ler mevcut olsa bile, StackOverflow'taki eski güvenli olmayan örnekler sayesinde yeni kodlar güvenli olmayan sürümler kullanılarak yazılıyor.”
2. Otomatik Araçlar Kullanarak DevOps Ardışık Düzenini Güçlendirin
Geliştiriciler, geliştirme sırasında kodu SQL enjeksiyon kusurlarına ve diğer yaygın güvenlik sorunlarına karşı kontrol etmek için birim testleri uygulamalı, taahhütlerin hem öncesinde hem de sonrasında statik uygulama güvenlik testleri eklemeli ve dinamik uygulama güvenlik testinin bir parçası olarak SQL enjeksiyonu için taramaları dahil etmelidir.
Birim testleri gibi çerçeveler kullanılarak eklenebilir tSQLt Microsoft SQL Server'ı test etmek için, pgTAP PostgreSQL kullanan uygulamaları test etmek için ve Pytest ve SQLAlchemy Python programlarında birim testi için. Çeşitli SQL birim testi en iyi uygulamaları SQL testlerinin bağımlılıklardan yalıtılması ve testlerin açıklayıcı isimlendirilmesi gibi testleri daha kullanışlı hale getirmek için takip edilmelidir.
Snyk'ten Degges, geliştirme sürecindeki otomatik testlere ek olarak geliştiricilerin SQLAlchemy gibi SQL çerçevelerini kullandıklarından emin olmaları gerektiğini söylüyor çünkü birçok güvenlik iyileştirmesi zaten mevcut.
“Günümüzde hemen hemen tüm modern SQL çerçeveleri ve araçları, bu konuda yardımcı olacak kolaylık yöntemleri sağlıyor; bu nedenle, sorgular oluştururken onu doğru kullandığınızdan emin olmak için ilgili çerçeve belgelerini baştan sona okumak en iyi seçenektir” diyor.
3. SQLMap ile Oynayın
açık kaynaklı program SQLMap Sızma testçilerinin SQL enjeksiyonunu denemeleri, olası güvenlik açıklarından yararlanmaları ve güvenlik açığından yararlanılabileceğini kanıtlamak için bir veritabanı dökümü yapmaları için harika bir araçtır. Araç aynı zamanda uygulama geliştiricilerini SQL enjeksiyonunun gerçek tehlikeleri ve savunmasız kodun nasıl istismar edilebileceği konusunda eğitebilir.
Ancak Portswigger's Kettle, aracın potansiyel güvenlik açıklarını taramanın en iyi yolu olmadığını söylüyor.
Kettle, “Tecrübelerime göre algılama yetenekleri yavaş, ağır ve hatalı pozitif sonuçlara eğilimli” diyor. “Ayrıca saldırı yüzeyini bulmak için web sitelerini inceleyemiyor ki bu da bu güvenlik açıklarını otomatik olarak bulmanın en büyük zorluklarından biri.”
4. DAST Hizmetini Düşünün
Kalite güvence aşamasının bir parçası olarak ve hatta mümkünse DevOps hattında daha erken bir zamanda Dinamik Uygulama Güvenliği Testini (DAST) kullanarak SQL enjeksiyon taramasının otomatikleştirilmesi, gözden kaçan güvenlik açıklarının yakalanmasına yardımcı olabilir. Ayrıca DAST taraması, eski kodda SQL enjeksiyonunu bulmanın iyi bir yoludur.
Kettle, web uygulaması güvenlik duvarlarının (WAF'ler) SQL enjeksiyon saldırılarının bir uygulamaya ulaşmasını engelleyebileceğini ancak bunların yalnızca derinlemesine savunma stratejisinin bir parçası olarak kullanılmaları ve bunlara güvenilmemeleri gerektiğini söylüyor.
“Şahsen ben WAF'ler gibi çalışma zamanı korumasının o kadar çok kez atlandığını gördüm ki onlara pek güvenmiyorum” diyor. “Bunun yerine, tespit edilemeyen güvenlik açıklarını ortaya çıkarmanın etkili bir yolu olarak bir hata ödül programını öneriyorum ve WAF'ları, bilinen güvenlik açıklarının yamalanamayacağı kadar kötü durumda olan sistemler için son çare olarak kullanıyorum.”
5. SQL'in Ötesine Genişleyin
Son olarak, SQL enjeksiyonu enjeksiyon güvenlik açıklarının yalnızca bir sınıfı olduğundan, şirketlerin diğer enjeksiyon güvenlik açıklarını da araması ve geliştiricilerinin riskli modelleri tanıdığından emin olması gerekir.
OWASP, enjeksiyon güvenlik açığı tanımını, kullanıcı tarafından sağlanan verilerin bir uygulama tarafından doğrulanmadığı veya sterilize edilmediği ve daha sonra bir tercümana gönderilmediği herhangi bir yazılım kusurunu kapsayacak şekilde genişletmektedir. Siteler arası komut dosyası oluşturma, SQL, işletim sistemi komut dosyası oluşturma ve Basit Dizin Erişim Protokolü'nü (LDAP) ayrıştırma, bunların tümü enjeksiyona karşı savunmasız olabilecek alanlardır.
Örneğin yapay zeka modellerinin ortaya çıkışıyla birlikte, hızlı enjeksiyon, enjeksiyon saldırısının en son biçimi haline geldi.