09'
Tasarım
HaCKer'Mys
Hacker
SQL Injection Neden olusur/Nasıl korunur
Bu yazı dizisi temel olarak saldırıya dayalı olduğundan dolayı detaylı korunma ve defans yolları anlatılmamıştır ve bu yazı dizisi etrafında anlatılmayacaktır. Saldırıyı anlamak korunmayı anlamanın en önemli kısımlarından biridir. Yazıda sadece yöntemlere değinilmiş ve ilgili dil-platform implementasyon pratiği okuyucuya bırakılmıştır.SQL Injection açığı neden oluşur ?
SQL Injection şüphe götürmez ki web uygulamalarında yaygınlık / hasar oranı en yüksek açıktır. Muhtemelen exploit etmesi de en eğlenceli ve bazen tahmin edilenden daha zor olan açıktır.
Belirttiğimiz gibi SQL Injection’ ın ana nedeni web uygulamasının kullanıcıdan gelen girdiyi doğru şekilde kontrol etmeden o girdi ile dinamik bir SQL cümleciği oluşturmasından kaynaklanmaktadır.
Bir önceki bölümdeki örnekte dikkat ettiyseniz saldırı girdisi (’) tırnak karakteri ile başlamıştı. Çünkü SQL’ e istediğimiz komutu göndermek için öncelikle string bölümünden (’) tırnak karakteri ile kaçıp daha sonra istediğimiz SQL komutunu SQL cümleciğine ekledik. Burada eklediğimiz komut “OR 1=1” gibi bir komuttu. Bu komut sayesinde SQL cümleciği tüm kayıtları döndürdüğünden dolayı sisteme başarılı bir şekilde giriş yapabilmiştik.
Özetle normalde SQL cümleciğinin yapısını değiştirerek yapması gerekeni değil yapmasını istediğimiz şeyi yaptırdık. Bunun ana nedeni ise SQL cümleciğinin içerisine dışarıdan (’) tırnak karakteri aracılığı ile komut ekleyebilmemizdi.
SQL Injection korunma yoLLarı...
SQL Injection’ dan korunma da iki altın kural vardır.Tüm ****-karakterlerden kaçılmalıdır,
Nümerik olarak beklenen parameterlerin nümerik olup olmadığı kontrol edilmelidir.
Birinci Kural;
Dinamik oluşturulan tüm SQL cümlecikleri **** karakterlerden başarılı bir şekilde kaçmalıdır. Örnek olarak SQL Server için (’) tek tırnak karakterini uygulama (’) iki tek tırnak ile değiştirilmelidir. Bu sayede SQL Server bunun tek tırnak karakteri olduğunu anlayabilir.
İkinci Kural;
Eğer oluşturulacak SQL cümlesi için beklenen data nümerik ise nümerik mi diye kontrol edilmeli eğer ve nümerik değilse uygulama bu datayı kabul etmemelidir.
Saldırının anatomisi anlaşıldıktan sonra defansı gayet basit olacaktır.
SQL cümleciği oluşturulmadan önce SQL cümleciğini oluşturmaya yardımcı olan tüm dinamik dataların beklenen data tiplerine uyup uymamasının kontrol edilmesi. Nümerik beklenen data gerçekten nümerik mi? gibi.String kayıtlarda kesinlikle **** karakterlerden kaçmaParameterized SQL cümlecikleri oluşturmaStored Procedure Kullanma (Stored Procedure lerde güvenli şekilde yazılmalıdır)Whitelisting, Sadece beklenen karakterlerin kabul edilmesi. Mesela isim girilecek bir yerde noktalama işaretlerinin kabul edilmemesi gibi. Whitelisting yapıldıktan sonra gene ****-karakterlerden kaçılmalıdır.Detaylı korunma metotları bu yazı dizisinin konusu dışındadır.
