Lab: SQL injection attack, listing the database contents on non-Oracle databases

Lab: SQL injection attack, listing the database contents on non-Oracle databases

SQL Injection konusunu öğrenirken bazı lablar vardır ki gerçekten olayın mantığını oturtur. Bu lab da tam olarak öyleydi. Baştan sona ilerlerken sadece payload denemek değil, her adımda neden o yöntemi kullandığımı anlamaya çalıştım. Bu yazıda da süreci aynı şekilde, mantığıyla birlikte anlatıyorum.

Lab Hakkında

Bu senaryoda uygulamanın product category filtresinde bir SQL Injection açığı bulunuyor. Uygulama, sorgu sonuçlarını doğrudan response içinde döndürdüğü için bu açık UNION tabanlı SQL Injection ile sömürülebiliyor.

Amaç oldukça net:

- Kullanıcıların tutulduğu tabloyu bulmak

- Kolon isimlerini çıkarmak

- Kullanıcı adı ve şifreleri elde etmek

- Administrator hesabına giriş yapmak

Her zaman olduğu gibi en basit testle başladım ve input alanına tek tırnak gönderdim:

Uygulama hata verdi. Bu küçük test aslında çok şey söylüyor. Çünkü tek tırnak SQL’de string’i sonlandırır. Eğer uygulama bu karakteri filtrelemiyorsa, sorgu bozulur ve hata alınır.

Buradan şu sonucu çıkardım:

Kullanıcı girdisi doğrudan SQL sorgusuna ekleniyor → SQL Injection mümkün

UNION tabanlı saldırılarda en kritik noktalardan biri, sorgunun kaç kolon döndürdüğünü bilmektir. Bunun için ORDER BY kullandım:

' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 3--

İlk iki deneme sorunsuz çalıştı ama üçüncüde hata aldım. Bunun anlamı:

Sorgu toplam 2 kolon döndürüyor

Bu bilgi olmadan UNION saldırısı zaten ilerlemezdi.

Şimdi sıra UNION’ın çalışıp çalışmadığını test etmekteydi:

' UNION SELECT NULL,NULL--

Burada özellikle NULL kullandım. Çünkü NULL her veri tipine uyum sağlar ve type mismatch hatası almamı engeller.

Payload sorunsuz çalıştı. Bu da şu anlama geliyor:

UNION injection mümkün ve kolon sayısı doğru

Bir adım ileri gidip string veri denedim:

' UNION SELECT NULL,'a'--

Ekranda bu değerleri gördüm. Bu da bana şunu gösterdi:

Her iki kolon da string veri kabul ediyor ve response’a basılıyor

Bir sonraki kritik adım, hangi veritabanı ile çalıştığımı anlamaktı. Çünkü kullanacağım sorgular buna göre değişecek.

' UNION SELECT  NULL,version()--

Gelen sonuç:

PostgreSQL

Bu bilgiyle artık doğru enumeration tekniklerini kullanabilirim.

PostgreSQL’de tablo bilgileri information_schema üzerinden alınır. Bu yüzden şu sorguyu kullandım:

'+UNION+SELECT+table_name,+NULL+FROM+information_schema.tables--

Birçok tablo listelendi ama içlerinden biri hemen dikkat çekti:

users_ddszzs

İsim zaten kendini belli ediyor. Kullanıcı verileri burada tutuluyor.

Artık hedef tablom belli olduğuna göre içindeki kolonları görmek gerekiyordu:

'+UNION+SELECT+column_name,+NULL+FROM+information_schema.columns+WHERE+table_name='users_ddszzs'--

Gelen sonuçlar:

- username_uupbii

- email

- password_okamvy

Bu noktada artık ihtiyacım olan her şey elimdeydi.

Son adımda direkt kullanıcı bilgilerini çektim:

'+UNION+SELECT+username_uupbii,+password_okamvy+FROM+users_ddszzs--

Tüm kullanıcıların username ve password bilgileri response içinde geldi. Aradığım şey ise belliydi: administrator hesabı .

Dump edilen veriler arasından administrator kullanıcısını buldum ve şifresini aldım. Login ekranına gidip bu bilgilerle giriş yaptım.

Ve sonuç:

Admin hesabına erişim sağlandı, lab tamamlandı

Bu lab aslında SQL Injection’ın temel akışını çok net gösteriyor:

- Injection tespiti

- Kolon sayısı belirleme

- UNION ile veri çekme

- Veritabanını tanıma

- Tablo ve kolon enumeration

- Data extraction

Buradaki en önemli nokta şuydu:

Her adım bir öncekine bağlı ve rastgele değil, tamamen mantık üzerine kurulu

SQL Injection öğrenirken en büyük hata payload ezberlemek. Ama asıl olay, hangi durumda neyi neden kullandığını bilmek.

Bu lab bana şunu net öğretti:

Eğer mantığı oturtursan, bilmediğin bir sistemde bile ilerleyebilirsin

Bu yüzden her labda sadece çözmek değil, süreci anlamak çok daha önemli.Bir sonraki labta görüşmek üzere 🌸