Visual C# 2008

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace Proje1

{

class Program

{

static void Main(string[] args)

{

Console.WriteLine(“msdundar”);

Console.Write(“To continue press any key”);

Console.ReadKey();

}

}

}

F5 veya Start Debugging ile derletip sonucu konsoldan görebiliriz.

Şimdi  öyle  bir  ayarlama  yapacağım  ki  bu uygulama çalıştırıldığı zaman ekrana bir pencerenin gelmesini sağlayacağım.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace Proje1

{

class Program

{

static void Main(string[] args)

{

System.Windows.Forms.Form Form1;

Form1 = new System.Windows.Forms.Form();

Form1.Text = “MSDundar”;

System.Windows.Forms.Application.Run(Form1);

}

}

}

Bu kodu dikkatlice  incelerseniz using deyimiyle System.Windows.Forms adlı  namespace’deki  Class’lardan  yararlanılmak  istendiği  belirtilmiş.  Aynı satırı sizler yazmaya kalkışırsanız hata meydana gelir. Çünkü bu Namespace .NET  Framework  ile  gelen  System.Windows.Forms.dll  adlı  DLL dosyasında  yani  referansta  yer  almaktadır.  .NET  Framework’e  ait  klasöre baktığınızda bu dosyayı görebilirsiniz.

Konsol  uygulamaları  dahilinde  ekrana  pencere  getirmek  için  bu  DLL dosyasının konsol uygulamasına dahil edilmesi gerekiyor. Başka bir deyişle Express Edition’ın bu referans hakkında bilgilendirilmesi gerekir. Bunun  için Express Edition penceresi içinde yer alan Solution Explorer penceresinden yararlanıp  Add  Reference  diyalog  kutusunu  ekrana  getirip System.Windows.Forms.dll referansını uygulamaya dahil etmelisiniz.

Her  ne  kadar  burada  referansın uygulamaya  dahil  edildiğinden  söz  edilse  bile  gerçek  tam  böyle  değildir. Yapılan,  Express  Edition’ın  dolayısıyla  C#  derleyicisinin  bu  referanstan yararlanılmak istendiği konusunda haberdar edilmesinden ibarettir.

Yukarıda  verilen  kodun  üzerinde  biraz  duralım.  Main() metoduna  yazdığım  bu  satırların  ilkinde  “Form1”  adında  ve System.Windows.Forms  adlı  Namespace’teki  Form  sınıfı  tipinde  bir değişken  tanımlanmaktadır. Devamında  new  anahtar  kelimesi  ile  Form sınıfının  örneğini  alıp (yani  nesne  hazırlayıp)  referansını  Form1  adını verdiğim değişkene aktardım. En son olarak bu Form nesnesini Application sınıfının Run() metoduna parametre olarak verdim. Dikkat ederseniz burada tanımladığım  değişkene  Form1  adını  verdim.

En az satır sayısına sahip, en basit C# kodu :

class Deneme

{

static void Main(string[] args)

{

}

}

Main() metoduna program içinde mutlaka yer vermeliyiz.

En az satıra sahip bu C# programındaki Main() metodunun hem static hem de  void  olduğunu  işaret  ettim.  C#  programlarının  başlangıç  noktası  olan Main() metodu(C  programlama  dilinde Main’den  fonksiyon  diye  söz  edilir) statik olmak zorundadır ama void olması zorunlu değildir. Metot geriye bir değer  göndermeyecekse  metot  adından  önce  void  yazılır.

Main() metodunun adından sonra parantezlerin arasına  “string[]  args”  yazdım.  Bu parantezin  içine  yazdıklarım  gerçekte dizi değişken  tanımlamaktan başka bir  şey değildir. Main  metodu  içinde tanımlanan  dizi  değişkene  “args”  adını  vermek  C#  programcılarının  bir alışkanlığıdır.

Şimdi  yukarıda  verdiğim  C#  programının  başlangıç  noktası  olan  Main() metodu  içinde  bir  değişkene  yer  vereceğim.  Bu  değişkeni  Main() metodu içinde tanımladım. Değişkeni Main() metodu tarafından sınırlanan kod bloğu yerine Class bloğu içinde tanımlayabilirdim.

class Deneme

{

static void Main(string[] args)

{

int yil;

}

}

Gördüğünüz  gibi  C#  programlarında  değişken  tanımlanırken  önce değişkenin  tipi sonra adı yazılmaktadır. Buradaki  int bu değişkenin  integer yani  tamsayı  tipindeki  bilgileri  saklayabileceğini  işaret  etmektedir.

Main() metodu  içinde yaşayabilecek  “yil” adında ve  Integer tipindeki bilgilerin aktarılabileceği bir değişken tanımlanmıştır. Bu değişkeni Main() metodu  içinde  tanımladığım için yalnızca Main() metodunun sınırları içinde  yaşar.  Fark  etmiş  olabileceğiniz  gibi  C#  programlarında  Class  ve metot başlatılan satırlar hariç her satırın sonuna “;” konulmaktadır.

Şimdi yukarıda verdiğim basit C# kod dosyası içinde Mesaj() adını verdiğim

metodu  Main()  metodunun  içinden  işleteceğim.  Hazırladığım  metot  aynı

sınıfın içinde olduğu için herhangi bir hazırlık yapmadan direk adıyla çağırıp

işletmek mümkündür.

class Deneme

{

static void Main(string[] args)

{

int yil;

Mesaj();

}

static void Mesaj()

{

}

}

Bu  programı  aşağıdaki  gibi  düzenlemiş  olsaydım  değişen  bir  şey  olmazdı.

Çünkü  C#  derleyicisi Main() metodunu  bulup  programın  başlangıç  noktası

yapar. Bu kısa örnekte “yil” adını verdiğim değişkeni hiç kullanmadığım için

C# derleyicisi derleme sırasında uyarı mesajı verir.

class Deneme

{

static void Mesaj()

{

}

static void Main(string[] args)

{

int yil;

Mesaj();

System.Console.WriteLine(“MSDundar”);

}

}

Konsolda  yani  DOS  penceresinde çalışan  C#  projelerinde  ekrana  bilgi  yazma  işlemleri  .NET  Framework  ile gelen Console sınıfında tanımlı olan Write() veya WriteLine() metotları ile yapılmaktadır.

Bu  şekilde  düzenlenen  C#  uygulaması  DOS  penceresinde  derlenip çalıştırıldığında  ekrana  “MSDundar”  yazdırıldıktan  sonra  programın çalışması sona erer. Çünkü C# ile geliştirilmiş programların çalışması Main() metodunun sonuna gelindiğinde biter.

Mesaj()  metoduna  yazdığım  satır  hakkında  biraz  konuşmak  gerekirse; “System.Console.WriteLine(“MSDundar “);”  satırındaki  System  bir namespace’tir.

Kısaca  anlatmak  gerekirse  Class’lar  Namespace’lerin  içine yerleştirilmektedir.  System  adlı  Namespace  .NET  Framework  ile  gelen  en önemli  Namespace’tir  ve  çok  sayıda  Class’ı  barındırmaktadır.  DOS penceresine veya konsola bilgi yazmak üzere hazırladığım satırdaki Console bir Class’tır. Çok sayıda metoda sahip olan bu Class’ın sayesinde konsol yani DOS  penceresi  ile  ilgili  istenen  işlemler  yapılabilmektedir.  Bu  satırdaki WriteLine() ise Console sınıfının bir metodudur.

Hazırlayıp  derlediğim  C#  programı  ekrana  bu  bilgiyi  yazdıktan  sonra  yani Main()  metodunun  sonuna  gelindiğinde  çalışması  otomatik  olarak  sona erer. Şimdi  bu  örmekte  öyle  bir  ayarlama  yapalım  ki  programın  veya  exe dosyanın  çalışması  Enter  tuşuna  basıncaya  kadar  devam  etsin.  Programın çalışmasının Enter tuşuna basıncaya kadar devam etmesini sağlamak üzere Deneme adını verdiğim Class’ın Main() metoduna bazı eklemeler yaptım.

class Deneme

{

static void Main(string[] args)

{

int yil;

Mesaj();

System.Console.WriteLine();

System.Console.Write(“Cıkmak için entera basın”);

System.Console.Read();

}

static void Mesaj()

{

System.Console.WriteLine(“MSDundar”);

}

}

Gördüğünüz  gibi  Console  sınıfının  WriteLine()  metodunu  Mesaj()  adını verdiğim  metodun  içinden  başka  bir  deyişle  Main()  metodunun  içinde kullandım.  Bu  örnekte  Main() metodu  içinde  önce  Mesaj()  adını  verdiğim metot  çağrıldığı  için  ekrana  önce  “MSDundar”  yazılır.  Mesaj() metodunun  çağrıldığı  satırdan  sonra  yine  WriteLine()  metodu kullanılmaktadır. Bu kez WriteLine() metoduna ekrana yazılmak üzere bilgi parametre  olarak  verilmediği  için  ekranın  o  satırı  boş  kalır.  Bir  sonraki satırda ise WriteLine() yerine Write() metodunu kullandım.  WriteLine() metodu  kendisine  parametre  olarak  verilen  bilgiyi  ekrana  yani DOS  penceresine  yazdıktan  sonra  imleci  bir  sonraki  satırın  başına  alır. Write() metodu  ise WriteLine() metodundan  farklı olarak  imleci bir  sonraki satırın  başına  almaz.  Burada  programın  çalışmasının  kendiliğinden  sona

ermesini engelleyen metot ise Read().

Console  sınıfının  Read()  metodu  gerçekte  kullanıcının  gireceği  bilgileri programa  veya  bir  değişkene  aktarılırken  işlevsel  olmaktadır.  Bu  örnekte kullanıcının  bilgi  girmesini  istemediğim  için  Console  sınıfının  Read() metodundan  önce  herhangi  bir  değişken  adı  yazmadım.  Diğer  yandan yukarıda  verdiğim  örnekte  asıl  anlatmak  istediğim  şuydu:  C#  programları Class’lar  şeklinde  hazırlanmakta  ve  Class’larda  işlem  yapan  kod  blokları

metot şeklinde düzenlenmektedir.

Bu  düşünce  ile  hazırladığım  kısacık  örnekte  Main()  metodundan  başka Mesaj() adında bir metot hazırlayıp Main() metodu dahilinde işlettim.

Şimdi bu  örnekte  değişiklik  yapıp  Mesaj()  adını  verdiğim  metodu  silip  çalışma

anında “yil” adını verdiğim değişkene bilgi aktarmaya çalışacağım.

class Deneme

{

static void Main(string[] args)

{

int yil;

System.Console.Write(“Hangi Yildayiz?”);

yil = System.Console.Read();

}

}

Bu  şekilde  değiştirdiğim  C#  programında  önce  Console  sınıfının  Write() metodu  ile  kullanıcıya  mesaj  verdikten  sonra  bir  sonraki  satırda  Read() metodu sayesinde kullanıcıdan  istenen bilgiyi “yil” adını verdiğim değişkene aktardım.  Aşağıda  verdiğim  ekran  görüntüsünü  bu  kısa  programı  derleyip çalıştırdıktan sonra aldım.

Ekrana mesaj yazarken Write() yerine WriteLine() metodunu kullansaydım imleç  bilgi  girişi  için  bir  sonraki  satırda  beklerdi. Şimdi  bu C#  programına ekleme yapıp kullanıcıdan  istenip  “yıl” adını verdiğim değişkenine aktarılan bilgiyi WriteLine() metodu ile tekrar ekrana yazacağım.

class Deneme

{

static void Main(string[] args)

{

int yil;

System.Console.Write(“Hangi Yildayiz?”);

yil = System.Console.Read();

System.Console.WriteLine();

System.Console.Write(“Girdiginiz Yil:”);

System.Console.Write(yil);

}

}

Yukarıda verilen koda dikkat ederseniz konsoldan bilgi okuma işlemi Read() metodu  ile  yapılmaktadır.  Read()  metodu  konsoldan  okuma  yaparken girilen  bilginin  ilk  karakterinin  ASCII  kodunu  geriye  göndermektedir.  Bu program  derlenip  çalıştırılıp  “Hangi  Yıldayız  :”  sorusuna  “A”  ile  cevap verilirse ekrana 65 yazılır. Çünkü “A” hafinin ASCII kodu 65’dir.

Console  sınıfının ReadLine() metodu  ise  farklı bir  şekilde  çalışmaktadır ve konsoldan  yani DOS  penceresinden okuduğu bilginin String  tipte olduğunu varsaymaktadır.  Bu  nedenle  yukarıda  verdiğimde  örnekte  değişiklik  yapıp okuma işlemini Read() yerine ReadLine() metodu ile yapmaya çalıştım.

