Döküman SQL Sorgusu Nasıl Çalışır ve Açık Tam Olarak Nerede Doğar? Hacker gibi düşün Bölüm 2

Bu bölümde şunları işleyeceğiz:
Ama https://spyhackerz.org/forum/thread...acker-gibi-dusun-bolum-1.159968/#post-3527114 bölüm 1 konusunu okumadan buraya geçiş yapmayın.

• SQL sorgusu nedir, nasıl kurulur?
• SELECT, FROM, WHERE ne işe yarar?
• Kullanıcıdan gelen veri sorguya nasıl eklenir?
• Güvenli ve güvensiz fark tam olarak nerede başlar?
• Hacker neden özellikle sorgunun birleştiği noktaya bakar?

SQL Sorgusu Nasıl Çalışır ve Açık Tam Olarak Nerede Doğar?​

Bir hacker için her şey ekranda başlamaz.
Her şey, arka tarafta kurulan cümlede başlar.


Çünkü bir web uygulaması veritabanıyla konuşurken aslında düz Türkçe değil, mantıklı ve kurallı bir dil kullanır: SQL.


Ve deneyimli biri şunu bilir:

Eğer o cümle yanlış kurulursa, sorun kullanıcıda değil, cümlenin yapısında doğar.

İlk bölümde SQL Injection’ın ne olduğunu gördük.
Şimdi bir adım daha ileri gidiyoruz:


Bu açık tam olarak nerede oluşur?
Sorun tam olarak hangi satırda başlar?
Bir hacker neden ilk bakışta bazı kodları görünce şüphelenir?


İşte bu bölümün derdi bu.

SQL sorgusu aslında nedir?​

SQL sorgusu, uygulamanın veritabanına sorduğu sorudur.


Örneğin bir site, kullanıcıyı bulmak için şunu sorabilir:



SELECT * FROM users WHERE username = 'ali';



Bu sorguyu parçalara ayıralım:

• SELECT → hangi veriyi istiyorum?
• * → tüm sütunları getir
• FROM users → users tablosundan getir
• WHERE username = 'ali' → ama sadece kullanıcı adı ali olanı getir

Bu, veritabanına sorulmuş net bir sorudur.


Yani uygulama aslında şöyle demektedir:

“Users tablosuna git ve bana kullanıcı adı ali olan kişiyi getir.”

Bir hacker bu sorguyu okurken sadece SQL görmez.
Şunu görür:

“Demek ki uygulama kullanıcı adı bilgisini veritabanında arıyor.”

Bir sorgu normalde nasıl oluşur?​

Bir kullanıcı giriş ekranına bir değer yazar.
Mesela:



ali



Uygulama bu değeri alır, sonra sorgunun içine yerleştirir.


En basit haliyle akış şöyledir:



Kullanıcı veri girer → Uygulama bunu alır → Veritabanına sorgu gönderilir



Örnek:



SELECT * FROM users WHERE username = 'ali';



Buraya kadar sorun yok.


Sorun, geliştiricinin bu sorguyu nasıl oluşturduğu ile ilgilidir.


Çünkü SQL Injection, sorgunun var olmasından değil,
yanlış birleştirilmesinden doğar.

Açık tam olarak nerede başlar?​

Şurada başlar:

Kullanıcıdan gelen veri, sorgunun içine güvenli biçimde değil, doğrudan yapıştırıldığında.

Mesela şöyle bir PHP mantığı düşün:



$username = $_POST['username'];
$query = "SELECT * FROM users WHERE username = '" . $username . "'";



İlk bakışta sıradan görünüyor.


Ama hacker burada anında durur.
Çünkü o satırda çok kritik bir şey olmuştur:

• SQL komutu var
• kullanıcı verisi var
• ikisi aynı string içinde birleşmiş

Yani sorgu ile veri birbirinden ayrılmamış.


Bu durumda sistem aslında şöyle çalışıyordur:



SELECT * FROM users WHERE username = 'KULLANICI_GIRDISI';



Ve bir hacker için en önemli yer tam olarak burasıdır:



WHERE username = '...'



Çünkü oraya dışarıdan veri oturuyordur.

Hacker neden özellikle bu noktaya bakar?​

Çünkü o şunu bilir:

Uygulama, benim yazdığım şeyi sorgunun bir parçası haline getiriyorsa, risk burada başlar.

Bir kullanıcı için bu sadece bir kutudur.
Bir hacker için ise bu, sorguya bağlanan bir giriş noktasıdır.


O yüzden hacker şunu sormaz:

“Bu kutuya ne yazsam?”

Önce şunu sorar:

“Benim yazdığım şey sorgunun neresine gidiyor?”

Bu çok büyük farktır.


Çünkü aynı input farklı yerlerde farklı risk taşır.


Örnek 1:



SELECT * FROM users WHERE username = 'ali';

Burada veri, metin alanına gidiyor.


Örnek 2:



SELECT * FROM orders WHERE id = 42;



Burada veri, sayı alanına gidiyor.


Örnek 3:



SELECT id, name, price FROM products ORDER BY price;



Burada veri bazen sorgunun yapısal kısmına bile gidebilir.


İyi bir hacker öğretmeni der ki:

“Önce input’u değil, input’un SQL içindeki görevini anla.”

Basit bir arama kutusu neden tehlikeli olabilir?​

Dışarıdan çok normal görünür:

Ürün ara

