Web Güvenliğinde Otomasyonun Önemi

Web Uygulamalarının ve Web Güvenliğinin Evrimi

İnternetin ilk yıllarında zaten az sayıda olan web sitesi daha çok resim ve doküman tarzı statik dosyaların saklanması, bunların yine aynı şekilde kullanıcıya sunulmasından ibaretti. Bir çok web sitesi kimlik doğrulama gerektirmediği gibi, kullanıcı ile etkileşimi sağlayan herhangi bir mekanizma da web sitelerinde bulunmamakta idi. Web uygulamalarındaki güvenlik zafiyetlerinin oluşmasının en büyük etkeni olan girdi noktalarının çokluğu ve bu girdi noktalarından alınan verilerin risk oluşturacak şekilde doğrudan işleme tabi tutulması, bu statik sayfalarda kendini göstermiyordu.

Haliyle web uygulamalarının hack edilmesi için kullanılan zafiyetler genellikle web sitesinin barındırıldığı sunucu üzerindeki işletim sisteminden ya da web server yazılımından kaynaklı oluyordu. Peki bu web siteleri hack edilip ele geçirildikten sonra? Çoğu zaman bu web sitelerinin bulunduğu sunucular, warez içerikleri için bir storage niyetiyle kullanılıyor, ancak web sitesinin hosting seviyesindeki bant genişliği dolduğu zaman web site sahibinin hack edildiğinden haberi oluyordu.

Bugün ise web siteleri evrimsel sürecini neredeyse tamamlamış, ilk başladığı yerden fersah fersah ileride, dinamik ve etkileşimli bir yapıya bürünmüş durumda. Bugün web siteleri, daha doğru tanımlamak gerekirse web uygulamaları aracılığı ile;

• E-ticaret yapılabiliyor
• Bankacılık işlemleri gerçekleştirilebiliyor
• ERP / CRM uygulamaları web’den hizmet verebiliyor
• Arama motorları aracılığı ile derinlemesine bilgi edinilebiliyor
• Sosyalleşilebiliyor
• Devletler ve kamu kurumlarıyla ilintili resmi işler halledilebiliyor

ve daha bir çok şey.

Haliyle artık web uygulamaları, tek yönlü statik bir iletişimden ziyade çift yönlü ve kullanıcı etkileşimli dinamik bir yapıda, bir çok kritik bilgiyi işleyen, saklayan ve sunan çetrefilli bir hâl alır oldular.

Git gide karmaşıklaşan web uygulamaları, etkileşim sunmak için artık kullanıcılardan daha çok girdi almaya başladı ve en temel güvenlik problemiyle karşı karşıya kaldı; “Arbitrary Input”. Yani beklenenden daha farklı değerler uygulamaya gönderilmeye başlandı ve uygulama arka planda bunları kontrol etmediği için de (Input Validation) nur topu gibi güvenlik riskleri dünyaya geldi.

Bu güvenlik riskleri ile beraber uygulamaya yönelik saldırı yüzeyinin genişlemesi, uygulamanın sakladığı bilgilerin kritiklik seviyesine göre güvenliği zorunlu bir hale getirdi.

Web Uygulamalarına Yönelik Saldırıların Boyutları

Web uygulamalarının işlevi; bulunduğu sektör ve hizmet ettiği amaca bağlı olarak değişmektedir. Bir e-ticaret uygulamasında ürün pazarlaması ve satışı yapılırken, sağlık sektörüne ait bir web uygulamasında ise hayati önem taşıyan bilgiler bulunabilmektedir.

Web uygulamasının konseptine göre de saldırıların boyutları ve açacağı zararlar şekillenmektedir. Bu zararları şu şekilde kategorize edebiliriz;

• Maddi zararlar,
• Manevi zararlar (prestij kaybı, olumsuz görüşlerin oluşması, güven kaybı)
• Kritik bilgilerin çalınması ve değiştirilmesi

Aşağıdaki grafikten sektörlere göre web uygulamalarındaki acil, kritik ve yüksek seviyedeki zafiyetlerin oranlarını görebilirsiniz.

Acil, kritik veya yüksek derecede güvenlik açığı bulunan web siteleri endüstri sektörlerine göre yüzdesel olarak sıralanmıştır.

Web Uygulama Güvenlik Tarayıcıları ve Netsparker