class Deneme

{

static void Main(string[] args)

{

string yil;

System.Console.Write(“Hangi Yildayiz?”);

yil = System.Console.ReadLine();

System.Console.WriteLine();

System.Console.Write(“Girdigin Yil:”);

System.Console.Write(yil);

}

}

Şimdi bu örnekte değişiklik yapıp kullanıcıdan 2 sayısal bilgi  isteyip bunları birbirleri  ile  çarptıktan  sonra  sonucu  ekrana  yani  konsola  yazacağım.  Bu amaçla  önce  2  string  değişken  tanımlayıp  Console  sınıfının  ReadLine() metodu ile okunan bilgileri bu değişkenlere aktardım.

class Deneme

{

static void Main(string[] args)

{

string rakam1;

string rakam2;

System.Console.Write(“İlk sayıyı girin :”);

rakam1 = System.Console.ReadLine();

System.Console.Write(“İkinci sayıyı girin :”);

rakam2 = System.Console.ReadLine();

}

}

Bu program bu hali ile kaydedilip çalıştırılırsa konsoldan girilen bilgiler string değişkenlere  aktarılır.  Bu  örnekteki  amacımız  kullanıcının  sayısal  bilgi girmesini  ve  bu  sayıları  birbiri  ile  çarpıp  ekrana  yazmak  olduğu  için matematiksel  işlem  öncesi  String  değişkenlerin  içeriğini  int  tipindeki değişkenlere aktarmak gerekir. Bu amaçla bu C# programına ekleme yapıp int tipinde 2 değişken tanımladım. Ardından string değişkenlerin içeriklerini dönüştürüp int tipindeki bu değişkenlere aktardım.

class Deneme

{

static void Main(string[] args)

{

string rakam1;

string rakam2;

int sayi1;

int sayi2;

System.Console.Write(“İlk sayıyı girin :”);

rakam1 = System.Console.ReadLine();

System.Console.Write(“İkinci sayıyı girin :”);

rakam2 = System.Console.ReadLine();

sayi1 = System.Int16.Parse(rakam1);

sayi2 = System.Int16.Parse(rakam2);

}

}

Hemen  bir  hatırlatmada  bulunmak  isterim:Her  ne  kadar  bu  örnekte kullanıcıya “sayı girin” mesajı verilmiş olunsa bile kullanıcı konsoldan sayısal bilgi  yerine  karaktersel  bilgi  girerse  Parse()  metodu  dönüştürme yapamayacağı  için  hata  meydana  gelir.  Bu  tip  karşılaşılması  muhtemel hataların önüne geçmek  için hata kontrol blokları hazırlanabilir. (try-catch)

class Deneme

{

static void Main(string[] args)

{

string rakam1;

string rakam2;

int sayi1;

int sayi2;

int carpim;

System.Console.Write(“İlk sayıyı girin :”);

rakam1 = System.Console.ReadLine();

System.Console.Write(“İkinci sayıyı girin :”);

rakam2 = System.Console.ReadLine();

sayi1 = System.Int16.Parse(rakam1);

sayi2 = System.Int16.Parse(rakam2);

carpim = sayi1 * sayi2;

System.Console.WriteLine(carpim);

}

}

Çarpma  işlemi  sonucu  bulunan  değeri  Console  sınıfının  WriteLine() metodu sayesinde direk konsola yazmak mümkün olmasına rağmen amacım bazı  konuları  anlatmak  olduğu  için  üçüncü  bir  string  değişken  tanımlayıp çarpma  işlemi  sonucu  bulunan  değeri  dönüştürüp  bu  değişkene  aktardım. Bu işlemi nasıl yaptığımı aşağıda görebilirsiniz.

class Deneme

{

static void Main(string[] args)

{

string rakam1, rakam2, sonuc_str;

int sayi1, sayi2, sonuc;

System.Console.Write(“İlk sayıyı girin :”);

rakam1 = System.Console.ReadLine();

System.Console.Write(“İkinci sayıyı girin :”);

rakam2 = System.Console.ReadLine();

sayi1 = System.Int16.Parse(rakam1);

sayi2 = System.Int16.Parse(rakam2);

sonuc = sayi1 * sayi2;

sonuc_str = System.Convert.ToString(sonuc);

System.Console.WriteLine(“Sayilarin çarpımı :” + sonuc_str);

System.Console.Write(“Devam etmek için bir tuşa basın”);

System.Console.ReadKey();

}

}

Bu  şekilde  hazırlanan  C#  programı  DOS  ortamında  derlenip  çalıştırılırsa belirtilen  bilgi  Write()  metodu  sayesinde  DOS  penceresine  yani  konsola yazılır.  Bir  sonraki  satırda  kullanılan  ReadLine() metodu  sayesinde  enter tuşuna  basılıncaya  kadar  program  çalışmaya  devam  eder.  Bu  örnekte ReadLine()  yerine  Read()  metodu  kullanılsaydı  değişen  bir  şey  olmazdı. Tabii  bu  3  satırlık  kodda  ReadLine()  yerine  ReadKey()  metodunu kullanırsanız uygulamanın  çalışmasını  sona erdirmek  için herhangi bir  tuşa

basılabilir.

.NET Framework adı verilen sınıf kitaplığı ile gelen sınıfların Namespace adı verilen  yapılarda  saklandığını  biliyorsunuz.  C#  programlarında  kullanmak istediğiniz  Class  hangi  Namespace’in  içinde  yer  alıyorsa  o  namespace’ı using  deyimi  ile  programa  dahil  etmelisiniz  veya  yukarıda  yapıldığı  gibi içerdiği  sınıfları  kullanmak  istediğiniz  namespace’in  adını  metodun  önüne her seferinde yazmalısınız.

DOS penceresi  ile  ilgili Console sınıfı System adlı Namespace’te yer aldığı için  Write()  metodundan  önce  bu  sınıfın  yer  aldığı  Namespace’in  adını yazdım.  Söz  konusu  Namespace’teki  sınıfları  programınızda  çok  kez kullanıyorsanız her seferinde Namespace’in adını bu şekilde yazmak yerine aşağıda  yapıldığı  gibi  ilgili  Namespace’i  using  deyimi  ile  koda  dâhil edebilirsiniz.  using  deyimi  ile  olmayan  bir  namespace’i  C#  programınıza dahil  etmek  istemeniz  yani  olmayan  bir  namespace’in  kaynaklarından yararlanmak istemeniz halinde derleme sırasında hata meydana gelir.

using System;

Class Deneme

{

public static void Main()

{

Console.Write(“Efes Pilsen Basketbol Takımı”);

Console.ReadLine();

}

}

C#  programlarınızda  .NET  Framework  ile  gelen  Namespace’lerdeki  hazır sınıfları kullanmanın ötesinde kendi hazırladığınız class’ları bir Namespace’in içine  koymanız  gerekir.  Yukarıda  bunu  yapmamış  olmamıza  rağmen herhangi  bir  hata  meydana  gelmedi.  Çünkü  programcı  yazdıklarını  bir Namespace’e  yerleştirmediği  zaman  C#  derleyicisi  kendiliğinden  bir Namespace hazırlamaktadır. Şimdi yukarıda verdiğim programdaki “Deneme” adını verdiğim Class’ı bir Namespace’e dahil edeceğim.

using System;

namespace Serhat

{

class Deneme

{

public static void Main()

{

Console.Write(“Efes Pilsen Basketbol Takımı”);

Console.ReadLine();

}

}

}

Birden Fazla Main() Metodu

Uygulamanızda  birden  fazla Class  varsa Main() metodunun  hangi Class’ta olduğunun  önemi  yoktur.  Çünkü  C#  derleyicisi  Main()  metodunun  hangi Class’ta olduğunu arayıp buluyor. Uygulamadaki birden  fazla  sınıfta Main() metodu  varsa  hangisinin  kullanılacağının  belirtilmesi  gerekir.  Bu  konuda bilgi vermek için aşağıdaki gibi bir C# programı hazırladım.

using System;

class Deneme1

{

public static void Main()

{

Console.Write(“Konsol ilk main ile başladı”);

Console.ReadLine();

}

}

class Deneme2

{

public static void Main()

{

Console.WriteLine(“Konsol ikinci main ile başladı”);

Console.ReadLine();

}

}

Bu örneğe dikkat ederseniz Main() metodunun parametresiz olduğunu veya parantezin  içine herhangi bir değişken adı yazmadığımı görürsünüz. Ayrıca bu örnekte Namespace hazırlamadığımı fark etmiş olmalısınız. Bu  şekilde  hazırlanan  C#  programı  bilinen  şekilde  derlendiğinde  hata meydana  gelir.  Derleme  satırında  hangi  sınıftaki  Main()  metodunun

kullanılmak  istendiği  belirtilmelidir.  Bu  program  aşağıdaki  gibi  derlenirse ygulama ilk sınıftaki Main() metodundan itibaren çalışmaya başlar :

csc dosyamiz.cs /main:Deneme1

Write ve WriteLine Metotları

Yukarıda  verdiğim  örneklerde  konsola  yalnızca  bir  bilgi  yazdım. Şimdi konunun  anlaşılmasına  katkı  olması  için  4  bilgiyi  yazacağım.

using System;

namespace Tokmak

{

class sinif_1

{

public static void Main()

{

Console.Write(“Fenerbahçe”);

Console.Write(“Galatasaray”);

Console.Write(“Beşiktaş”);

Console.Write(“Trabzonspor”);

Console.ReadLine();

}

}

}

Bu programda Write() metodu ile konsola 4 bilgi arka arkaya yazılmakta ve ReadLine()  metodu  ile  programın  işletimi  askıya  alınmaktadır.

Bu  bilgilerin  ayrı  satırlara  yazılmasını  sağlamak  için  Write()  yerine WriteLine()  metodunu  kullanabilirsiniz.  WriteLine()  metodu  kendisine parametre olarak  verilen bilgiyi belirtilen  ortama (burada  konsol)  yazdıktan sonra imleci bir sonraki satırın başına alır.

using System;

namespace Tokmak

{

class sinif_1

{

public static void Main()

{

Console.WriteLine(“Fenerbahçe”);

Console.WriteLine(“Galatasaray”);

Console.WriteLine(“Beşiktaş”);

Console.WriteLine(“Trabzonspor”);

Console.ReadLine();

}

}

}

Write()  metodu  ile  konsola  yazılan  metnin  sonuna  satır  başı karakterini(“\n”) ekleyerek aynı  sonucu alabilirsiniz.

using System;

class sinif_1

{

public static void Main()

{

Console.Write(“Fenerbahçe\n”);

Console.Write(“Galatasaray \n”);

Console.Write(“Beşiktaş \n”);

Console.Write(“Trabzonspor \n”);

Console.Read();

}

}

Wsus, sistem yöneticilerinin ağlarında bulunan, Windows işletim sistemine sahip bilgisayarlardaki güncellemeleri (Office, Exchange, SQL, Windows) takip etmelerini sağlayan bir servis yazılımıdır.

• Windows Server 2008 R2 ile uyumludur.
• Windows Server 2008 R2′deki BranchCache özelliğini destekler.
• Windows 7 ve Windows Server 2008 R2 istemcisini destekler.
• Rapor özelliği sunar.
• WSUS 3.0 SP2 yalnız başına yüklenebilir veya WSUS 3.0 SP1′e güncelleme olarak kullanılabilir.

WSUS’u kurmak için minimum sistem gereksinimleri :

1. 6 GB boş disk alanı.

2. System partition NTFS ile formatlanmış olması.

3. IIS 5.0 (Windows 2000) ya da IIS 6 (Windows 2003/R2) kurulu olması gerekir.

4. Net Framework 1.1 SP1.

WSUS 3.0 SP1 için gereksinimler :

Windows Server 2008

Windows Server 2003 SP1 (en az)

IIS 6.0 (en az)

Microsoft .NET Framework 2.0

Microsoft Management Console 3.0

Microsoft Report Viewer

WSUS 3.0 Administration Console için gereksinimler :

Windows XP SP2

Microsoft. NET Framework 2.0

Microsoft Management Console 3.0

Microsoft Report Viewer

• Microsoft Report Viewer sisteminizde kurulu değilse bu durum kurulumu engellemeyecek, fakat yazılımdan rapor alma özelliğini kullanamazsınız. Raporunuzu Excel veya PDF seklinde kaydedebilirsiniz.
• Eğer sisteminizde SQL 2005 sunucunuz varsa database olarak orayı tanımlayabilirsiniz. Eğer yok ise yükleme paketi WSUS Windows Internal Database’i kurarak yapılandıracaktır.

