Stronger_Cracker
- 25 Tem 2022
- 6,407 Mesaj
Selamun Aleykum yeni nesil hack işini bilmiyorum işin uzmanları örneklerde verebilirse seviniriz.
Bir ASP.NET Core projesinde güvenlik sadece bizim tarafımızdan yazdığımız controller, service veya SQL sorgularıyla sınırlı değilmiş. Projeye eklediğimiz NuGet paketleri de saldırı yüzeyinin bir parçasıdır. Red Team bakışında supply chain attack denilen konu tam olarak burada başlıyor(muş): saldırgan doğrudan bizim kodumuzu aşmak yerine, güvendiğimiz bağımlılıkları hedef alır. Özellikle eski sürümde kalmış, bakımı zayıflamış veya bilinen açıkları bulunan paketler uygulamanın en zayıf halkasına dönüşür. OWASP(Açık Web Uygulama Güvenliği Projesi) da yazılım tedarik zinciri risklerini ayrı bir güvenlik başlığı olarak ele alıyor.
ASP.NET Core tarafında tipik bir örnek düşünelim. Projede dosya işleme, loglama, JSON parse etme, mail gönderme veya authentication için dış paket kullanıyoruz. Bizim kodumuz temiz olsa bile, o paketin eski bir sürümünde yayınlanmış bir CVE varsa saldırgan çoğu zaman önce oraya bakar. Çünkü geliştiriciler kendi kodunu gözden geçirir ama yıllar önce eklenmiş bir NuGet paketini çoğu zaman unutabilir. Microsoft da bu yüzden
NuGet paketleri için güvenlik denetimi yapılmasını ve bilinen zafiyetlerin restore aşamasında takip edilmesini resmi olarak öneriyor. Css veya bir JS kütüphanesi gibi çağrıldığı gibi ana kaynağından yapılamaz mı diye araştırdım fakat kimsenin aklına gelmemiş :
şaka şaka aslında CDN den çağır gibi olabilirmiş fakat DERLEME gerektireceği için şuan benzer işlemler varmış önerilmiyor. Kim bilir belki geliştirme aşamasında olan bu özellik yıllar sonra kullabiliriz.
İleri düzey fark burada ortaya çıkar: klasik yaklaşımda “uygulama çalışıyor, sorun yok” denir; modern güvenlik yaklaşımında ise “uygulama hangi paketlerle çalışıyor, bu paketlerin transitif bağımlılıkları ne durumda, bilinen açık var mı” diye bakılır. Yani risk sadece doğrudan eklediğin paket değil, o paketin altında gelen diğer bağımlılıklar da olabilir. Microsoft’un NuGetAudit yaklaşımı da tam olarak bu yüzden önemlidir; .NET 8 ve Visual Studio 17.8 ile doğrudan paketlerdeki bilinen açıklar için uyarı verilirken, .NET 9 ve Visual Studio 17.12 ile transitif paketler için de varsayılan uyarılar genişletildi hatta şu daha doğru bir cümle olacaktır. “.NET 8 ve .NET 9’da NuGetAudit varsayılan olarak doğrudan paketleri uyarır. .NET 10’da ise varsayılan davranış transitif bağımlılıkları da kapsayacak şekilde genişletilmiştir”.
Kısacası ASP.NET Core projesinde güvenlik sadece “kod yazmak” değildir. Kullanılan NuGet paketlerini seçmek, sürümlerini takip etmek, gereksiz bağımlılıkları kaldırmak ve CVE kayıtlarını düzenli izlemek de işin bir parçasıdır. Bazen saldırı kapısı bizim controller dosyamız değil, yıllardır güncellenmemiş tek bir paketin içindedir. Supply chain attack mantığı tam olarak bunu anlatır. Genel kavram olarak bu saldırı türü, yazılımın kendisinden çok onu oluşturan veya dağıtan zinciri hedef alır.
Bir ASP.NET Core projesinde güvenlik sadece bizim tarafımızdan yazdığımız controller, service veya SQL sorgularıyla sınırlı değilmiş. Projeye eklediğimiz NuGet paketleri de saldırı yüzeyinin bir parçasıdır. Red Team bakışında supply chain attack denilen konu tam olarak burada başlıyor(muş): saldırgan doğrudan bizim kodumuzu aşmak yerine, güvendiğimiz bağımlılıkları hedef alır. Özellikle eski sürümde kalmış, bakımı zayıflamış veya bilinen açıkları bulunan paketler uygulamanın en zayıf halkasına dönüşür. OWASP(Açık Web Uygulama Güvenliği Projesi) da yazılım tedarik zinciri risklerini ayrı bir güvenlik başlığı olarak ele alıyor.
ASP.NET Core tarafında tipik bir örnek düşünelim. Projede dosya işleme, loglama, JSON parse etme, mail gönderme veya authentication için dış paket kullanıyoruz. Bizim kodumuz temiz olsa bile, o paketin eski bir sürümünde yayınlanmış bir CVE varsa saldırgan çoğu zaman önce oraya bakar. Çünkü geliştiriciler kendi kodunu gözden geçirir ama yıllar önce eklenmiş bir NuGet paketini çoğu zaman unutabilir. Microsoft da bu yüzden
NuGet paketleri için güvenlik denetimi yapılmasını ve bilinen zafiyetlerin restore aşamasında takip edilmesini resmi olarak öneriyor. Css veya bir JS kütüphanesi gibi çağrıldığı gibi ana kaynağından yapılamaz mı diye araştırdım fakat kimsenin aklına gelmemiş :
şaka şaka aslında CDN den çağır gibi olabilirmiş fakat DERLEME gerektireceği için şuan benzer işlemler varmış önerilmiyor. Kim bilir belki geliştirme aşamasında olan bu özellik yıllar sonra kullabiliriz.İleri düzey fark burada ortaya çıkar: klasik yaklaşımda “uygulama çalışıyor, sorun yok” denir; modern güvenlik yaklaşımında ise “uygulama hangi paketlerle çalışıyor, bu paketlerin transitif bağımlılıkları ne durumda, bilinen açık var mı” diye bakılır. Yani risk sadece doğrudan eklediğin paket değil, o paketin altında gelen diğer bağımlılıklar da olabilir. Microsoft’un NuGetAudit yaklaşımı da tam olarak bu yüzden önemlidir; .NET 8 ve Visual Studio 17.8 ile doğrudan paketlerdeki bilinen açıklar için uyarı verilirken, .NET 9 ve Visual Studio 17.12 ile transitif paketler için de varsayılan uyarılar genişletildi hatta şu daha doğru bir cümle olacaktır. “.NET 8 ve .NET 9’da NuGetAudit varsayılan olarak doğrudan paketleri uyarır. .NET 10’da ise varsayılan davranış transitif bağımlılıkları da kapsayacak şekilde genişletilmiştir”.
Kısacası ASP.NET Core projesinde güvenlik sadece “kod yazmak” değildir. Kullanılan NuGet paketlerini seçmek, sürümlerini takip etmek, gereksiz bağımlılıkları kaldırmak ve CVE kayıtlarını düzenli izlemek de işin bir parçasıdır. Bazen saldırı kapısı bizim controller dosyamız değil, yıllardır güncellenmemiş tek bir paketin içindedir. Supply chain attack mantığı tam olarak bunu anlatır. Genel kavram olarak bu saldırı türü, yazılımın kendisinden çok onu oluşturan veya dağıtan zinciri hedef alır.