SQL Injection Nedir, Kendi Sitenizde Nasıl Test Edilir?

Haberci

SEO UZMANI
Yönetici
Katılım
21 May 2023
Mesajlar
539
Tepki
17
Puan
18
810




Bir SQL injection tarama aracını indirip kendi canlı sitenize yöneltmeden önce duraksamak makul bir refleks: yanlış yapılandırılmış bir tarama, üretim veritabanınızda gerçek veriyi bozabilir ya da sunucuyu geçici olarak devre dışı bırakabilir. Ama testi hiç yapmamak da açığı üretimde bırakmak anlamına geliyor.

Bu yazı SQL injection'ın kod seviyesinde nasıl önlendiğini ve kendi sitenizde güvenle nasıl test edilmesi gerektiğini resmî kaynaklardan gösteriyor.

Önce önleme: sorun testte değil kodda başlıyor​


OWASP'ın SQL Injection Prevention Cheat Sheet'ine göre birincil savunma parametreli sorgular (prepared statements): "Parametreli sorgular geliştiriciyi tüm SQL kodunu önce tanımlamaya, ardından her parametreyi sorguya sonradan geçirmeye zorlar." Bu ayrım sayesinde veritabanı motoru kod ile veriyi hiçbir zaman karıştırmıyor; kullanıcı girdisi ne yazarsa yazsın veri olarak kalıyor, çalıştırılabilir komut hâline gelemiyor.

Aynı sayfa, kullanıcı girdisini elle kaçış (escaping) fonksiyonlarıyla temizlemeyi ayrı bir seçenek olarak ele alıyor ama bunu "kesinlikle önerilmez" diye etiketliyor; gerekçe olarak da veritabanına özgü olması ve "tüm durumlarda tüm SQL injection'ları önleyeceğinin garanti edilemeyeceğini" yazıyor. Girdiyi izin verilen değerler listesiyle (allow-list) doğrulamak da tek başına yeterli sayılmıyor: sayfa "doğrulanmış verinin, string birleştirme yoluyla SQL sorgusuna eklenmesi güvenli olmak zorunda değildir" diyor. Yani bir alanı yalnızca rakamla sınırlamak saldırıyı zorlaştırır ama sorgu hâlâ birleştirme yoluyla kuruluyorsa açık kapanmış olmuyor.

PHP tarafında bu nasıl görünüyor?​


PHP'nin resmî kılavuzuna göre PDO ile hazırlanan sorgularda parametreler otomatik olarak işleniyor: "Uygulama yalnızca hazırlanmış sorgular kullanıyorsa, geliştirici hiçbir SQL injection oluşmayacağından emin olabilir." Kılavuz burada iki örneği yan yana koyuyor: `WHERE name = ?` biçimindeki bir yer tutucu güvenli, ama `WHERE name LIKE '%?%'` gibi yer tutucunun bir dizenin parçası olarak kullanılması güvenli değil. İkinci örnekte yer tutucu tam değerin yerini almadığı için veritabanı sürücüsü onu beklendiği gibi işleyemiyor.

Bu ayrım, "biz zaten PDO kullanıyoruz, güvendeyiz" varsayımının her zaman doğru olmadığını gösteriyor; yer tutucunun sorgu içinde nasıl konumlandırıldığı da en az kullanılan API kadar önemli.

Kendi sitenizde testi güvenli hâle getiren üç sınır​


OWASP'ın kendi test rehberi, saldırı tekniklerini değil test metodolojisini ayrı bir belgede ele alıyor; ama önleme sayfasının verdiği çerçeveden hareketle kendi ortamınızda güvenli bir test kurmak için üç sınır koymak gerekiyor:

  • Ortam ayrımı: Tarama, üretim veritabanının bire bir kopyası olan ayrı bir staging ortamında yapılmalı.
  • Yetki sınırı: Test hesabının veritabanı kullanıcısı yalnızca okuma yetkisine sahip olmalı, yazma/silme yetkisi kapatılmalı.
  • Kapsam belgesi: Hangi URL ve parametrelerin test edileceği önceden yazılı olarak belirlenmeli; bu hem yanlışlıkla üretime sızmayı önlüyor hem de barındırma sağlayıcınızla olası bir yetkilendirme anlaşmazlığını baştan çözüyor.