Desteklenen İşletim Sistemleri :

Windows 7; Windows Server 2003; Windows Server 2003 Service Pack 1; Windows Server 2003 Service Pack 2; Windows Server 2008; Windows Vista; Windows Vista Service Pack 1; Windows Vista Service Pack 2; Windows XP Service Pack 3

Windows Server 2008 R2, Windows Server 2008 SP1 or later versions, Windows Server 2003 SP2 or later versions, Windows Small Business Server 2008, Windows Small Business Server 2003 and Windows XP SP3

WSUS Download :

http://www.microsoft.com/downloads/details.aspx?FamilyId=a206ae20-2695-436c-9578-3403a7d46e40&displaylang=en

Yükleme paketi WSUS 3.0 SP2 Server, WSUS 3.0 SP2 Yönetim konsol bileşenleri ve düşük seviye işletim sistemleri için WUA istemcisi yükler.

Adım Adım WSUS Yüklemesi :

1. İnstaller’ı Çalıştırın.
2. Sunucu kurulumu yapıyorsanız ilk seçeneği, eğer kurduğumuz bir WSUS’u istemci bir pc den yönetmek istersek 2. seçeneği seçin.
3. Lisans sözleşmesini kabul edin.
4. WSUS’un update’leri indireceği yeri seçin. Yüksek alan içeren bir bölüm olması faydanızadır.
5. Eğer sisteminizde SQL 2005 sunucunuz varsa database olarak orayı tanımlayabilirsiniz. Eğer yok ise yükleme paketi WSUS Windows Internal Database’i kurarak yapılandıracaktır.
6. IIS üzerinde WSUS’a istemcilerin erişim yapacakları site ayarını yapın. Yerel web sayfasını kullanacaksanız 1. seçeneği, yeni bir WSUS web sitesi oluşturacaksanız 2.seçeneği seçin. 2. seçeneği seçtiğinizde sitenizin sonuna bir port numarası eklenir. Eğer modeminiz dahilinde veya software olarak bir firewall kullanıyorsanız bu porta erişim izni tanımanız gerekir.
7. Ayar Sihirbazından gereken ayarları yapınız.
8. Sistemde birden fazla WSUS varsa ikinci seçeneği seçerek senkronize edebilirsiniz. İlk kurulum için birinci seçeneği seçerek WSUS’u doğrudan Windows Update ile ilişkilendirebilirsiniz.
9. Proxy ayarlarınızı yapın.
10. Start Connection’u seçerek bağlantıyı başlatıp update bilgilerini alalım.
11. Güncelleme yapacağımız yazılımların kullandığı dil paketlerini güncelleme olarak alalım. Office, Exchange, SQL, Windows vs.
12. Güncelleme yapmak istediğimiz alanları seçelim.
13. Güncelleme günlüğü oluşturun.
14. Senkronizasyonu başlat seçeneğini de seçerek kurulumu bitirelim.

(Wsus’a Başlat/Programlar/Yönetimsel Araçlar’dan ulaşılabilir.)

WSUS admin sayfası :

http://wsusserver/WusAdmin

Eğer default olan port numarasından başka bir port atadıysanız :

http://wsusserver:PortNumaraniz/WusAdmin

Adım Adım WSUS Konfigürasyonu

1. Eşitleme bittikten sonra kategoriler halinde gördüğümüz güncelleştirmelerden, Filter kısmından “Unappored” Status kısmından “Any” sorgularını yaptığımızda eşitlemede çektiğiniz liste gelir. Yüklenmesini istediğimiz güncelleştirmeleri seçerek “Approve” seçeneği ile güncelleştirmeye başlıyoruz.
2. Şimdi, istemcilerin bu güncelleştirmelerden haberdar olabilmesi için template ekliyoruz. Wuau template’i editöre ekleyelim.
3. Administrative Templates’e sağ tıklayalım. Add/Remove Templates’i seçin. Wuau.adm dosyasını seçip ekliyoruz.
4. GPO>Computer Configuration>Administrative Templates>Windows Components>Windows Update
5. Configure Automatic Updates > Enabled
6. GPO > Computer Configuration > Administrative Templates > Windows Components > Windows Update
7. Specify intranet Microsoft update service location > Enabled* GPO’nun istemcileri görmesi 15-20 dakika arası zaman alabilir. Bu süreyi beklemek istemiyorsanız “wuauclt.exe /detectnow” komutu ile anında istemcileri belirleyebilirsiniz.
8. Gpupdate /force komutunu çalıştıralım ve istemcileri yeniden başlatalım.
9. İstemci de rsop.msc komutunu çalıştırarak policy ayarlarımızın geçerliliğini sınayalım.

WSUS 3.0′da e-mail bilgilendirmeleri

Posta Sunucusu Ayarları :

E-Mail Server sekmesinden “Outgoing e-mail server (SMTP)” kutusuna mail sunucunuzun adini yazin. “Port number” kutusuna mail sunucusunun SMTP portunu yazin.

“Sender name” (Gönderen)
“E-mail address” (Gönderenin Mail Adresi)
Eger mail sunucunuz kimlik dogrulamasi yapiyorsa “My SMTP server requires authentication” secenegini secin ve kullanici adi ile sifreyi yazin.

Uygulayıp çıkınız.

Gönderim Ayarları :

WSUS Administration / Options / E-Mail Notifications / General

Send e-mail notification when new updates are synchronized” seçeneğini seçerek, güncellemeler hakkında, “Send status reports” seçeneğini seçerek durum bildirimlerini mail olarak alabilirsiniz.

Recipients bölümüne bilgilendirme mesajlarini alacak emailleri yazin. Birden fazla email adresi yazacaksaniz noktali virgul ile ayirin.

“Frequency box” (Gönderim sıklığı)

“Send reports at” (Gönderim saati)

“Recipients” (Alicilar)

Ayarlarını yapın ve uygulayın.

Bu yazıyı bilgisayarınıza PDF Formatında indirebilirsiniz :

DOWNLOAD

Kaynaklar :

http://www.microsoft.com/downloads/details.aspx?FamilyId=a206ae20-2695-436c-9578-3403a7d46e40&displaylang=en#Requirements

http://blogs.digitalortam.net/

http://www.hidayetaltun.com/wsus/

http://mshowto.org

http://www.syslogs.org/tag/wsus/

http://osman-shener-tr.blogspot.com

Bugün Microsoft Certificied Application Developer | SOA Danışmanı Gökhan Öztopuz‘un seminerine katıldım. Yaklaşık 3,5 saat süren seminerde :

Web Temelleri (html, css, javascript, ajax, .NET)
Web servisleri (xml)
Ajax örnekleri
Azure
Bulut Bilişimi

Konuları üzerinde duruldu.

Yarın “Daron Yöndem” hocanın seminerine katılacağım.  O seminerde ise :

WPF ile 3D animasyonlar

LINQ ile veritabanı erişimi

Silverlight

konuları üzerinde durulacak.

Bugün ki seminere ait sunular :

BULUT BİLİŞİMİ-SAAS-AZURE

WEB SERVİSLERİ-

Web Temelleri

Kolay gelsin.

M.Serhat Dündar

Not: Bu döküman “Mod Security Reference Manual” dökümanından yararlanılarak yazılmıstır.

Zaman zaman içinde kendi yorumlarım ve örneklerim bulunmaktadır.

Giris

Mod Security Nedir?

Mod Security, Web uygulamaları için gelistirilmis açık kaynak kodlu güvenlik duvarıdır “Web Application Firewall (WAF)”. Mod Security web sunucusuna gömülü sekilde çalısır.

Kullandıgınız ve ya yazdıgınız web uygulamaları için saldırı tespit ve engelleme görevini üstlenir.

Neden Kullanırız?  Yararları Nelerdir?

1. Mod Seucirty HTTP trafigini son derece detaylı dinler (Bunu ileride auditlog kavramında görecegiz). Apachenin loglarını göz önünde tutarsak istek içerigi ve cevap içerigi gibi ibarelerin loglanmadıgını görürüz. Oysa Mod Security HTTP trafigi üzerinde her türlü veriyi kayıt altına alma yetenegine sahiptir. Hatta bu logları gruplamanıza ve ya daha okunur sekilde yazdırmanıza yardımcı olur. Bir çok log analiz standartını desteklemektir. Özellikle kendi içinde guarding log sitilinide bulundurmaktadır.

2. Mod Security`nin bir avantajıda gerçek zamanlı veri analizi yapmasıdır. Bu ne demektir?

Kullanıcıların uygulamalarınız üzerinde ve ya web sunucunuza baglandıgı andan itibaren gelen giden veriler üzerinde istediginiz kontrolleri yapmanız demektir.

3. Saldırı tespit ve önleme için anında müdahaleler yapmanıza yarayan kurallar yazabilirsiniz.

Mod Security web uygulamalarınıza erismek isteyen saldırılara karsı anında tepki verir.

Bunu çogunlukla üç yolla yapar :

a. Negatif Güvenlik Modeli (Negative Security Model):

Anormal istekleri, sıra dısı hareketleri ve genel web uygulama ataklarını izler. Kısacası bir çok detaya bakıp (ip adress, oturum, kullanıcı hesabı) bunların sonucuna göre kuralların islenmesi saglanır.

b. Pozitif Güvenlik Modeli (Positive Security Model):

Bu modeli uyguladıgınızda, sadece geçerli tanımladıgınız istekler kabul edilir ve bunun dısındakiler tümüyle reddedilir. Bu yaklasım agır ve nadiren güncellenen uygulamalarla çok iyi çalısır.

c. Bilinen Zayıflıklar ve Açıklar (Known weaknesses and Vulnerabilities):

Mod Security`nin kural dili sayesinde, dısarıdan gelen saldırılara karsı sunucunuza kurallar yardımı ile birlikte yamalar yapmanızı saglar. Bu yamalar sunucunun kendi açıklarından ziyade üçüncü parti yazılımlardan kaynaklanan açıklardır. Bu yazılımlardan kaynaklanan açıklar yazılım sahibi tarafından güncellenene kadar mod Security ile yamalar olusturabilirsiniz. Yani dısarıdan gelen zararlı istekleri azaltmaya yarar. Web uygulamalarının açıklarını düzeltmek bir çok kurumda haftaları buluyor. Mod Security sayesinde uygulamanın kaynak koduna dokunmadan (çogu zaman erismeksizin) dısarıdan kurallar ekleyerek güvenlik yamalarınızı olusturabilirsiniz.

4. Mod Security kural moturu (SecRuleEngin) çok esnek kurallar yazmamızı saglar. Bu motor aynı zamanda Mod Security`nin asıl amacını tasır. Aynı zamanda HTTP islem dataları üzerinde bize özel bir programlama dili sunar. –ki bu dil normal firewall kullanıcıları ve ya web uygulaması gelstirenler için çokta yabancı degildir (Özellikle regular expression – düzenli ifadeler, PCRE kütüphanesi kullanılır). Bir diger hususta zincir kurallar olusturabilmenizdir. Bsunu bir nevi if kurallarına benzeterek yapılan kural takımıda diyebiliriz. Buda sizin daha kompleks kurallar yazmanız anlamına gelir.

5. Yukarıda da söyledigimiz gibi Mod Security gömülü bir firewall uygulamasıdır. Bunun anlamıda kurulu olan web sunucunuza istediginiz zaman ilave edebilir ve devre dısı bırakabilirsiniz. Mod Security`nin bu kullanım sekli ile daha önce var olan networkünüzde herhangi bir degisiklik yapmanıza gerek kalmaz. Ayrıca kural dosyalarının Web sunucunuzla bir bagı olmadıgından tasınabilirligi gayet kolaydır. Ayrıca SSL tarfiginide analiz etme yetenegine sahiptir. Bunu SSL üstünden geçen veriler çözüldükten hemen
sonra hayata geçirir. Bir çok isletim sistemiyle birlikte gayet uyumlu çalısır. Genel kullanıcıları FreeBSD, Linux, Windows, Solaris, OpenBSD, NetBSD, AIX, Mac OS X ve HP-UX.

6. Mod Security apachenin Mod proxy uygulaması ile birliktede çalısabilir.

Devamı için :

ModSecurity_2.1.0_Turkish

Tanım :

Syhunt firmasının en iyi ürünlerinden olan Sandcat’in, tamamen php scriptler için yazılmış hali “SandCat for PHP”.

Özellikler :

** Sandcat’in paranoyak yapısını unutmamak lazım. Bütün $Post $Get $Sesion $Cookie karakterleri, echo komutu ve daha bir çoğu muhtemel tehlike onun için.

* Program sadece local olarak çalışmakta.