Web uygulamalarında güvenliğin neden önemli olduğuna dair kanaat hasıl olduktan sonra, güvenliğin nasıl sağlanacağı hala önümüzde bir problem olarak duruyor. Peki bu problemi nasıl çözeceğiz?

Öncelikle güvenliğin bir sonuç değil, süreç olduğunu ve bu sürecin çeşitli adımlardan oluştuğunu bilmek gerekiyor. Bu süreçte zafiyetlere neden olan etkenlere baktığımız zaman;

• Yetersiz güvenlik farkındalığı
• Basit özelliklerin güvenlik riski doğurmayacağı düşüncesi
• Hızla gelişen saldırı vektörleri ve yeni oluşan tehditler
• Kaynak / Zaman ikilemi

faktörlerinin ön plana çıktığını görüyoruz. Bu faktörleri güvenlik sürecinde ilgili noktalarla eşleştirdiğimiz zaman, bu sürecin birkaç parçaya ayrılabildiğini ve sorumluluk sahibi farklı kişilerin olması gerektiğini görüyoruz.

İşte Netsparker burada devreye girerek, web uygulamalarına yönelik yapılacak güvenlik testlerini çok büyük bir oranda otomatize ederek, iş yükünü azaltacak ve personel istihdamını belki de ortadan kaldıracaktır. Peki otomasyon neden gerekli?

Güvenlik Testlerini Neden Otomatize Etmeliyiz?

Özellikle web uygulaması güvenliği ve sızma testi alanındaki vasıflı personel olmak üzere insanların geneli iş süreçlerine dahil olduklarında herkesin sırtına belli bir yük biner. Web uygulamalarına yönelik sızma testleri yaparken şu işlemler sırasında bir hayli kaynak ve beceri ihtiyacı ortaya çıkar:

• Projeyi detaylandırma
• Bilgi toplama
• Web zafiyetlerini tarama
• Zafiyet tespit etme ve doğrulama
• Raporlama
• Riskleri önleme ve hafifletme

Bu faktörler, neredeyse tüm kurumlarda geçerli olmak üzere bazı insanların sürece dahil edilmesi manasına gelir. Söz konusu insanlar geliştiriciler, QA analistleri, proje yöneticileri, ağ yöneticileri, web uygulama geliştiricileri, bilgi güvenliği yöneticileri, denetçiler ve yöneticilerdir. Hatta üçüncü parti yazılım sağlayıcıları dahi web güvenlik projelerinde yerlerini alırlar. Yüksek maliyetlere sebep olan böyle bir ekiple ortak bir hedef için çalışan her işletme, karışıklıktan ve maliyetin artmasından kaçınmak için mümkün olduğunca otomatikleştirilmiş süreçlere başvurmak zorundadır.

“Neden?” diye sorabilirsiniz. Neden otomasyon bu kadar önemli? Her durum farklı olsa da bazı ortak noktalar bulunabilir. Öncelikle, gereksiz testler yapıldığında bu testler, fazladan çaba sarf etme riskini de beraberinde getirir. Günümüzdeki çevrimiçi işletmelerin çoğunun kullandığı sayısız karmaşık web uygulamalarına sahip olmanız kayda değer miktarda gereksiz efora sebep olabilir. Bir diğer sorun ise yönetimin, tüm web uygulamalarının mütemadiyen manuel olarak web zafiyeti taramasından geçirilmesi için yeterli bilginin olup olmadığını tam olarak anlayamamasıdır. Şayet web uygulaması güvenliği testleri, kısa sürede güvenlik açığını tespit edebildiği kanıtlanmış bir web güvenlik tarayıcısı ile otomatize edilmemişse, hepsi olmasa bile bazı ciddi güvenlik problemleri gözden kaçabilir. Görünürde sıradan IT projeleri olan web uygulamalarının güvenlik testleri, ciddi bir iş yüküne dönüşür.

Örneğin, web tabanlı bir kurumsal kaynak planlama (ERP - Enterprise Resource Planning) sistemi düşünelim. Bu gibi sistemler, binlerce olmasa da yüzlerce girdi noktasına dolayısıyla saldırı yüzeyine kısacası SQL Injection ve Cross Site Scripting gibi zafiyetlerin bulunabildiği kontrol edilmesi gereken birçok hassas noktaya sahiptir.

Gerçek hayattan örnek verecek olursak, 100 farklı web uygulama zafiyeti için kontrol edilmesi gereken 200 girdi noktasına sahip bir ERP düşünelim. Bu sayılar, bir pentester’ın en az 20 bin test yapması gerektiği manasını taşır. Her test 5 dakika sürmüş olsa, ERP sistemi için yapılan söz konusu web uygulaması güvenliği denetimi, web güvenlik uzmanının 208 gününü alacaktır.