Barındırma sağlayıcınızın kendi sunucusunda böyle bir tarama yapmadan önce hizmet şartlarını kontrol etmek de gerekiyor; bazı paylaşımlı hosting sağlayıcıları otomatik tarama araçlarını saldırı girişimiyle karıştırıp hesabı geçici olarak askıya alabiliyor. Kendi sunucunuzu veya adanmış bir sunucuyu kullanıyorsanız bu risk daha düşük, ama yine de tarama sırasında oluşan yoğun sorgu trafiğinin normal kullanıcı isteklerini yavaşlatabileceğini hesaba katmak gerekiyor; bu yüzden taramayı düşük trafikli bir saatte, mümkünse gece planlamak pratik bir tercih.

Bir açık bulduğunuzda ne yapılır?​


Test sırasında gerçek bir SQL injection açığı bulursanız, sıradaki adım onu hemen düzeltmek değil, önce kapsamı belgelemek: hangi parametre, hangi endpoint, hangi HTTP metodu üzerinden tetikleniyor. Kendi ürününüzde değil bir üçüncü taraf serviste böyle bir açık bulduysanız, bunu nasıl ve kime bildireceğinizi güvenlik açığı bildirim sürecini anlatan başlıkta daha ayrıntılı bulabilirsiniz; sorumlu bildirim (responsible disclosure) süreci, açığı herkese açık paylaşmadan önce satıcıya makul bir düzeltme süresi tanımayı öngörüyor.

Düzeltme sonrası doğrulama nasıl önceliklendirilir?​


Bulunan açığı düzeltip yamaladıktan sonra, bu yamanın hangi aciliyette dağıtılması gerektiğine karar verirken yalnızca "kritik" etiketine bakmak yeterli değil; açığın sizin sisteminizde gerçekten erişilebilir olup olmadığı da önemli. Bu değerlendirmeyi nasıl yapacağınızı CVSS puanının alt bileşenlerini okumayı anlatan yazıda bulabilirsiniz; kendi bulduğunuz SQL injection açıklarını önceliklendirirken de aynı çerçeve işe yarıyor.

Kontrol noktası' Alıntı:
Parametreli sorgu kullanmak yer tutucuyu doğru konuma koymakla eş anlamlı değil; ikisi ayrı ayrı doğrulanmalı.

Genel web güvenliği farkındalığınızı tazelemek isterseniz internet kullanıcılarının dikkat etmesi gereken güvenlik açıklarını özetleyen yazı SQL injection dışındaki yaygın açık türlerine de kısa bir bakış sunuyor.

Sık Sorulan Sorular​


SQL injection nedir?
Kullanıcıdan gelen verinin sorgu metnine doğrudan eklenmesi sonucu, saldırganın sorgunun yapısını değiştirebilmesidir. Sorun verinin kendisinde değil, veriyle komutun aynı metinde birleştirilmesindedir.

SQL injection nasıl önlenir?
Birincil savunma parametreli sorgulardır: veri, sorgu metnine gömülmek yerine ayrı bir parametre olarak gönderilir. Girdi temizleme tek başına yeterli bir savunma sayılmaz.

Kendi siteme SQL injection testi yapmak yasal mı?
Kendinize ait, izniniz olan bir sistemde test yapmak sorun değildir; başkasının sistemine izinsiz test yapmak değildir. Testi üretim ortamında değil, kopya bir ortamda yapmak da veri kaybını önler.

Özetle​


SQL injection'a karşı asıl savunma parametreli sorgulardır; ama parametreli sorgu kullanmak tek başına yeterli değil, yer tutucunun sorgu içinde doğru konumlandırıldığından da emin olunmalı. Kendi sitenizde test yaparken staging ortamı, salt okunur test hesabı ve yazılı kapsam belgesi üç temel sınır olarak kalıyor.

Son SQL injection testinizi üretim ortamında mı, ayrı bir staging ortamında mı yaptınız?

Güncelleme: 24 Ağustos 2026.



Dijital Dünyanıza Yön Veren Pusula
 

Ekli dosyalar

  • banner_04.jpg
    banner_04.jpg
    6.4 KB · Görüntüleme: 0
Geri
Üst