Category: Türkçe

Date:

Hacker Geçen cumartesi İnternet Teknolojileri Derneği‘nin Leventteki IBM Linux binasında düzenlediği Web Uygulama Güvenliği adlı seminere katıldım. Semineri veren kişi olan Fırat Okay, uzun bir süre yazılımcılıkla uğraştıktan sonra bu işin çok yorucu(hata ayıklama, güncelleme, paket yapma vs) olduğunu düşündüğü için güvenlik alanına yönelmiş ve bir arkadaşıyla bir güvenlik firması kurmuşlar. Fırat Bey, şimdi de yarı zamanlı olarak burada çalışıp kalan vaktinde güvenlik eğitimleri veriyormuş.

Seminer benim için çok faydalı oldu. Öncelikle hiçbir sistemin güvenli olmadığını öğrendim. Öyle ki konuşmacının sorduğu "En güvenli sistem hangisidir?" sorusu karşısında verdiğim cevap olan "Olmayan sistemdir" doğru çıktı :) Şimdi sizlere seminerin bir özetini vereceğim...

GÜVENLİK

Öncelikle güvenlik sadece gizlilik değildir. Bazıları kullandıkları sistemlerin SSL ile gizli olmasını sağlayıp geri kalan kısmı güvenlikten saymıyorlar. Halbuki güvenlik üç kısımdan oluşuyor(CIA):

  • Confidentality(Gizlilik)
  • Integrity(Bütünlük)
  • Availability(Erişilebilirlik)

Siz her ne kadar verilerinizi korusanız da verilerinizi görmeden onları yok edebilecekler çıkabilir. Olmadı, verilerinizi ulaşılamaz hale getirebilirler. Bu durumlara karşı çoğu uygulamada önlem alınmıyor.

Güvenli bir uygulama geliştirmek için güvenliği daha uygulamanın nasıl olacağını tartışırken konuşmak gerekir. Uygulama bittikten sonra ona sıkıştırılan güvenlik önlemlerinin hiçbir faydası yoktur. Bu tartışma aşamasında sisteme "Kim, neden, ne elde etmek için, nasıl saldırır?" sorularını sormalı ve bu sorulara verilecek cevaplara göre güvenlik önlemleri alınmalıdır.

Bir sistemin karşı karşıya olduğu tehlikeleri oluşturan öğeler ise şunlardır:

Tehdit(Threats): Bir saldırının olma sıklığı
Açık(Vulnerabilities): Sistemde bulunan açıklar

Güdü(Motivation): Saldırganların saldırma güdüleri

Saldırı(Attacks): Saldırmanın etkileri

Çeşitli saldırı yöntemleri vardır ve bunlardan en seçkin olanları birkaç yılda bir owasp.org adresinde ilan ediliyor. Bu saldırı yöntemlerinden korunmak için tavsiye edilebilecek bir kitap ise Michael Howardın yazdığı "Writing Secure Code 2nd Edition".

Güvenlik Çözümlemesi(Analizi) yaparken göz önünde bulundurulması gereken etmenler ise şunlar:

STRIDE

  1. Spoofing Identity: Kendini başkası gibi göstermek
  2. Tampering with Data: Sunucuya giden / sunucudaki verileri değiştirmek ve böylece sahte ve yasak isteklerde bulunmak
  3. Repudiation: Yaptığını inkar etmek. Saldırıyı ispatlayamama durumu var. Kayıtlar(log) var mı?
  4. Information Disclosure: Bilgilerin açığa çıkmasıdır. Bu durumu önlemek için SSL kullanılır.
  5. Denial of Service: Sistemin bir kısmının veya tamamının, bir kullanıcıya veya herkese ulaşılamaz hale gelmesi
  6. Elevation of Privilege: Farklı bir kulanıcı hesabını ele geçirerek yetkileri yükseltmek.

Sisteminize yönelik tehditleri öbekleyip sonra her bir öbeği kendi içerisinde sıralamalıyız ve risk çözümlemesi yapmalıyız. Bunun için olasılıktan yararlanılan hesap yöntemleri mevcut. Örneğin DREAD.

KİMLİK DOĞRULAMA

Eğer sisteminizde en az iki etmenli kimlik doğrulaması yapıyorsanız, uygulamanız kimlik doğrulaması açısından "güvenli bir uygulama" olarak nitelendirilebilir. Nedir bu etmenler?

