Neler yeni
Bughane Academy

Bughane Academy, bug bounty, web güvenliği ve sızma testi alanında kendini geliştirmek isteyenler için kurulmuş Türkçe odaklı bir topluluktur.

Burada; gerçek güvenlik açıkları, recon ve exploit teknikleri, payload & bypass yöntemleri, araçlar, scriptler ve write-up’lar topluluk tarafından paylaşılır ve tartışılır.

Birlikte öğren, birlikte üret, birlikte güçlen.

Manuel SQL Injection’dan Admin Ele Geçirmeye | SQLite İstismarı, Hash Analizi ve Cookie Manipülasyonu

Katılım
10 Ocak 2026
Mesajlar
5
Tepkime puanı
12
Puan
3

Manuel SQL Injection’dan Admin Ele Geçirmeye​


SQLite İstismarı, Hash Analizi ve Cookie Manipülasyonu​


Bu çalışmada basit gibi görünen bir input alanının nasıl zincirleme şekilde tam yönetici ele geçirilmesine dönüştüğünü göstereceğim. Tek başına kritik görünmeyen zafiyetlerin nasıl birleşerek ciddi bir etkiye yol açtığını adım adım inceleyeceğiz. Senaryoda SQL injection, veritabanı keşfi, parola hash analizi ve cookie manipülasyonu birlikte kullanıldı. Aslında bu yazı tek bir açıkla ilgili değil; zafiyet zinciriyle ilgili.

Injection Noktasını Nasıl Tespit Ettim?​

Uygulamada iki temel alan vardı:
  • Login formu
  • “Home” bölümünde item isteyen bir input alanı

Ekran görüntüsü 2026-02-14 140932.jpg

Öncelikle login tarafında klasik bypass denemeleri yaptım ancak sonuç alamadım. Bu kısım ya filtrelenmişti ya da parametrik sorgu kullanıyordu. Ancak item input alanı farklı tepki verdi. Bu alana tek tırnak (') gönderdiğimde doğrudan bir veritabanı hatası aldım. Bu benim için kritik bir sinyaldi çünkü:
  • Girdi doğrudan SQL sorgusuna gömülüyordu.
  • Sorgu string birleştirme yöntemiyle oluşturulmuştu.
  • Hata mesajları bastırılmamıştı.
  • Sanitizasyon yoktu.

Muhtemelen arka planda şöyle bir sorgu vardı:

SQL:
SELECT * FROM products WHERE name = '$input';

Tek tırnak gönderdiğimde string yapısı bozuldu ve syntax hatası oluştu. Bu noktada injection yüzeyini doğrulamış oldum.
Ekran görüntüsü 2026-02-14 141017.jpg

Kolon Sayısını Belirleme Süreci​

UNION tabanlı SQL injection yapabilmem için önce kaç kolon döndürüldüğünü öğrenmem gerekiyordu. Bunun için klasik ORDER BY tekniğini kullandım:
SQL:
' ORDER BY 1 --
' ORDER BY 2 --
' ORDER BY 3 --

1 ve 2 sorunsuz çalıştı. 3. denemede sınır dışı hatası aldım. Bu bana sorgunun 2 kolon döndürdüğünü gösterdi. Artık UNION SELECT payload’larımı iki kolonlu olarak yazmam gerektiğini biliyordum.


Ekran görüntüsü 2026-02-14 141220.jpg

Backend Veritabanını Nasıl Tespit Ettim?​


Bir sonraki adımda veritabanı motorunu anlamaya çalıştım. Şu payload’ı denedim:
SQL:
' UNION SELECT database(),2 --

Dönen hata:
SQL:
No such function: database
Ekran görüntüsü 2026-02-14 141336.jpg

Bu hata MySQL’e ait değil. SQLite’ta database() fonksiyonu bulunmaz.Bu noktada backend’in SQLite olduğunu netleştirdim.Veritabanı motorunu bilmek çok önemli çünkü enumeration yöntemi tamamen değişiyor.



sqlite_master Üzerinden Tablo Keşfi​


SQLite şema bilgilerini sqlite_master adlı tabloda tutar. Bu nedenle şu sorguyu kullandım:

SQL:
' UNION SELECT name,2 FROM sqlite_master WHERE type='table' --



Ekran görüntüsü 2026-02-14 141515.jpg

Tablo isimlerini elde ettim. Listede iki önemli tablo vardı:
  • products
  • users

Hedefim artık belliydi: users tablosu.



Kullanıcı Bilgilerini Çekme​


Şimdi kullanıcı adlarını ve parola hash’lerini çekmem gerekiyordu:

SQL:
' UNION SELECT username,password FROM users --

Ekran görüntüsü 2026-02-14 141713.jpg

Çıktıda iki kullanıcı gördüm:
  • admin
  • jerry
Parolalar SHA-256 ile hash’lenmişti (64 karakterlik hex format). Burada önemli nokta şu: SHA-256 güçlü bir hash algoritmasıdır ancak salting veya adaptive hashing kullanılmadığında parola güvenliği için yeterli değildir. Jerry’nin hash’ini araştırdığımda karşılığının 1qaz2wsx olduğunu gördüm. Zayıf parola kullanımı zincirin bir sonraki halkasını oluşturdu.

Ekran görüntüsü 2026-02-14 141901.jpg

Sisteme Giriş​


Elde ettiğim bilgilerle giriş yaptım:

Kullanıcı adı: jerry
Parola: 1qaz2wsx


Login başarılı oldu.Ancak flag ya da admin içeriği henüz görünmüyordu.Bu noktada injection bitmişti ama yetki yükseltme henüz tamamlanmamıştı.

Cookie Manipülasyonu ve Yetki Yükseltme​

Tarayıcıdaki cookie’leri incelediğimde şunu gördüm:

Kod:
user_id = 2


Bu değer Jerry’ye aitti. Çoğu sistemde admin kullanıcısı ilk oluşturulan hesaptır ve ID’si genellikle 1’dir. Cookie değerini şu şekilde değiştirdim:

Kod:
user_id = 1

Sayfayı yenilediğimde admin içeriği erişilebilir hale geldi. Bu durum, güvensiz oturum yönetimi ile birleşen cookie tabanlı bir yetkilendirme zafiyetidir. Uygulama, kullanıcı kimliğini client-side bir değere güvenerek belirliyordu ve server-side rol doğrulaması yapılmıyordu.
Ekran görüntüsü 2026-02-14 142143.jpg

Sonuç ve Kişisel Değerlendirme​


Bu senaryo bana tekrar şunu gösterdi: Güvenlik tek bir büyük açık meselesi değil. Küçük zafiyetlerin nasıl bağlandığı meselesi. SQL injection burada sadece başlangıçtı. Asıl kritik olan, uygulamanın güven modeliydi.Gerçek dünyadaki ihlaller admin parolasıyla başlamaz. Bazen sadece bir tek tırnakla başlar. Buraya kadar okuduysanız teşekkür ederim.
Tüm süreci adım adım, canlı olarak görmek isterseniz video walkthrough’u buradan izleyebilirsiniz: (Videoyu sonuna kadar izlerseniz sevinirim)


Daha fazla teknik write-up ve uygulamalı laboratuvar içeriği yakında gelecek.


Stay safe and happy hacking. 🚀

YouTube: https://youtube.com/@NullSecurityX
Twitter (X): https://x.com/NullSecurityX
Whatsapp: https://whatsapp.com/channel/0029Vb6Q9I69RZAcE3O1ST2G
 
Geri
Üst