* Ücretsiz sürümünde tek seferde sadece 2 dosya için tarama yapabilirsiniz. Fakat tarama yapacağınız toplam dosya sayısı sınırsızdır.

Daha önce genel sürümünü tanıtmıştım :

http://fentanyl.wordpress.com/2009/04/21/sandcat-37-web-security-scanner/

Konfigürasyon Dosyalarının Güvenliği

Sandcat’in bize sunduğu özellikler arasına Syhunt Hardening Tool’da bulunmakta.

Bu özellik ile php.ini, httpd.conf gibi konfügürasyon dosyalarının güvenlik ayarlarını otomatik olarak denetleyebiliyoruz.

Örnek bir php.ini dosyasına ait analiz :

Örnek bir httpd.conf dosyasına ait analiz :

Download :

http://www.syhunt.com/

M.Serhat Dündar

Uzun zamandır activeX ile ilgili doğru düzgün bir güvenlik yazılımı görmemiştim. O yüzden bu yazılım gözümde bi kat daha değerli. Bugün security-database’de gezinirken rastladığım bu güzel programı paylaşmak istedim.

Download :

http://sourceforge.net/projects/dranzer/

Usage (Kullanım) :

“dranzer.exe <secenekler>”

Seçenekler :

-o <outputfile> – Output Filename
-i <inputfile> – Use input file CLSID list
-d <notestfile> – Use don’t test CLSID List
-g – Generate base COM list
-k – Generate Kill Bit COM list
-l – Generate Interface Listings
-b – Load In Browser (IE)
-t – Test Interfaces Properties and Methods
-p – Test PARAMS (PropertyBag) in Internet Explorer
-s – Test PARAMS (Binary Scan) in Internet Explorer
-n – Print COM object information
-v – Print out version information
-r – Generate Kill Bit registry files

Örnek:

dranzer.exe -g

User Guide :

http://docs.google.com/Doc?docid=0ATn5yqW-bnJPZGhtZGNoZjVfMTAwYzU0NW04OXE&hl=tr

Döküman :

dranzer

Bakılması Tavsiye Kaynaklar :

http://www.cert.org/vuls/discovery/dranzer.html

M.Serhat Dündar

User Guide :

Overview

ActiveX and COM vulnerabilities have been getting much attention lately. ActiveX allows a web browser to use software components installed on a Windows machine. Scripting technologies can allow an attacker to control the memory contents of a machine. By combining scripting and ActiveX, an attacker can take advantage of flaws in COM objects, which may allow execution of arbitrary code, information disclosure, or other security violations.

Dranzer is a tool that can detect flaws in COM objects.

Target Audience

Dranzer can be useful to various groups of people:

1. Software developers can test COM objects as they are being developed. By testing during the software development process, developers can prevent vulnerabilities before the software is released to the public.

2. Software vendors can detect and fix flaws in their COM objects before attackers discover the flaws.

3. System administrators can assess the security of their systems with respect to COM objects.

ActiveX Vulnerability Classes

I. COM objects that crash Internet Explorer upon instantiation.

Some COM objects will crash Internet Explorer just by being referenced in a web page. The COM object may not have been intended for a web browser, but Internet Explorer will attempt to instantiate any COM object that is referenced in an <OBJECT> tag, regardless of whether the object is a traditional ActiveX control. Certain COM objects will cause Internet Explorer to crash in a manner that attackers can exploit to execute arbitrary code.

More information about this class of vulnerabilities is available in “Multiple COM objects cause memory corruption in Microsoft Internet Explorer” (http://www.kb.cert.org/vuls/id/959049).

II. COM objects that fail to properly validate input.

Attackers can use a script within a web page to control COM objects that are marked “Safe for scripting.” This script would call methods or access properties of the COM object. Attackers can control COM objects that are marked “Safe for initialization” by using <PARAM> tags in a web page. If the COM object fails to properly validate input, such as enforcing a maximum size for a string parameter, an attacker may be able to pass specially crafted parameters that would cause the object to crash Internet Explorer in a way that the attacker could exploit.

An example of this type of vulnerability is available in “RealPlayer ActiveX control contains buffer overflow in ‘ShowPreferences’” (http://www.kb.cert.org/vuls/id/698390).

III. COM objects that do not restrict access to its methods.

Unless special restrictions are in place, any web page can call the methods provided by safe-for-scripting COM objects. Attackers may be able to take advantage of some of these methods to disclose information unintentionally; they may even be able to download and execute applications.

An example of this type of vulnerability is available in “Microsoft Log Sink Class ActiveX control incorrectly marked ‘safe for scripting’” (http://www.kb.cert.org/vuls/id/165022).

Dranzer system requirements

Operating system: Windows Vista, XP or Windows 2000. Windows XP is preferred.

Browser: Internet Explorer with ActiveX enabled for the Internet Zone (IE 6 and earlier) and Local Intranet Zone (IE 7 or later)

Note: We do not recommend running Dranzer on production systems. The process of testing COM objects essentially involves executing pieces of code that exist on a system, and this may have adverse effects in a test environment.

Running Dranzer

C:\Program Files\Dranzer\Dranzer\Release>Dranzer.exe

Execution mode not specified use -g,-k,-l,-b, or -p

Usage: Dranzer.exe <options>

Options:

-o <outputfile> – Output Filename

-i <inputfile> – Use input file CLSID list

-d <notestfile> – Use don’t test CLSID List

-g – Generate base COM list

-k – Generate Kill Bit COM list

-l – Generate Interface Listings

-b – Load In Browser (IE)

-t – Test Interfaces Properties and Methods

-p – Test PARAMS (PropertyBag) in Internet Explorer

-s – Test PARAMS (Binary Scan) in Internet Explorer

-n – Print COM object information

-v – Print out version information

-r - Generate Kill Bit registry files

Dranzer has the ability to test all three of the COM vulnerability classes described above.

Class I: (-b)

With the “-b” option, Dranzer will check for COM objects that cause Internet Explorer to crash upon their instantiation.

Example usage:

Dranzer.exe -o testmachine_crashie.txt -b

Class II: (-t, -p, -s)

With the “-t” option, Dranzer will check for COM objects that fail to properly validate input to methods.

Example usage:

Dranzer.exe -o testmachine_report.txt -t

With the “-p” and “-s” options, Dranzer will check for COM objects that fail to properly validate input to initialization parameters. Dranzer will check for available parameters by using either the IPropertyBag interface or by scanning the binary file, respectively.

Example usage:

Dranzer.exe -o testmachine_param_bag.txt -p

Dranzer.exe -o testmachine_param_scan.txt -s

Class III: (-l)

With the “-l” option, Dranzer will enumerate the methods and properties of COM objects that are marked “safe for scripting.”

Example usage:

Dranzer.exe –o testmachine_methods.txt -l

Using baselines and exception lists

The “-g” option can be used to create a “baseline” list of COM objects installed on a machine. This capability can be useful for determining what COM objects an application provides. For example:

1) Create a baseline snapshot for the machine being used in the test:

Dranzer.exe -o baseline.txt -g

2) Install software package

3) Run Dranzer with the “-d” option to exclude the COM objects in the baseline:

Dranzer -d baseline.txt -o myapp_crashie.txt -b

Alternatively, you can execute the alltests.bat script to run all Dranzer tests for COM objects that do not exist in the baseline.txt file. Rather than using the command line listed in step 3, simply run alltests.bat. This will test only the new COM objects that were installed with the software package in step 2. Included in the Dranzer installation are the files xpprosp2.txt and vista.txt. These files contain a list of COM objects that come with Windows XP Professional SP2 and Windows Vista, respectively. You can use these files as a starting point for testing COM objects on a system if you were unable to generate a baseline before installing the software.

Using input lists

The “-i” option can be used if you wish to provide a list of the COM objects that you would like to be tested.

Example usage:

Dranzer.exe -i mycomobjects.txt -o myobjects_test.txt -t

This command will test the methods of the COM objects listed in the “mycomobjects.txt” input file.

Using Kill Bit Registry files

The “-r” option can be used in combination with any of the Dranzer tests (-t, -p, -s, or -b) if you wish to generate kill bit registry files to prevent Internet Explorer from using controls that Dranzer has found to be defective.

Example usage:

Dranzer.exe -t -r myobjects_test

This command will test the methods of all COM objects on a system, and any COM object that has failed the methods test will be added to the myobjects_test.reg file. Opening this file will merge the kill bit values into the registry, which will prevent Internet Explorer from using those controls. If you wish to undo the kill bit changes, simply open the “Undo” version of the .reg file.  This will revert the kill bit values back to their original state.

Interpreting the results

Class I: (-b)

The output file will contain a list of all COM objects that have caused Internet Explorer to crash on their instantiation. The crashes are usually caused by memory access violations.

As Dranzer encounters COM objects that cause Internet Explorer to crash, it will save HTML files in the current directory. Opening these files in Internet Explorer can help to verify the crashes. The file names will be {GUID}_load.html, where GUID is the identifier for the COM object.

Class II: (-t, -p, -s)

The output file will list all COM objects that have caused Internet Explorer to crash when Dranzer passed unexpected values to their methods. You can see the methods and properties that were accessed prior to the crash. The crashes are usually caused by memory access violations.

As Dranzer encounters COM objects that cause Internet Explorer to crash as the result of initialization parameters, it will save HTML files in the current directory. Opening these files in Internet Explorer can help to verify the crashes. The file names will be {GUID}_param_pb.html or {GUID}_param_bs.html, depending on which flag was used. Dranzer does not determine the specific parameter that caused the crash but rather includes all possible parameters in the HTML file.

Detailed crash analysis of COM objects

For both Class I and Class II COM object vulnerabilities, any access violation can indicate a vulnerability that an attacker may be able to exploit to execute arbitrary code. As a general rule, the more control an attacker has over the crash, the more likely that an arbitrary code execution vulnerability exists. Dranzer uses lowercase ‘x’ characters to test for buffer overflows, so any time the value “78” is seen in the crash details, it usually indicates an exploitable flaw. In certain circumstances, Dranzer will detect an access violation but will not show details such as memory locations and operation. This situation can happen when the buffer overflow causes the structured exception handler (SEH) to be overwritten. When the SEH is overwritten, Dranzer is not able to trap the access violation and will not be able to display the crash details for the method that caused the buffer overflow. In these cases, the very last method called for a COM object is suspect. When testing fixes for COM objects, Dranzer must be able to test the object without indicating any access violations in the results.

Dranzer output examples

Top-level errors

In the Dranzer output, these errors are listed at the beginning of each failed COM object. Possible errors include the following:

ERROR – Access violation (0xc0000005)

This error indicates a crash as the result of accessing an invalid area of memory.

ERROR – Buffer Overrun Fault (0xfffffff3)

This error is usually indicative of a buffer overflow that is caught by Microsoft’s /GS buffer security check. The /GS buffer overflow protection can make it more difficult to exploit the vulnerability. However, depending on what the vulnerable control’s code does, and whether the /SAFESEH flag was used, an attacker can often bypass this protection. Note that Dranzer can produce this error as a false positive if the control uses the same error code for other errors. Also note that Dranzer will not clearly indicate which method caused the buffer overrun fault error code, but it will be the last method or property listed in the Dranzer output.

ERROR – COM Object Exception Occurred (0xfffffff9)

The COM object has generated an exception, which is usually the result of a memory access violation.

ERROR – Internet Explorer Crashed (0xfffffff7)

The HTML test case caused IE to crash. Use the relevant HTML file in the Dranzer directory to reproduce the crash.

ERROR – COM Object Operation Hung (0xffffffff)

The COM object has not responded within the time allowed. Certain COM objects can hang when a web page attempts to use them; others can have specific methods that will cause the hang. With either of these situations, the errors are not normally exploitable, but in certain cases a buffer overflow or other error can cause memory corruption that will lead to a hang. You need to further investigate these errors by testing other input values, if possible, to determine if this is the case.

Method-level errors

In the Dranzer output, Method-level errors are listed for specific methods or properties. The following are example errors:

*****************************

*** Access Violation ***

*****************************

Invoked Property Get – ObjectName::short PropName()

Access violation at 0×6E205539 :Bad read on 0×00000000

This is a null pointer dereference access violation as the result of attempting to refer to the “PropName” property. It is less likely to be exploitable because of the null pointer and also because the property takes no parameters. However, keep in mind that the Dranzer testing is sequential, so a crash in a specific method or parameter may be the result of the actions that took place before (above) it.

*****************************

*** Access Violation ***

*****************************

Invoked Method – ObjectName::VARIANT_BOOL MethodName()

Access violation at 0×7C91142E :Bad read on 0×78787878