Bildiğiniz bir şey: kullanıcı adı, parola
Sahip olduğunuz bir şey: akıllı kart, USB token, OTP
Olduğunuz bir şey: parmak izi, el izi, retina taraması, davranış tarzı(bu pek tutulmadı)
Bununla birlikte,

  1. Sistemde öntanımlı hesapların (admin vs) bulunması,
  2. Tahmin edilebilir kullanıcı adları kullanılması(örn: banka müşteri numarası)
  3. Zayıf parola sorunları
  4. Parolaların veritabanında açık(şifrelenmeden) olarak saklanması
  5. Parolalara uygulanan şifreleme yöntemlerinin ters çevrilebilir(reversible) olması.
  6. Kaba Kuvvet Saldırısı (Brute Force Attack)

gibi zayıflıklar bir sistemin güvenliğini büyük ölçüde azaltmaktadır. Bu halde yukarıdaki zayıflıkların giderilmesi büyük önem arzetmektedir. İlk 5 sorun kolaylıkla giderilebilir ancak Kaba Kuvvet Saldırısını engellemek için daha değişik bir yöntem izlemeliyiz. Bu ise aşamalı gecikme yöntemidir. Bu yönteme göre parola yanlış girildiği zaman bir dahaki parola girişine her yanlış girişte daha fazla bekletmek koşuluyla (3 saniye sonra, bir daha yanlış girerse 15 sn sonra, 30, 60 ... şeklinde artan zaman aralıklarıyla) müsaade edilirse bu saldırı da engellenebilir

VERİ GİRİŞ DOĞRULAMASI

Bir saldırganın saldırı yöntemi sadece kullanıcı girişi yapmaktan ibaret değildir. Arama motorunda yapılacak sorgunun içinde bazı yasak karakterleri kullanarak birçok zararlı etkinlikte bulunabilir(SQL Injection). Bu yüzden her türlü veri girişinde(kullanıcı girişi, arama girişi vs) verinin tipi, biçimi ve uzunluğu hem istemci(tarayıcı) hem de sunucu tarafında denetlenmelidir. Çünkü istemci tarafındaki javascript denetlemeleri rahatlıkla aşılabilir. Bununla birlikte fazladan güvenlik önlemi olarak

Web Sunucusu - Uygulama - Veritabanı Sunucusunun her birisinin arasında bu denetlemeleri yapabilirsiniz.

SQL Injectionda kullanılan bazı yasak karakterler şunlardır:
NULL(zero) %00
LF -chr(10) - "r"
CR -chr(13) - "n"
CRLF - "nr"
Tırnak - " ‘
,/;&><

Örneğin bir sistemin SQL sorgusu şu olsun:

strSQL="SELECT * FROM users WHERE user_name LIKE ‘%"+keyword+"%';";

Kullanıcı burada keyword kısmına a% AND password=abcd';- girdiği zaman SQL sorgusunun son hali şu olmakta:

strSQL="SELECT * FROM users WHERE user_name LIKE ‘%a% AND password=abcd';-%';";

Yani kullanıcı adında a harfi geçen ve parolası abcd olan tüm kullanıcıları seçebiliyor.

Başka bir örnek, "SELECT * FROM accounts WHERE account_no='"+keyword+"‘;"; sorgusunda anahtar kelime olarak ‘101 AND first_name LIKE ‘J%- dediğimizde hesap numarası 101 olan kişinin isminin J ile başlayıp başlamadığını öğrendik... En sondaki — ise, asıl sorgudaki geri kalan karakterlerin yorum olarak algılanmasını sağlıyor.

Sonuç olarak tüm bu SQL Sızmalarını engellemek için sisteme yapılan tüm girişlerin denetlenmesi, yasak karakterlerin ayıklanması(encode) gerekiyor.

OTURUM YÖNETİMİ

Oturum yönetiminin güvenliğinde karşılaşılan bazı sıkıntılar ise şöyle sıralanabilir:

  1. Tahmin edilebilir oturum değişkeni (session ID) oluşturulması.
  2. Sabit oturum değişkeni sağlanması.
  3. Oturum değişkenlerinin çok kullanımlık, uzun süreli olması
  4. Oturum değişkeninin istemci bilgisayarında bir dosya içinde saklanması.

Avustralyadaki bir kurumda oturum değişkeni sabit(static) olarak verildiği için bu değişken kullanılarak başkalarının sisteme sızması gündeme gelmiş. Oturum değişkeni bilindikten sonra eğer bu değişken çerez(cookie) vasıtasıyla saklanmışsa;

  1. Sisteme kendi kullanıcınla giriş yap
  2. Kendi çerez dosyanı aç
  3. İçindeki değişkeni kurbanın değişkeniyle değiştir.
  4. Yoluna devam et.