Teorik ve yuvarlak olarak bahsettiğimiz bu sayıları somut örnekler üzerinden inceleyerek durumu daha da netleştirelim.

SQL Injection Örneği

Hata mesajlarını görememek bir saldırganın başına gelebilecek en kötü şeylerden biridir ve artık aklı başında hiç bir site hata mesajlarını göstermiyor. Bu mesajlara erişemeden bir sistemin güvenliğini test etmek, bu mesajlara erişerek ve sistemin alt yapısını izleme imkanına sahip olarak (white-box testing) test etmekten çok daha farklı bir iş.

Bir parametreye tek tırnak koyduğunuzda bir SQL Injection hatası almıyorsanız bu o sitenin güvenli olduğu anlamına gelmez. Tam anlamı ile bir SQL Injection açıklığını tespit etmek istersek, şu saldırıları denemeliyiz:

• Filtre geçmek: 2 tip saldırı (Mesela boşluk kabul edilmiyorsa tüm istekleri bir de boşlukları "/**/" ile değiştirerek göndermek gerekli)
• SQL cümleciklerini önceden bitirmek için: 2 tip saldırı (mesela "--" ve "")
• Gruplama içeren SQL Cümlecikleri için: 4 tip saldırı (mesela: "",")"," ))"," )))" gibi... )
• String, Integer, AND / OR vs. kombinasyonları: 2 tip
• Injection yerine göre: 3 tip (GET, POST, COOKIE)

Sonuç: 2 * 2 * 4 * 2 * 3 = 96 HTTP isteği.

Bunun anlamı sitedeki her dinamik girdi alanı için 96 farklı deneme yapmazsanız sistemi gerçekten yeterli şekilde test ettiğinizden emin olamazsınız, demek. Ortalama bir sitede 50 dinamik parametre görebilirsiniz, eğer karşıdaki veri tabanını da bilmiyorsanız, diğer veri tabanlarına uygun da denemeler yapmanız lazım, yani 96 * 3 * 50 = 14.400 istek. Teorik olarak hala mükemmel bir SQL Injection testi yapamadınız, hala acayip ve tuhaf olasılıklar var; mesela farklı bir sistemde sizin girdiniz ile her akşam çalışan bir SQL sorgusunda SQL Injection varsa?

Netsparker’ın SQL Injection zafiyetini tespit etmek için yaptığı atakların sadece bir kısmı

Unutmamak lazım 15.000 istekten sonra hala çözmemiz gereken başka dertler var; XSS var, CSRF var, LFI var, RFI var ve daha bir çok başka abuk subuk kısaltması olan ve bulunması gereken güvenlik açığı var.

Mantıklı bir güvenlik uzmanı gidip eliyle 15.000 deneme yapmaz, genelde onun yerine açık olabilecek yerlere belli olasılıklar ile odaklanır ve HTTP cevaplarını en verimli şekilde analiz edip ona göre oralarda en çok bulunma olasılığı olan açıkları dener.

XSS, RFI, LFI gibi diğer açıklar da SQL Injection testleri kadar olmasa da çok sayıda deneme gerektiriyor.

Yeni Çıkan Güvenlik Açıkları

Ya da SSL kullanan, farklı sunucu ve lokasyonlardan yönettiğiniz 100 adet websiteniz olduğunu düşünün? Veya güvenlik danışmanlığı hizmeti verdiğiniz onlarca web sitesinde Heartbleed zafiyetinin olup olmadığını kontrol etmek istiyorsunuz?

İşte burada yine otomasyonun nimetleri devreye giriyor ve Netsparker’a liste halinde web sitelerinizi verip dakikalar içerisinde sonuçları alıyorsunuz.

Sonuç

Web güvenliğinde otomatik olarak tespit edilemeyecek açıklar var -en azından yapay zeka sistemleri gelişene kadar-, ama onun harici otomatik olarak tespit edilebilecek de bir çok ciddi güvenlik açığı ve sorun var. Güvenlik testlerinin otomatikleştirilebilecek kısımları otomatikleştirilmeli ve güvenlik uzmanları da değerli vakit ve enerjilerini daha çok otomatik olarak tespit edilemeyecek açıkları tespit etmek için kullanmalılar.