Ama arka planda sorgu şöyle olabilir:



SELECT id, name, price
FROM products
WHERE name LIKE '%telefon%';



Bu sorgunun amacı, içinde “telefon” geçen ürünleri bulmaktır.


Peki geliştirici bu sorguyu nasıl kuruyor?


Eğer şöyle yapıyorsa:



search = request.GET["q"]
query = "SELECT id, name, price FROM products WHERE name LIKE '%" + search + "%'"



hacker bunu görünce şunu düşünür:

“Benim verdiğim veri, SQL cümlesinin ortasına yerleştiriliyor.”

Yani sorun arama özelliği değildir.
Sorun, arama metninin güvenli parametre olarak değil, sorgu metninin içine katılmış olmasıdır.

Giriş ekranı neden özel bir risktir?​

Çünkü login ekranı genelde iki kritik veriyle çalışır:

• kullanıcı adı
• şifre

Örneğin sorgu şöyle olabilir:



SELECT * FROM users
WHERE username = 'ali'
AND password = '123456';



Bu sorgu sistem için normaldir.
Ama eğer uygulama bunu şu mantıkla kuruyorsa:



const query =
"SELECT * FROM users WHERE username = '" +
username +
"' AND password = '" +
password +
"'";



o zaman hacker için alarm çalar.


Neden?


Çünkü iki ayrı kullanıcı verisi, sorgu cümlesinin içine ham biçimde katılmıştır.


Bu da şunu gösterir:

• veri ile komut ayrılmamış
• sorgu yapısı dış girdiye açık hale gelmiş
• savunma zayıf olabilir

İşte SQL Injection’ın doğduğu yer burasıdır.

SQL Injection bir “hack anı” değil, bir kodlama hatasıdır​

Bunu çok net anlamak gerekir.


SQL Injection, sihirli bir saldırı tekniği değildir.
Aslında çoğu zaman geliştiricinin yaptığı basit ama tehlikeli bir hatanın sonucudur.


Mesela şu satır:



String sql = "SELECT * FROM invoices WHERE customer_id = " + customerId;



Bir yazılımcı için pratik gibi görünebilir.
Ama hacker için bu satır şunu söyler:

“Burada kullanıcıdan gelen bir değer, sorgu metnine doğrudan eklenmiş.”

Yani hacker bazen uygulamayı kırmadan önce geliştiricinin nerede acele ettiğini fark eder.


Bu yüzden SQLi konusu sadece saldırı değil, aynı zamanda kod disiplini konusudur.

Peki güvenli yaklaşım nasıl görünür?​

İşte oyunu değiştiren yer burasıdır.


Aynı işlem güvenli şekilde yapılacaksa, kullanıcı verisi sorguya yapıştırılmaz.
Ayrı parametre olarak geçirilir.

PHP örneği​

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$stmt->execute(["username" => $username]);

Python örneği​

cursor.execute(
"SELECT * FROM users WHERE username = %s",
(username,)
)

Java örneği​

PreparedStatement ps = conn.prepareStatement(
"SELECT * FROM users WHERE username = ?"
);
ps.setString(1, username);



Burada çok kritik fark şudur:

• SQL komutu sabit
• kullanıcı verisi ayrı
• sistem veriyi komut gibi değil, veri gibi işler

OWASP, parameterized query / prepared statement kullanımını SQL Injection’a karşı temel ve güçlü savunma olarak öneriyor. Çünkü bu yöntem, sorgunun anlamının kullanıcı girdisiyle değişmesini engellemeyi amaçlar. (cheatsheetseries.owasp.org)

Hacker’ın asıl baktığı şey: birleşme noktası​

İyi biri ekranda buton aramaz.
Birleşme noktası arar.


Yani şu anı:



Kullanıcı verisi + SQL cümlesi



Çünkü tehlike orada doğar.


Bu yüzden deneyimli birinin zihninde şu soru döner:

• Veri parametre olarak mı geçiyor?
• Yoksa string birleştirme mi yapılıyor?
• Sorgu sabit mi?
• Input tip kontrolü görüyor mu?
• Bu alan metin mi, sayı mı, sıralama mı?

İşte hacker bakışı budur.
Gösterişli değil, dikkatli.
Hızlı değil, analitik.

Bu bölümde ne öğrendik?​

Bu bölümün sonunda okuyucu şunu net anlamalı:

1. SQL sorgusu, uygulamanın veritabanına sorduğu cümledir.​

Örnek:



SELECT * FROM users WHERE username = 'ali';

2. SQL Injection, bu cümlenin kullanıcı verisiyle yanlış şekilde birleştirilmesinden doğar.​

3. Açığın doğduğu yer genelde string birleştirme yapılan satırlardır.​

Örnek:



$query = "SELECT * FROM users WHERE username = '" . $username . "'";

4. Hacker önce payload’a değil, verinin sorgudaki konumuna bakar.​

5. Güvenli yaklaşımda veri ve komut ayrılır.​

Yani:

• string birleştirme yok
• parameterized query var
• prepared statement var

Bölüm 2 kapanış cümlesi​

Bir hacker SQL sorgusuna bakarken şunu düşünür:

“Sorun veritabanında değil.
Sorun, bu uygulamanın kullanıcıyı sorgunun ne kadar yakınına oturttuğunda.”

Bu konu: spyhackerz.org için yazılmıştır kaynak belirtmeden lütfen paylaşmayın.