Eğer oturum değişkeni URL yoluyla saklanıyorsa, giriş yaptıktan sonra URLdeki değişkeni değiştirip yeni adrese gitmek yeterli. Bu iki yöntemde uygulanan başkasının yerine geçme olayına: XSS(çarpraz betik oturumu) deniyor. Bu çalma işlemi ise trojan vs vasıtasıyla olabildiği gibi javascript ile de yapılabiliyor. Örneğin bir zamanlar mevcut olan bir açık hadisesi:
Saldırgan, internet bankacılığını kullanarak rastgele bir hesap numarasına 1YTLlik havale yapar. Açıklama kısmına ise:

Ancak bu kadarını ödeyebiliyorum abi

yazıyor. Böylece kurban açıklamayı gördüğü anda çerez bilgileri saldırganın sitesindeki php dosyasına gönderiliyor, o dosya da bunu saldırgana sunuyor. Daha sonra saldırgan kendi oturum değişkenini bu değişkenle değiştirip kurbanın yerine geçmiş oluyor. Gördüğünüz üzere burada bir sosyal mühendislik kullanılmış durumda. Sosyal mühendislik olmadan XSSin çok da tehlikeli olmadığını söylüyorlar.

Tüm bu durumları engellemek için otomatik oturum oluşturma sistemi benimsenmeli. Her oturum değişkeni tek kullanımlık(dolayısıyla değişken) ve kısa süreli olmalı. Ayrıca javascript ile oturum değişkeni çalınmasını engellemek için de Veri Giriş Doğrulaması yapılmalı.

XSSe benzeyen, yeni yeni kullanılmaya başlanan bir yöntem ise CSRF. Bu yöntemde saldırganın belirlediği bir oturum değişkeni, (kurbanı sahte bir siteye yönlendirme yoluyla) kurbanın oturum değişkeni yapılıyor. Böylece kurban giriş yaptıktan sonra kurbanın oturum değişkenini bilen saldırgan onun yerine her türlü işlemi yapabiliyor. Bunu engellemek için de bir oturum deği��keninin birden fazla IP adresinde kullanılamaması sağlanabilir.

Yine benzer bir durum ise: Saldırgan kendi hesap numarasının bir eksiğine havale yapmak istiyor, numarayı yazıp ileri tuşuna basınca alıcının adı, soyadı, müşteri numarası gibi bilgileri gözüküyor. Bu bilgileri öğrenen saldırgan phishing(sahte e-posta veya telefon ile) ile kullanıcının parolasını talep edebiliyor. Kendisine ismiyle, müşteri ve hesap numarasıyla hitap edildiğini gören kurban ise bu tuzağa düşebiliyor. Aman dikkat!

GÜVENLİK DUVARI

Web Uygulamaları Güvenlik Duvarı(Firewall) tarafından korunamazlar. Çünkü güvenlik duvarı sadece 80 dışındaki portları kapatır. Web Uygulaması ise 80 portunda çalıştığı için güvenlik duvarının işlevi sadece telnet,ssh ve ftp üzerinden yapılacak saldırıları önlemek olur. Uygulamanın güvenliğini sağlamak için zararlı istekleri reddeden Web Uygulama Güvenlik Duvarı kullanılmalıdır. Ancak SSL kullanıldığı takdirde bu duvar şifreli verileri anlayamayacağı için yine etkisiz kalacaktır.Ayrıca saldırganlar çoğu zaman bazı işler için web tarayıcı kullanmaktansa bu işler için özel olarak yapılmış olan araçları kullanırlar. Bu araçlar HTTP Taleplerini(Request) saldırganın isteğine göre(manuel) yerine getirmektedirler. Dolayısıyla bu tür durumlara karşı da önlem almak gerekir.

En sık rastlanan güvenlik açıklarını denemek için önerilen bir yazılım ise Webgoat. Bu bir web uygulaması. Yerel sunucunuzda çalıştırıp çeşitli saldırı denemeleri yapabilirsiniz.

KABLOSUZ AĞLAR
Kablosuz ağlar konusunda bahsedilmesi gerek bir nokta ise şifreleme olarak bilinen WEP(Wired equivalent privacy) çok da güvenli olmadığı. Adı üzerinde sadece kablolu bağlantıya denk bir güvenlik sağlıyor. WEP ile korunan bir ağın yeterince süre dinlenmesi ile şifresi rahatlıkla kırılabilir. Bu yüzden WPA kullanmak güvenlik açısından çok daha iyi.


Share: FacebookGoogle+Email


comments powered by Disqus