Uygulama Güvenlik Açıklarını Anlamak

Uygulama güvenliği, yazılımcılar için önemli bir konudur. 2011 yılından beri profesyonel olarak yazılım geliştiriyorum. Java, C#, Kotlin, Node.js gibi dilleri kullandım. Büyük ölçekli şirketlerin arka uçları, mikro hizmetleri, API'leri ve veri işlem hatları gibi projelerde çalıştım. Milyonlarca insanın kullandığı üretim kodlarını gönderdim. Takımları yönettim, mimarileri inceledim, genç mühendisleri mentörlük ettim ve 'senior yazılımcı' olarak anılmaya değer deneyimler kazandım.

Ancak, uygulama güvenliğine geçiş yapmaya karar verdiğimde, önemli bir bilgi açığım olduğunu fark ettim. Yazılımların nasıl çalıştığını biliyordum, ancak nasıl başarısız olabileceğini ve saldırganların bunu nasıl kullanabileceğini bilmiyordum.

Güvenli Kod Yazmayı Biliyordum, Ama Neden Güvenli Olduğunu Bilmiyordum.

Utandığım bir itiraf: En az on yıl önce parametrelendirilmiş sorguları kullanmaya başladım. Nasıl çalıştıklarını tam olarak bilmiyordum, ancak güvenli olduklarını biliyordum. Ancak, neden güvenli olduklarını açıklamamı isteseniz, bana 'veritabanı bunu ayrı olarak işler' gibi belirsiz bir cevap verirdim.

SQL enjeksiyonu algılama kuralını oluştururken, bunun nedenini tam olarak öğrenmek zorunda kaldım. SELECT * FROM users WHERE id = " + userId gibi bir sorgunun neden tehlikeli olduğunu, SELECT * FROM users WHERE id = ? gibi bir sorgunun neden güvenli olduğunu ve neden bu farkın önemli olduğunu öğrenmek zorunda kaldım.

Cevap, parametrelendirilmiş sorguların sorgu yapısını ve veriyi ayrı mesajlarda göndermesi ve veritabanının veriyi SQL sözdizimi olarak işlememesidir. Bu cevap karmaşık değildir, ancak ben bunu tam olarak bilmiyordum.

Güvenlik, Bir Düşmanlık Alanıdır

Yazılım mühendisliği büyük ölçüde bir işbirliği alanudur. Bir şeyler inşa ediyorsunuz ve amacınız bunun çalışmasını sağlamaktır. Sistem hakkındaki zihinsel modeliniz, happy path etrafında dönüyor - girdiler geçerli, ağlar güvenilir ve kullanıcılar beklendiği gibi davranıyor.

Uygulama güvenliği ise düşmanlık alanıdır. Gereken zihinsel değişim başlangıçta gerçekten karıştırıcıdır.

JWT algoritması olmayan kuralı oluştururken, kimlik doğrulama tokenlerini sahtelemek isteyen biri gibi düşünmek zorunda kaldım. Bunu yapmak istiyorum diye değil, çünkü saldırganın nasıl çalıştığını, saldırganın ne kontrol ettiğini, hangi varsayımların yapıldığını ve nasıl bir saldırı zinciri oluştuğunu anlamazsam, güvenilir bir şekilde bunu algılayan bir kural yazamazdım.

Bu, 13 yıllık bir yazılımcı olarak geliştiremediğim bir beceridir: düşmanlık düşüncesi. Soru, 'bu kod çalışır mı?' değil, 'bu kodu nasıl çalıştırabilirsiniz?'

OWASP Top 10, temel olarak geliştiricilerin yaptığı varsayımların saldırganlar tarafından sömürülmesi ile ilgili bir kataloğdur. A03 - Enjeksiyon, girdilerin veri değil, komutlar olduğunu varsayar. A07 - Kimlik Doğrulama Hataları, kodun kimliği doğru şekilde doğruladığını varsayar. A02 - Kriptografik Hatalar, şifrelemenin verilerin korunmasını sağladığını varsayar.

Her kategori, geliştiricilerin sistem hakkındaki zihinsel modelinin saldırganların neler yapabileceği ile arasındaki bir ayrımdır. OWASP'yi derinlemesine anlamak, bu ayrımları anlamak demektir - bir kontrol listesi olarak değil, bir düşünce tarzı olarak.

Araçlar, Cevaplar Değil, Amplifikatörlerdir

Kendi SAST aracımı oluşturmadan önce, SAST araçlarını kullanıyordum. Ve bunları yaklaşık bir derleyici uyarısı gibi kullanıyordum: bir şey ateşlendi, bakıyordum, onu düzeltmeye veya görmezden gelmeye karar veriyordum.

Bir tane oluşturmak, SAST aracının ne olduğu hakkında düşüncemi değiştirdi.

Bir SAST aracı,codified bir dizi kestirme tentang nedir vulnerable kod gibi. Bu kestirme,insanlar tarafından yazılı ve insan anlayışına dayanan güvenlik açığı modelleri ile birlikte confidence düzeyleri ve severity değerlendirmeleri ile kararlar alınır. Araç, kod tabanınızı bilmez, tehdit modelinizi bilmez, üretilen bulgunun gerçekten sömürülebileceğini belirli bir dağıtım bağlamında bilmez.

Bu, bir eleştiri değil, bir aracın uygun rolünün tanımıdır.

Artık Snyk veya Semgrep'i çalıştırdığımda, sonuçlarla farklı bir şekilde ilgileniyorum. Şunu soruyorum: Bu kural hangi modeli yakalamaya çalışıyor? Bu model, kuralın varsaydığı nedenle kod tabanında mevcut mu? Hedeflenen güvenlik açığı, bu bağlamda gerçekten uygulanabilir mi? Bir saldırganın bunu sömürmek için ne kontrol etmesi gerekir?

Bu, uygulama güvenliği soruları, değil DevOps soruları. Bir DevOps zihniyeti, SAST çıktısını bir uyumluluk kapısı olarak görür. Bir uygulama güvenliği zihniyeti, bunu bir analiz başlangıç noktası olarak görür.

Güvenlik açıklarını anlamak ve bunlara karşı korunmak için sürekli olarak öğrenmeye ve gelişmeye ihtiyacımız var. Uygulama güvenliği, sadece teknik bir sorun değil, aynı zamanda bir zihinsel model ve düşünce tarzı meselesidir.