This indicates that a buffer overflow has taken place, with the memory address being the value specified in a buffer value (lowercase ‘x’ being 0×78 in ASCII). Depending on what the COM object is doing with the value that is being read from that location, this flaw has a high probability that an attacker can exploit it to execute arbitrary code. Note that this is another case in which the method that triggers the access violation is not the one that accepts user input. The buffer overflow likely took place in a previous parameter or method operation, but what is experienced can be considered a “second-order” flaw because the symptoms of the flaw are not immediately seen.

*****************************

*** Access Violation ***

*****************************

Invoked Method – ObjectName::long MethodName([in] BSTR ParameterName<”xxxx…..{10240}”>)

Access violation at 0×78787878 :Bad read on 0×78787878

This indicates a buffer overflow vulnerability that is trivially exploitable. Two identical memory addresses indicate that the COM object is trying to execute code at the specified address. In this case, it’s the hex value of the characters in the parameter specified for the method.

*****************************

*** Access Violation ***

*****************************

Invoked Property Get – ObjectName::long PropertyName(long ParameterName<-1>)

Access violation at 0×6338092E :Bad read on 0xFFFFFFFF

This is an example of a possible integer overflow. Depending on how the memory address can be affected by various parameter values, the flaw may be exploitable.

Note: If there is a top-level error reported, but no method-level violation is present, look at the last method or parameter that Dranzer tested in the output. This last entry is likely the one that caused the SEH to be overwritten or caused /GS protection to trigger. Both of these cases will prevent a method-level violation from being reported. Vulnerabilities in which the SEH is overwritten as the result of a buffer overflow are usually trivially exploitable.

The behavior where the test process is terminated unexpectedly can cause important flaws to be overlooked. This can happen when a method-level violation is reported, but also the last method tested causes one of the exceptions described above. Dranzer may not report the method-level exception in the output. To work around this situation, use Dranzer to retest COM objects after all reported violations are fixed in the code and pay special attention to the last method listed in Dranzer test reports.

Class III: (-l)

This class of vulnerabilities requires the most analysis to determine if there is a problem. Look for method names that an attacker could leverage. The following are some examples of dangerous methods:

ShellExecute(BSTR)

Reboot()

DownloadFile(BSTR,BSTR)

HttpPOST(BSTR,BSTR,BSTR)

GetUserName()

If the COM object does not restrict which web addresses can use the methods, attackers may be able to use the COM object to their advantage.

Other COM fuzzers

axfuzz – <http://sourceforge.net/projects/axfuzz>

axfuzz was the inspiration for creating Dranzer. With the axfuzz package, you must use a combination of the axenum and axfuzz tools to fuzz test an entire system. When the testing tools crash, the tools must manually be restarted at a specific control after the one that caused the crash, and crash details are not included in the reports.

COMRaider – <http://labs.idefense.com/labs-software.php?show=20>

COMRaider is a graphical tool for fuzz testing a single COM object. Crash details are included, which can help determine which COM flaws may be exploitable. Due to the program design, a high level of user interaction is required, and the tests take a long time to complete.

AxMan – <http://metasploit.com/users/hdm/tools/axman>

AxMan is a browser-based method fuzz tester. AxMan is designed to fuzz test all of the COM objects installed on a system, and the test process involves multiple steps. Once a crash is encountered, the test process must be manually restarted to begin again using a control that exists in the list after the one that caused the crash. COM objects that display dialogs or present the Internet Explorer information bar will require a user to manually click those items to continue the test process. AxMan does not appear to support Internet Explorer 7.

COM fuzzer comparison

A single COM object that was known to be vulnerable was used to compare the fuzz test tools:

References

Microsoft ActiveX security resources:

• “Designing Secure ActiveX Controls” (http://msdn.microsoft.com/en-us/library/aa752035.aspx)
• “ActiveX Security: Improvements and Best Practices” (http://msdn.microsoft.com/en-us/library/bb250471.aspx)
• “How to stop an ActiveX control from running in Internet Explorer” (http://support.microsoft.com/kb/240797)

“Results of the CERT/CC Security in ActiveX Workshop” (http://www.cert.org/reports/activeX_report.pdf)

Vulnerability notes:

• “Multiple COM objects cause memory corruption in Microsoft Internet Explorer” (http://www.kb.cert.org/vuls/id/959049)
• “RealPlayer ActiveX control contains buffer overflow in ‘ShowPreferences’” (http://www.kb.cert.org/vuls/id/698390)
• “Microsoft Log Sink Class ActiveX control incorrectly marked ‘safe for scripting’” (http://www.kb.cert.org/vuls/id/165022)

Other COM fuzzers:

• axfuzz (http://sourceforge.net/projects/axfuzz)
• iDefense Labs Fuzzing Software Tools (http://labs.idefense.com/software/fuzzing.php#more_comraider)
• AxMan (http://metasploit.com/users/hdm/tools/axman)

Tanım :

Web application simple validation checking script for webpage
Simple Validation check Scanner – with all perimeter [ XSS , Validation Error , SQL Injection ...]
gamja v.1.6 – from screammingCSS+ Paros+ Private skill

Gereklilikler : wget , Perl

* Sisteminizde active perl kurulu olmalı.

* Programa ait dosyaları içeren .rar dosyasını unzip ettikten sonra C:\Perl\bin dizinine atınız.

* Komut satırı ile dizine inerek gamja.pl dosyasını çalıştırın.

Resim 1 : Komut satırı ve kullanım

Kullanımı usage kısmında belirtildiği şekildedir.

Yeni komut satırı gelene kadar sayfayı kapatmayınız.

Kullanım

“gamja.pl http://hedefsite[:port][/baslama/dizini]“

Detaylı Kullanım

“gamja.pl -v http://hedefsite[:port][/baslama/dizini]“

Tarama sonuçlarını C:\Perl\bin dizini içinde oluşacak 2 adet html dosyasından inceleyebilirsiniz.

Download

http://sourceforge.net/projects/gamja/

M.Serhat DÜNDAR

Web Uygulaması Güvenliği

Web uygulaması güvenliği sağlanırken genellikle akıllara ilk gelenler çeşitli kod enjeksiyonu zafiyetleri ve girdi doğrulama temelli yaklaşımlardır. SQL Injection’ı kesmek için parametrik sorgular, XSS’i kesmek için output encoding, LFI & RFI için doğru şekilde girdi doğrulama ve CSRF için de kritik fonksiyonaliteler için token uygulaması.

Oysa dünyanın en güvenli uygulamasını yazmış olsanız dahi, sunucu üzerinde tutulan bir klasörün izinlerini doğru şekilde düzenlemediyseniz , hack’lenmeniz işten bile değil ! Bundan dolayı işin kod kalitesi ile ilgili kısmını düşünürken, konfigürasyonel boyutunu da es geçmemek gerekmektedir.

ASP.NET

Günümüzde web uygulamaları bir çok programlama dili vasıtasıyla yazılabilmekte ve bir çok üretim ortamında çalışabilmektedir. Bu dillerden ve platformlardan önemli bir tanesi ise ASP.NET ‘dir.

ASP.NET ortamında geliştirilmiş uygulamaların konfigürasyon bilgileri web.config isimli dosyada tutulur.

Web.config

Söz konusu XML dosyası uygulamanın durum bilgisi, güvenlik konfigürasyonu,  derlenme ayarları ve uygulama-spesifik bilgiler yer alır. Bir web sunucu üzerindeki tüm uygulamalar aynı konfigürasyon dosyasını kullanmak zorunda değillerdir. Farklı uygulamalar için farklı Web.config dosyaları tanımlanabilir.

İlgili konfigürasyon dosyasındaki ayarların doğru şekilde belirlenmemesi durumlarında çeşitli güvenlik zafiyetleri ortaya çıkabilmektedir.  Kimi güvenlik zafiyeti ise herhangi bir hatalı konfigürasyon beklemeden, varsayılı ayarlarda meydana çıkmaktadır.

Potansiyel zafiyetlerin bir listesi şu şekildedir:

• Hata mesajlarından  ve uygulamadan çeşitli şekillerde bilgi sızmaları
• Uygulama ile istemci arasındaki trafiğin ifşası
• Yazılımın saldırganların kontrolüne geçmesi halinde, sunucunun tüm kontrolünün kaybedilmesi
• Oturum ile ilgili konular
o Oturumun manipüle edilmesi
o Oturumun çalınması
o Zaman aşımı olmaması sonucu çalınan çerezin kullanılması
• Web çerezleri ile ilgili konular
o Çerezlerin XSS saldırısı ile çalınması
o Çerezlerin ağ trafiği dinlenilerek çalınması
• İstek hırsızlığı
• Hassas dosyaların ifşası.
• Trafiğin dinlenilmesi
• Web.config içindeki kritik bilgilerin sızdırılması [1]

Web.config dosyasının doğru şekilde konfigüre edilmesiyle söz konusu zafiyetlerin bazılarından sonsuza dek, bazılarından ise bir çok durumda korunmak mümkün olacaktır.

Web.config dosyalarındaki problemlerin otomatik şekilde incelenmesini gerçekleştirmek üzere WCSA (Web.config Security Analyzer) hazırlandı. WCSA kendisine parametre olarak geçilen Web.config dosyalarını inceleyip varolan konfigürasyonel güvenlik problemlerini ortaya çıkarıyor.

Proje’nin ana sayfası http://code.google.com/p/wcsa/ olup, download linklerine de erişebilirsiniz.

Çıktı olarak verdiği HTML raporda güvenlik zafiyetleri, zafiyetlerin tanımları, yapılması gereken güvenli konfigürasyon ve referanslar veriliyor.

Sonuç

Güvenlik bir bütün olarak düşünülmelidir. Güvenli web uygulamaları geliştirirken, güvenli kod pratiklerinin uygulanmasının yanında sürecin konfigürasyonel boyutu da göz önünde bulundurulmalıdır.

http://dergi.webguvenligi.org/websec/7-guvenli-asp-net-produksiyon-ortami.wgt

Şimdilik sadece MTTD olarak yazacağım bu scripti. Çünkü pek duyulmamış bir script ve bulana kadar ömrümden ömür gitti (: Hemde özgür domainimle açacağım sitemde kullanacağım için süpriz olsun istiyorum.

Tam aradığım özellikleri içeren 324kb.’cık bi script. Kod yazarı Rus. Kendisine teşekkür mailimi attım ve türkçe tercümesini de yarın kendisine teşekkür mahiyetinde (vouw :) yollayacağımı bildirdim.

Validating işlemini tamamen bitirdim. Rus arkadaş baya bi yetenekliymiş.

Penetration Test kısmında şimdilik güvendiğim yazılımlardan olan Syhunt firmasının Sandcat’i ile script üzerinde bi kaç tarama yaptım :

ajax.lang.php, ajax.php dosyalarında XSS açıkları yaratması muhtemel satırlar bulundu.

Yine veritabanı bağlantı dosyalarında İnjection yaratması muhtemel satırlar bulundu.

** Sandcat’in paranoyak yapısını unutmamak lazım. Bütün $Post $Get $Sesion $Cookie karakterleri, echo komutu ve daha bir çoğu muhtemel tehlike onun için (:

Şuan oldukça uykulu olduğum için sandcat’i ve diğer frameworkleri kapatıp tüm işleri yarına bırakıyorum.

Saati yine 05.17 yaptım..

Web uygulamalarında bulunan güvenlik zafiyetlerinin taşıdığı riskler, bu açıklıkları, günümüz siber güvenlik anlayışının en önemli konularından biri (belki de en önemlisi) haline getirmiştir. İstatistiklere göre her 10 web sitesinden 9’unda ciddi seviyede bir açıklığın olmasının yanında siber saldırıların %60’ından fazlasının web teknolojilerine yönelik gerçekleştirilmesi bu önemin açık bir nedenidir [1].

İki bölümden oluşacak bu yazının ilk bölümü, otomatik web zafiyet tarayıcılarının genellikle ilk fazı olan girdi noktası bulma algoritmaları ve etkinlikleri üzerine olacaktır.

Web uygulamalarında bulunan açıklıklar; SQL enjeksiyonu, XSS, yetersiz hata yönetimi, CSRF gibi sadece yazılımsal veya standartlarda bulunan dizayn tabanlı hatalar olmayıp, yönetimsel ve mantıksal hataları da içermektedir.

Bu yazılımlardaki güvenlik problemlerinin bulunması, düzeltilmelerindeki en önemli adımdır. Bu adımı gerçeklemek adına üç önemli yöntem; elle yapılan testler, web uygulama açıklık tarayıcıları, statik/dinamik kod analiz araçlarıdır. Ancak bilinmelidir ki, yazılımlarda bulunan risk seviyesi yüksek zafiyetlerin açığa çıkarılması sadece tek bir yöntemle mümkün veya uygulanabilir değildir. Bu nedenle kapsamlı bir risk haritası için her üç yönetimin de elden geldiğince uygulanması gerekir.

Otomatik web açıklık tarayıcılarının (WAT) kapsayıcı ve zaman açısından etkin olmaları, web güvenlik risk haritasının çıkarılmasında çok önemlidir. WAT çalışma süreçlerinin birçok safhası vardır ama işleyişleri genel olarak ikiye ayrılır; girdi keşfi ve zafiyet analizi.
Girdi noktaları web uygulamalarının çalışma prensibinin en önemli parçalarıdır. Ne de olsa, interaktiflik bu etkileşim üzerine kurulmuştur; etki ve tepki, istek ve cevap. İşte bu nedenle birçok güvenlik problemi de bu modellemede girdi denetiminin yetersiz kalmasından kaynaklanmaktadır. Web uygulamalarında girdi noktaları HTTP protokolündeki istek mesajlarının her parçasından oluşabildiği gibi (URL, HTTP başlıkları, HTTP gövdesi, v.b.) farklı protokollerdeki (RMI, JNLP v.b.) veya alt-protokollerdeki (Flash Remoting, SOAP, v.b.) parçalar da bu kategoriye girmektedir.

Girdi keşfi sırasında WAT’lar, mümkün olabildiğince fazla girdi noktası bulmaya çalışırlar. Çünkü bu fazda ne kadar fazla girdi noktası bulunursa ikinci fazda (bu fazlar her zaman art arda işlemek zorunda değildir) bir o kadar zafiyet bulma şansı doğacaktır. WAT’lar genellikle “berbatometre” olarak adlandırılmaktadırlar; yani üzerinde analiz yaptıkları uygulamanın ne kadar kötü olduğunu söyleme yetisi. Çünkü WAT’ların bir uygulamanın güvenlik açısından ne kadar kaliteli yazıldığı sonucuna varabilmeleri, risk seviyesi yüksek açıkların oranı ve bu araçların kabiliyetleri düşünüldüğünde (en azından şimdilik) mümkün değildir. Örnek olarak; yapısal bir problem olan XSS açıklıklarını bulma konusunda iyi bir iş yapan WAT’lar, yetersiz yetkilendirme konusunda sınıfta kalmaktadırlar. Başarılı oldukları iş olan yapısal problemleri bulmak, dolayısıyla ilk faz (girdi noktası keşfi)  yani saldırı yüzeyini arttırmak bu açıdan WAT’lar için hayati önem taşır.

2002 ve 2003 yıllarından başlamak suretiyle özellikle istemci tarafındaki teknoloji karmaşıklığının artması (Web 2.0) ile beraber ilk fazın kapsamlı olarak gerçeklenmesi büyük bir problem olarak karşımıza çıkmaktadır. Klasik HTML yapılarının (form, a, frame, iframe HTML elementleri) yanında ağır Javascript ve Flash gibi diğer standartların da kullanılması yaygınlaştıkça WAT statik parserların web sayfalarındaki girdi noktalarını bulmaları oldukça zorlaşmıştır. Bu konuda örnek vermek gerekirse, Web 1.0 veya 1.5 olarak adlandırılan web sayfalarında

…

<a href=”/satinal.do?deger=5&d=3453667&tür=cd”>satın al</a>

…

türünde yapılar bulmak yaygınken AJAX ve ağır Javascript kullanımıyla yukarıdaki örnek ile aynı işi yapan aşağıdaki yapılar görülmeye başlanmıştır.

…

<script type=”text/javascript”>

$(“span#satinal”).click(function(){SALELIB. doSale($(‘activeitem’).id)});

</script>

…

…

<span id=”satinal”>satın al</span>

…

Bu örnek bile klasik bir parserın ilgili girdi noktasını (/satinal.do? deger=5&d=3453667&tür=cd) bulma becerisini sorgulamaya yetmektedir.  Bu noktada yaygın olarak kullanılan WAT’lar statik parser anlayışından sıyrılmış dinamik bir duruşu uygulamaya koymuşlardır. Dinamik girdi noktası bulma işi, WAT parserının aynı bir tarayıcı (browser) gibi davranıp içinde bulunduğu kodu (Flash,  Javascript) sanki normal bir kullanıcı kullanıyormuş gibi çalıştırmasından ibarettir. Tabi ki, diğer bazı kısa yollar (heuristics) da bu işin içindedir ancak çalıştırıp sonucunu yakalamak giderek karmaşıklaşan istemci taraflı kodlar için şimdilik en mantıklı ve kısa yol gibi durmaktadır.

Güvenlik testlerinin en önemli parçalarından biri (bulma, sınıflandırma, risk hesaplamasını yapma, yazılı hale getirme ve gidermenin yanında) ölçülebilir olmasıdır. Aynı şekilde teknolojilerin de kriterler ve standartlar yardımı ile karşılaştırmalarının yapılması ve kalitelerinin ölçülmesi gerekmektedir. Kalite kontrol ve temel bir PHP web uygulaması olan WIVET, WAT’ların faz 1 etkinliğini ölçmek amacı ile yazılmıştır. Bir çok girdi noktası sınıfından oluşan WIVET, üzerine koşulan WAT uygulamasının girdi noktalarını bulmasını bekler (Şekil 1).

Şekil 1 WAT girdi noktası bulma karşılaştırması için WIVET web arayüzü

Ayrıca bu bulma ve çıkarma işlemi sırasında ve sonucunda kapsama alanını (coverage) canlı bir şekilde gösterir (Şekil 2).

WIVET‘in bazı açık kaynak kodlu ve ticari WAT’lara ve link çıkarıcılara uygulanması sonucu elde edilmiş matrix Şekil 3′te gösterilmektedir.

Şekil 3 WIVET karşılaştırma kısmi sonuçları

Genel olarak WAT’ların hangi noktalarda takıldığını belirtmek gerekirse;

1. javascript kullanarak a href /iframe oluşturma:

…

var container = document.getElementById(“container”);

var alink = document.createElement(“a”);

alink.href = “../innerpages/1_1.php”;

alink.innerHTML = “click me”;

container.appendChild(alink);

…

var diframe = createElement(“iframe”);

diframe.src = “../innerpages/12_3.php”;

body.appendChild(diframe);

…

2.  javascript onay:

…

function searchMe(){

alert(“confirm?”);

var searchcontainerifr = document.getElementById(“searchcontainer”);

var enginesel = document.getElementById(“engine”);

searchcontainerifr.src = enginesel.options[enginesel.selectedIndex].value;

}

…

3. meta refresh:

…

<meta http-equiv=Refresh content=”5; URL=../innerpages/14_1.php”>

…

4. HTTP 302 cevap içeriği:

HTTP/1.1 302 Found

Date: Sat, 06 Dec 2007 17:58:46 GMT

Server: Apache

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Pragma: no-cache

Location: ../innerpages/16_1.php

Content-Length: 69

Content-Type: text/html

This page has moved to <a href=”../innerpages/16_2.php”>HERE :)</a>

5. XHR (AJAX) meşgul modu:

function doxhr(phpname){

if(!busy){

AjaxObject.startRequest(formURL(phpname));

busy = 1;

}

else

alert(‘not so fast, one request at a time old sport’);

}

6. Linklenmeyen linkler ve (özellikle AS3 ile yazılan) SWF dosyaları içindeki linkler.

Sonuç

AJAX akımı ile beraber oluşturulan istemci taraflı kütüphaneler her ne kadar hem geliştirmeyi hem de kullanıcı kullanışlığını önemli ölçüde kolaylaştırsa ve eğlenceli hale getirse de, (HTTP) trafik karmaşıklığı ile hem manuel hem de otomatik testlerde işleri zorlaştırmıştır. Bu teknolojiler ile beraber açıklık tipleri çok değişmemiştir ama bu açıklıkları bulmak eskisinden kolay değildir. Otomatik web açıklık tarayıcılar (WAT) test yüzeylerini arttırabilmek için text tabanlı parserlar yerine artık istemci taraflı kodu koşarak (kullanıcıyı simule ederek) dinamik parserlar kullanmaya başlamışlardır. Her ne kadar dinamik tabanlı parserlar iyi iş çıkarsalar bile, çoğu durumda olduğu gibi girdi noktası bulmakta da elle yapılan testlerden iyi ve kapsamlı değildirler. Ancak WAT’lar zaman ve iş gücü değerlendirildiğinde bulunmaz yardımcılardır.

Referanslar

[1] http://www.whitehatsec.com/home/assets/presentations/PPTstats032608.pdf

http://www.bilgiguvenligi.gov.tr/teknik-yazilar-kategorisi/web-aciklik-tarayicilari-bolum-1.html

Bu yazımızda uygulama test tekniklerinden birisi olan fuzz testing (fuzzing) tekniğini ve web uygulamalarına nasıl uygulanabileceğini göreceğiz.

Fuzz Testing (Fuzzing)

Bir uygulamada zafiyet tespit edebilmek için uygulamaya rastgele veriler göndererek, uygulamanın farklı isteklere verdiği cevapları analiz etmek isteyebiliriz. Bu rastgele veri gönderme işlemine fuzzing (fuzz testing), bu işlemi yapmaya yarayan araçlara ise fuzzer denilmektedir.

Fuzz testing; test yapılacak uygulamanın arka planında ki işlevsel ve yazılımsal özellikler bilinmediğinden ve gönderilen verilerin uygulamada oluşturduğu etki ve sonuçların analizine dayandığından, uygulama test tekniklerinden black-box kategorisine girmektedir [1,2].

Fuzz testing; yazılım geliştirme ve test süreçlerinde ve ters mühendislik işlemlerinde kullanıldığı gibi, web uygulamalarında zayıflık tespiti veya bilgi toplama amaçlı da kullanılmaktadır. Web uygulamaları için geliştirilmiş olan fuzzing araçlarını (fuzzer) iki kategoride inceleyebiliriz [3];

• Recursive Fuzzing: ‘Yinelemeli fuzzing’ olarakta adlandırabileceğimiz bu teknikte, belirlenmiş karakterler fuzzer aracılığıyla kombinasyonel veriler halinde gönderilecektir. Örneğin; {3,9,6,1) şeklinde belirlediğimiz karakterler;

• • ?id=3961, ?id=3916, ….., ?id=1693 yinelenerek gönderilecek ve her bir dönen sonuç incelenecektir.

• Replacive Fuzzing: ‘Değiştirmeli fuzzing’ olarakta adlandırabileceğimiz bu teknikte ise, seçilmiş değerin / parametrenin değiştirilerek gönderilmesi esastır.

Fuzz Testing konusunda detaylı bilgiye farklı [4] kaynaklardan erişebilirsiniz. Şimdi web uygulamaları için geliştirilmiş olan fuzzer`lara göz atalım [5].

Ferruh Mavituna’s Freakin’ Simple Fuzzer (FM-FSF)

Ferruh Mavituna tarafından geliştirilen Freakin’ Simple Fuzzer (FSF) [6]; web uygulamaları için fuzz testing ve veri toplama işlevlerini yapabilmektedir. Temel düzeyde fuzzing işlemleri ve belirtilen düzenli ifadeye göre veri toplama işlemi yapabilen FSF, plugin yapısını desteklemektedir.

VB.NET ile geliştirilen FSF`i, .NET Framework 3.5 (Windows) ve Mono (OSX ve Linux) sistemlerinde çalıştırabilirsiniz. Kurulumu ve kullanımının çok basit olması nedeniyle tercih edebileceğiniz FSF`in kullanım detaylarına proje sayfasından erişebilirsiniz [7].

WebSlayer

OWASP WebSlayer projesinin ürünü olan WebSlayer [8]; web uygulamaları için hazırlanmış bir fuzz testing ve brute-force uygulamasıdır. WebSlayer ile;

• Dosya ve klasör tespiti,
• Login formlarına brute-force,
• Oturumlara brute-force,
• Parametrelere brute-force,
• XSS ve SQL Injection tespiti ve
• Authentication`lara yönelik brute-force atakları düzenlemek mümkündür.

WebSlayer`ın bünyesinde barındırdığı özellikler ise;

• Encoding desteği,
• Get, post ve header`lara yönelik ataklar,
• Authentication desteği,
• Payload desteği,
• Proxy desteğiyle gizlilik,
• Filtreleme,
• Multi Threading olarak sıralanabilir.

WebSlayer ile alakalı detaylı bilgilere proje sayfasından ulaşabileceğiniz gibi [9], belirlenen parametreye seçilen wordlist`teki değerleri post etmek için gerekli temel konfigürasyonları ve test sonuçlarını da görebilirsiniz.

Şekil -1: Konfigürasyon

Şekil – 2: Dönen Sonuçlar

Referanslar

[1] http://en.wikipedia.org/wiki/Black-box_testing
[2] http://docs.google.com/View?id=d4w2g9c_5hc6m7vgj
[3] http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors
[4] http://www.informit.com/store/product.aspx?isbn=0321446119
[5] http://www.dragoslungu.com/2007/05/12/my-favorite-10-web-application-security-fuzzing-tools/
[6] http://code.google.com/p/fm-fsf/
[7] http://code.google.com/p/fm-fsf/w/list
[8] http://code.google.com/p/webslayer/downloads/list
[9] http://www.owasp.org/index.php/Category:OWASP_Webslayer_Project

http://dergi.webguvenligi.org/websec/8-fuzz-testing.wgt

Posted in Web Güvenliği Tagged: fm-fsf, fuzz testing, fuzzer, fuzzing, Güvenlik, Web Güvenliği, webslayer ]]>

İlk bakışta ve özellikle demolarda özellikleri ile baş döndüren bu araçlar, yakından tecrübe edildikçe ve üzerinde çalıştıkları teknolojiler/zafiyet detayları öğrenildikçe, başarmaya çalıştıkları görevin çok karmaşık ve zor olmasından, bazı durumlarda beklenildiği gibi çalışmadıkları görülmektedir.

Tekrarlamak gerekirse, bu yazıda otomatik tarayıcıların iddia ettikleri özelliklerin üzerine yoğunlaşılmıştır. İddia etmedikleri özellikler ise başka bir makale konusu olabilir (mesela, kullanıcı profili çapraz testleri, integer overflow, v.b.).

Tarayıcıyı Doğru Yolda Tutmak

Hassas verilerini son kullanıcılardan koruma güvenlik gereksinimi ile yazılan web uygulamaları, kimlik doğrulama ve yetkilendirme adımlarını gerçeklemektedirler. Bu uygulamaları uzaktan denetleyecek tarayıcıların, bu kontrollerden geçip uygulamanın dahili arayüzlerine ulaşması ve uygulamadan çıkmadan ulaşabildiği bütün arayüzleri denetlemesi gerekmektedir.

Tarayıcılar doğru yolda tutunabilmek için bir çok mantıklı seçenek getirmişlerdir; giriş makro kaydedicileri, logout link belirlenmesi, v.b. Bu seçenekler denetlenen uygulamaların çoğunluğunda (ağırlıklı olarak ASP.NET/PHP/ASP) işe yaramakla birlikte, bazı durumlarda yetersiz kalmakta ve taramaların eksik kalmasına neden olmaktadırlar.

Örnek olarak, Java RichFaces JavaServer Faces için yazılmış bir bileşen kütüphanesidir. Bu kütüphane kullanılarak, AJAX teknolojisi ile kolay ve zengin uygulamalar yazmak mümkündür. ExtJS gibi, ürettiği istemci taraflı çok karmaşık kodlarla denetleyicinin sinirini hoplatan bu teknolojinin HTML element’lere (JSF’den kaynaklanan) otomatik id değeri ataması “logout link belirlenme” tekniğini bazı durumlarda kullanılmaz hale getirmekte, bazı durumlarda ise çok zorlaştırmaktadır. Örnek bir logout POST isteği aşağıda verilmiştir;

j_id_jsp_1019999124_4=j_id_jsp_1019999124_4&javax.faces.ViewState=j_id2&j_id
_jsp_1019999124_4%3Aj_id_jsp_1019999124_7=j_id_jsp_1019999124_4%
3Aj_id_jsp_1019999124_7

Yukarıda küçük periyotlar ile sadece viewstate değişmektedir. Diğer parametre isimleri (ve dolayısıyla değerleri) zaman zaman sunucu yeniden başlatmalarında, uygulama redeploylarında ve kritik hata durumlarında değişmektedirler. Parametre isimleri (id attribute değerleri), geliştiricinin özel olarak vermediği durumlarda otomatik olarak JSF motoru tarafından üretilmektedirler.

Yukarıda,

j_id_jsp_1019999124_4: form’un id’sini
j_id_jsp_1019999124_7: logout link’inin id’si belirtmektedir

Giriş ekranlarında CAPTCHA kullanıldığından, giriş makrosu oluşturulması ve kullanılması olanaksızdır.  Logout linki belirlenmesi ise yukarıda bahsedilen durumlardan ötürü (ve karmaşık olsa dahi giriş makrosu oluşturulamadığından) mümkün değildir.

Ayrıca CAPTCHA kullanımından dolayı giriş makrosunun kullanılmadığı durumlarda açıklık tarayıcının geçerli bir session cookie’sinin verilmesi ile dahili sayfalara ulaşması sağlanabilemektedir. Eğer bu session cookie’si herhangi bir nedenden dolayı geçersiz hale gelirse (bubi tuzakları, container problemleri, v.b.) tarayıcı bunun farkına varamayacağından sonuçların eksik kalmasına ve daha kötüsü sistem yöneticilerinde ve denetçilerde yanlış bir güvenlik hissine yol açacaktır.

Açıklık Bulma Kalitesi

Tarayıcılar yıllardır bilinen ve yaygın olarak exploit edilen bazı açıklıkları bulma konusunda eksik kalabilmektedirler.  Bu duruma en iyi iki örnek; Reflected XSS ve Kör  SQL Enjeksiyonudur.

Bariz sentaks (syntactic) özelliği ile bulunması en kolay açıklık vektörlerinden biri olan Reflected XSS, istek ve ardından cevap ikilisinin analiz edilmesi ile ortaya çıkarılır. Ancak bu durumda bile tarayıcılarda eksiklikler görülebilmektedir. Kullanılan veya el altındaki araçlar değerlendirilmek istenirse http://www.webguvenligi.org/xsstb/reflected.php uygulaması veya çözümleri ile beraber http://www.webguvenligi.org/xsstb/reflected_hints.php uygulaması kullanılabilir.

Ek olarak, en ciddi saldırı vektörlerinden biri olan ve üzerine bir çok araştırma (hem akademik ve akademik olmayan) yapılan Kör SQL enjeksiyonunun, otomatik tarayıcılar tarafından bulunma yetenekleri hem çok kısıtlı ve hem de hataya açıktır. Bulma algoritmaları belirli ve üzerinde çok düşünülmüş olmasına rağmen her zaman bulunması mümkün olmayan bu açıklığın ortaya çıkarılmasında yine de otomatik tarayıcılara büyük iş düşmektedir. Kullanılan veya el altındaki araçlar değerlendirilmek istenirse http://www.webguvenligi.org/projeler/sqlibench projesi kullanılabilir.

Hatalı Pozitifler (False Positives)

“False positives”, güvenlik taramalarının kaçınılmaz bir şekilde otomatize edilmesi ile denetçilerin hayatına giren bir terimdir. Temel olarak, tarayıcılar tarafından bulunan açıklıkların aslında var olmadığı anlamına gelir.

Tarayıcıların, bazı yaygın uygulamaları ve dosyaları tanımlaları veya bu uygulamalar/dosyalar yolu ile çıkan false positive’leri suppress edebilme seçeneğini sunmaları bilgi kirliliğinin azaltılması bakımından çok önemlidir.

Örnek olarak, açıklık tarayıcıların artık yaygın olarak kullanılan/bulunan jQuery ve Apache Manual dosyalarını otomatik olarak tanımaları ve bu dosyalar hakkında false positive (dizin gezinimi, os komut çalıştırma, v.b.) üretmemeleri gerekmektedir.

Esneklik

Tarayıcılar çalışırken, ayarlarında bazı değişiklikler yapılması gerekebilmektedir (yapılan istek sayısının azaltılması/arttırılması, kullanılan session id’nin yenilenmesi, false pozitif vermeye başlayan URL bölümlerinin atlatılması, v.b.). Tarama zamanı, bu ayar değişikliklerinin etkin olması beklenirken, etkin olmayacağı durumların kullanıcıya belirtilmesi bilgilendirici olacaktır.

Aynı doğrultuda bir açıklık tarayıcıda mutlaka Pause/Beklet özelliğinin bulunması ve bu özelliğin çalışması gerekmektedir.

Raporlama

Tarayıcıların çoğu özelleştirilebilen pdf/html raporlar üretebilmektedirler. Yine bu tarayıcılar çoğunlukla ilişkisel veritabanlarını kullandıkları için, özel araçlar tarafından kurumsal gereksinimlere göre daha granuler ve parse edilebilen XML raporları üretebilmelidir. Enterprise boyutlarda üretilen bir çok açıklık sonuç raporunun tek bir havuzda toplanabilmesi, ölçülebilirlik ve izlenebilirlik açısından son derece önemlidir. Bir çok tarayıcının (network, audit, web) raporlarının konsolide edilebilmesi bu  açıdan hayati önem taşımaktadır.

Web Servisler ve İstemci Taraflı Teknolojilerin Desteği

Farklı bir çok web servis teknolojisi ile üretilen uygulamaların otomatik tarayıcı tarafından algılanabilir ve denetlenebilir olması gereklidir. Bu teknolojilerden bazıları aşağıda listelenmiştir;

JBossWS
JBossWS JAX-WS
JAX-RPC
JAX-WS
Axis 1.x
Axis 2
Apache CFX
XFire 1.x
Oracle Proxy
XmlBeans
JAXB 2.0
.NET 2.0
Gsoap

Web üzerinden servis edilen istemci taraflı teknolojilerdeki açıklık vektörlerinin de denetlenebilmesi otomatik tarayıcıların özelliklerinden biri olmalıdır. Bu teknolojilerden en önemlisi Adobe Flash’tır.

Ürün Spesifik Uygulama Açıklıkları

Bu özellik web uygulama tarayıcılarında olması gereken en önemli özelliklerden biridir. Otomatik veya manuel olarak üçüncü parti uygulamalardaki bilinen ve yayınlanmış web açıklıklarının kontrol edilmesi ve bulunması %100 mümkün değildir. Yeterli kaynak bulunmaması  bu durumdaki en büyük nedendir.

Tarayıcı bir otomatik update mekanizması ile neredeyse her gün yenisi çıkan bu tür zafiyetlerin kurallarını öğrenmeli ve uygulamalıdır.

İstek Sayısı İnce Ayarı ve İstek İzleme

Tarayıcı tarafından üretilen istek sayısının ince ayarının yapılabilmesi (network tarayıcılarındaki dakikadaki paket sayısı gibi web tarayıcılarındaki dakikadaki istek sayısı) bazı durumlarda çok önemli hale gelmektedir; IPS, uygulama bubi tuzakları, uygulamanın saturasyon eşik değerleri, v.b.

Bu özelliğin yanında tarayıcı tarafından üretilen isteklerin mutlaka kaydedilme ve tarama anında veya daha sonra detaylı olarak izlenme özelliğinin tarayıcılar tarafından gerçeklenmiş olması gerekmektedir. Oturumun geçersiz olmaya başladığı, hatalı negatiflerin nedeninin bulunması gibi kritik durumlarda bu izleme yetisi denetleyiciye önemli bilgiler sunacaktır. Bu özellik çok yer alabileceğinden opsiyonel hale getirilebilir.

Sonuç

Yazıda web açıklık tarayıcılarının kısa geldiği bazı durumlardan ve özelliklerinden bahsedilmektedir. Bu özelliklerin bazılarının gerçeklenebilmesi karşılık geldikleri problemlerin doğaları gereği zordur. Bu araçları network tarayıcıları ile kıyaslamak bu açıdan doğru olmayacaktır ama çok değişkenlik gösteren web ormanında çok kaliteli bir tarayıcının çıkması biraz daha zaman alacak gibi gözükmektedir.

http://dergi.webguvenligi.org/websec/5-web-aciklik-tarayicilari–bolum-2.wgt

Microsoft Security Essentials, Microsoft’tan ücretsiz Anti-virüs Programı

MSE (Microsoft Security Essentials ), Microsoft’un yakın geçmişte (23 haziran 2009) betasını yayınladığı ücretsiz anti-virus programıdır. Windows Live OneCare’in devamı olarak görülen bu program, OneCare’dan farklı olarak en son anti-malware teknolojilerini içerir. Aynı zamanda bilgisayarınızın performansını, malware taraması süresince en üst seviyede tutmayı sağlayan bir uygulamadır.

Kod adı: Morro (MSE)

MSE (Microsoft Security Essentials ), Microsoft’un yakın geçmişte (23 haziran 2009) betasını yayınladığı ücretsiz anti-virus programıdır. Windows Live OneCare’in devamı olarak görülen bu program, OneCare’dan farklı olarak en son anti-malware teknolojilerini içerir. Aynı zamanda bilgisayarınızın performansını, malware taraması süresince en üst seviyede tutmayı sağlayan bir uygulamadır.

Projenin kod adı olan Morro (ingilizcede; tepedeki kale) bu programın dışarıdan gelen saldırılara karşı güçlü bir kale olacağını belirtmiş. Şu anki Beta testleri de bu durumu doğruluyor. Yalnızca Amerika, Çin ve Brezilya’ya açılan beta versiyonunu internet üzerinden edinmek mümkün. Performans, malware bulma ve malware’i etkisiz hale getirmek konularında oldukça iddialı.

İlk bakışta MSE, Windows XP, Windows Vista ve Windows 7 gibi işletim sistemlerinin güvenliğini yüksek oranda arttıracak bir anti-malware programı gibi görünüyor. Bahsettiğimiz bu özelliklerin gerçekten neden böyle olduklarına bir göz atalım;

Peformans :

Bilindiği üzere çoğu free / commercial anti-virüs programları işletim sistemi yüklendiği zaman daha önceden belirlenmiş tarama sürecine girer ve bilgisayarın performansını yüksek oranda düşürürler. Bir çok kullanıcı bu sebepten tarama esnasında işlerini yavaşlatmaması için anti-malware tarama programını kapatmak zorunda kalır. Bu da sistemin olası ataklara korunmaması, yani kişisel veya kurumsal bilgilerin istenmeyen kişiler tarafından ele geçirilebilme olasılığını arttırır. MSE, CPU throttling yaparak kullanıcının MSE’nin aktivitelerinden etkilenmeden çalışmasını sağlar. Bu özelliğinin yanısıra MSE kendisini öteki programlara göre daha az öncelikli olarak tanıttığından kullanıcının kullandığı programlara öncelik tanınır. Eğer kullanıcı aktivitesini engellemeyecek bir boşluk oluşursa, MSE o zamanda taramayı gerçekleştirir. Aynı zamanda MSE, RAM’de yaklaşık 4 mb gibi çok küçük bir alanda çalıştığından performans bakımından oldukça zayıf denebilecek bilgisayarlarda bile sorunsuz çalışacaktır. Son olarak CPU throttling, laptopunuz herhangi bir adaptöre bağlı değil iken tarama yapıldığında makinanın pilinin bitmemesi için enerji tasarrufu yapar.

Bu özellikleri özetlemek gerekirse, MSE, son kullanıcıya varlığını hissettirmeden çalışır ve buna rağmen piyasadaki anti-virüs programlarından daha hızlı tarama yapabilmektedir Ancak bilindiği gibi, eğer virüsleri gerçekten tanıyamıyorsa, performans tek başına hiç bir işe yaramaz.

Virüs tarama, tanıma ve etkisiz hale getirme:

Microsoft Security Essentials’ın virüs tarama ve tanımada kullandığı sistemler, en yeni çıkan malware signaturelar tanımlanmamış olmasına rağmen, MSE’ın bu zararlı programları tespit etmesine olanak sağlar. MSE’nin veritabanı, çıkan yeni virüsler için sürekli güncellenmekte, ancak programın imzalarını kontrol etmek her zaman virüsleri yakalamaya yeterli olamıyacağı için, Microsoft Security Essentials kontrol edilecek programların makina dilindeki halini belirli kalıplara uyup uymadığını da kontrol etmektedir. Mesela bir dosyayı tararken, dosya eğer signature testinden geçerse yine de kalıp kontrolünü yapar ve malware yapılarıyla bir benzerlik varsa kullanıcıyı bu dosyanın zararlı bir dosya olabileceği konusunda uyarır.
Microsoft Security Essentials‘ın virüs tarama özellikleri bunlar ile kısıtlı kalmıyor. Tanınmamak için kendisini her seferinde değişik biçimlere sokan çok kompleks malware’lara karşı da önlemler alınmış durumda. Arka planda çalışan motoru sayesinde usb memory sticklerini, CD veya DVD’leri tarayarak bilgisayarın hem sanal olarak hem fiziksel olarak sürekli korumasını sağlar.
Microsoft Security Essentials ile Windows işletim sistemini çok daha güvenilir bir ortam haline getirilmesi mümkün.

Microsoft Security Essentials’ın henüz ilk public betasında bu performansı sağlayabilmesi, gelecekte çıkacak olan release versiyonundan beklenenleri arttıracaktır. Windows işletim sistemlerinin popülerliği göz önünde bulundurularak yapılan Microsoft Security Essentials’ın, güçlü bir anti-malware programı olmasınının yanında, basit arayüzü ve kolay öğrenilebilir kullanımı sayesinde kullanıcı dostu olması, onu alanında en üst sıralara taşıyor.

DOWNLOAD

Bu yazımızda web güvenliği testlerinde otomasyon gereksinimi ve rakamlar ile web uygulaması testleri konularını ele alıyoruz.

Yeni gelen teknolojilerin bir çoğu ilk başlarda çok güvensiz olur. Kimsenin firewall kullanmadığı, kimsenin kablosuz ağına şifre koymadığı, bir exploit’ in internetin 1/4’ ünü etkilediği zamanları görüp geçirdik. Aynı bunun gibi her üç sitenin ikisinde SQL Injection, Cross-site Scripting olduğu günleri de geride bıraktık diyebiliriz.

Tüm ağlar, işletim sistemleri bir gecede güvenli olmadı ama git gide insanların bilinçlenmesi , “firewall”, “otomatik güncelleme” gibi şeylerin standart hale gelmesi ile genel olarak çok daha güvenli sistemler ile karşılaşmaya başladık. Tabii ki bu sistemlerin basit saldırılara karşı güvenli olması tüm güvenlik açıklarının yok olduğu anlamına da gelmiyor, hala güvenlik açıkları var ama daha zor yerlerdeler.

Web de benzer bir geçiş sürecinden nasibini aldı. Daha güvenli web dilleri ortaya çıktı, üç sene önce web geliştiricileri XSS (Cross-site Scripting)’in [1] ne olduğunu bilmiyorken bugün web geliştiricisi olmayan kişiler bile en azından bu konuda bir fikir sahibiler. Tabii ki bu bilinçlenmeye katkıda bulunan tüm XSS ve SQL Injection solucanlarının da hakkını vermemiz lazım, onlar sayesinde bu tip sorunlar medayada kendilerine yer buldular [2].

Güvenlik hakkındaki bu genel bilinçlenme bir çok güvenlik açığının oluşmasına engel olmaya başladı. Artık hiç bir sitenin login formunda SQL Injection bulunmuyor ama hala bir çok web uygulamasında “Nümerik” değerler bekleyen SQL cümleciklerinde data tip kontrolü yerine sadece tek tırnaklardan kaçıldığını görebilirsiniz, mesela şu iki SQL cümleciğine bakalım:

1. SELECT * FROM users WHERE name=”’ + SQLSafe(Request(“username”)) + ’”

2. SELECT * FROM users WHERE name=” + SQLSafe(Request(“userid”))

Burada kullanılan SQLSafe() fonksiyonuna bakalım. Programcı MS SQL Server kullandığından tek tırnakları çift tek tırnağa çevirerek SQL Injection’ a karşı kendini koruyor:

Function SQLSafe(input)

input = Replace(“’”,”’’”)

SQLSafe = input

End Function

Bu korunma birinci SQL Query örneğinde güvenli olsa da ikincisinde güvenli değil çünkü SQL Query nümerik olduğundan tırnak içerisinde yazılmamış. Dolayısıyla zaten SQL Injection için tırnak kullanmaya gerek yok. Bunun anlamı bir saldırgan tek tırnak kullanmadan başarılı şekilde bir SQL Injection saldırısı yapabilir.

Burada hala bir güvenlik açığı var ama bulması ve exploit etmesi ” ’ OR ’1’=’1 ” yazmaktan daha zor.

Güvenlik açısından baktığımızda üç tip site görebiliriz:

1. Güvenli Siteler
2. Güvensiz Siteler
3. Güvenli olduğunu zanneden siteler

Güvenli olduğunu zannetme genelde şu nedenlerden dolayı oluşur:

1. Web geliştiricisinin güvenlik açığını gerçekten anlamamış olması ama hasbel kader ne olduğunu bilmesi.
2. Geliştiricinin potansiyel bir güvenlik açığını görmüş olması ama exploit edilemeyeceğini düşünmesi, bunun ana nedeni kendisinin bu açığı exploit edememiş olmasıdır. O edemediyse kimse edemez (!), değil mi?
3. Kullandıkları web dilinin ya da framework’ ünün onlar için tüm güvenlik işlerini hallettiğini sanması. Bu SSL’ in tüm güvenlik dertlerinizi çözeceğine inanmanız kadar komik bir şey.

Bunun harici kriptoloji, WAF (Web Uygulaması Firewall’ı) vs. gibi şeylerin sistemlerini bir gecede güvenli yapacağına inanan kişiler de var, onlar başka bir yazı konusu…

Rakamlar ile Web Uygulaması Testi

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ı olarak (white-box testing) test etmekten çok daha farklı bir iş.

Tam anlamı [3] 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

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

Bunun anlamı sitedeki her dinamik girdi için 96 farklı deneme yapmazsanız sistemi gerçekten yeterli şekilde test ettiğinizden emin olmazsınız demek. Vasat bir sitede 50 dinamik parametre görebilirsiniz, eğer karşıdaki veritabanını da bilmiyorsanız, diğer veritabanları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 [4].

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 tutma olasılığı olan açıkları dener.

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

Burada üç genel çözüm var:

1. Güvenli yazılım geliştirmek
2. White-Box (açık kutu, sisteme erişerek) güvenlik testi yapmak [5].
3. Testleri otomatikleştirmek

Aslında bu üçünü birbirlerinden ayırmak yanlış olur nitekim bunların hepsini en verimli oranlarda yaparak (vakit – para) – güvenlik üçlüsünde güzel bir oranı yakalayabilirsiniz.

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 sorun var. Güvenlik testlerinin otomatikleştirilebilecek kısımları otomatikleştirilmeli ve güvenlik uzmanları da değerli vakit ve beyinlerini daha çok otomatik olarak tespit edilemeyecek açıkları tespit etmek için kullanmalılar.

Buradaki en kritik noktalardan biri otomatize eden aracın verimliliğidir. Web uygulamalarının komplike ve değişken yapısı, Web 2.0, AJAX ve 3rd parti yazılım çılgınlığı sayesinde her gün daha da komplike hale geliyor. Bu durumda araçlar da gereken verimi veremeyebiliyorlar, güvenlik testi yapan kişi aracın tam olarak neyi yapıp neyi yapamadığını bilmediğinden dolayı ilgili araçtansa kendi altıncı hissine daha çok güveniyor.

Bu maalesef güvenlik testi otomasyonunda uzunca bir süre daha çözülemeyek konulardan biri gibi. Muhtemel ki yakında daha çok güvenlik testi yapan kişi ile otomasyonu yapan aracın bire bir ilişkisinin yükseldiği araçlar göreceğiz.

Hatta “kullanıcı haklarına” ilişkin açıkları anlayabilen, siz siteyi gezerken girdiğiniz bir şifrenin sitenin başka bir yerinde bir hidden input içerisinde base64 ile encode edilmiş olduğunu tespit edebilen, çok adımlı formların adımlarını anlayabilip, adımları geçmeyi deneyen araçlar görebiliriz, hatta görmeliyiz. Aksi takdirde kendimizi yeni açıkların da listeye eklenmesi ile otomasyon olmadan içinden çıkılması mümkün olmayan bir yerde bulacağız.

[1] 2003’te Drupal’in geliştiricilerine bir XSS açığı bildirdiğimde, bana “XSS nedir?”, “Sitede Javascript çalışması neden zararlı olsun ki?” gibi bir e-mail atmışlardı.
[2] Burayı okur okumaz insanlara CSRF’nin ne kadar önemli bir açık olduğunu anlatma amaçlı bir solucan yazmaya karar vermediniz değil mi?
[3] Bir parametreye tek tırnak koyduğunuzda bir SQL Injection hatası almıyorsanız bu o sitenin güvenli olduğuna gelmez.
[4] Mesela farklı bir sistemde sizin girdiniz ile her akşam çalışan bir SQL Query’sinde SQL Injection varsa?
[5] Aslında bu da çok süper bir çözüm değil gerçek ve büyük bir sistem ile karşılaştığınız da kaynak kod güvenlik analizlerinin aylarca süreceğiniz görebilirsiniz.

http://dergi.webguvenligi.org/websec/3-web-guvenliginde-otomasyon.wgt