sql injection testing tutorial example
SQL Enjeksiyon Örnekleri ve Web Uygulamalarında SQL Enjeksiyon Saldırılarını önlemenin yolları
Bir web sitesini veya sistemi test ederken, test uzmanının amacı, test edilen ürünün mümkün olduğunca çok korunup korunmadığından emin olmaktır.
Güvenlik Testi genellikle bu amaçla yapılır. Bu tür bir testi gerçekleştirmek için, öncelikle hangi saldırıların meydana gelme olasılığı en yüksek olduğunu düşünmemiz gerekir. SQL Enjeksiyonu bu saldırılardan biridir.
SQL Enjeksiyonu, sisteminize ve hassas verilerinize ciddi ve zararlı sonuçlar getirebileceği için en yaygın saldırılardan biri olarak kabul edilir.
Ne öğreneceksin:
- SQL Enjeksiyonu Nedir?
- SQL Enjeksiyonunun Riskleri
- Bu Saldırının Özü
- Önerilen Araç
- Web Uygulamalarının SQL Enjeksiyonuna Karşı Güvenlik Testi
- Bu Saldırının Savunmasız Parçaları
- SQL Enjeksiyon Testlerini Otomatikleştirme
- Diğer Saldırılarla Karşılaştırma
- Sonuç
- Önerilen Kaynaklar
SQL Enjeksiyonu Nedir?
Kullanıcı girdilerinin bazıları çerçevelemede kullanılabilir SQL İfadeleri bunlar daha sonra uygulama tarafından veritabanında yürütülür. Bir uygulamanın kullanıcı tarafından verilen girdileri düzgün bir şekilde işlememesi mümkündür.
Eğer durum buysa, kötü niyetli bir kullanıcı, daha sonra veritabanında SQL ifadelerini çerçevelemek ve yürütmek için kullanılan uygulamaya beklenmedik girdiler sağlayabilir. Buna SQL Enjeksiyonu denir. Böyle bir eylemin sonuçları endişe verici olabilir.
Adından da anlaşılacağı gibi, SQL Enjeksiyon saldırısının amacı kötü niyetli SQL kodunu enjekte etmektir.
Bir web sitesinin her alanı, veritabanına açılan bir kapı gibidir. Oturum açma formunda, kullanıcı oturum açma verilerini girer, arama alanına kullanıcı bir arama metni girer, veri kaydetme formuna kullanıcı kaydedilecek verileri girer. Belirtilen tüm bu veriler veri tabanına gider.
Doğru veriler yerine, herhangi bir kötü amaçlı kod girilirse, veri tabanında ve tüm sistemde bazı ciddi hasarların olması ihtimali vardır.
SQL Enjeksiyonu, SQL programlama dili ile gerçekleştirilir. Veritabanında tutulan verilerin yönetimi için SQL (Yapılandırılmış Sorgu Dili) kullanılır. Bu nedenle, bu saldırı sırasında, bu programlama dili kodu kötü amaçlı bir enjeksiyon olarak kullanılmaktadır.
Veritabanları neredeyse tüm teknolojiler için kullanıldığından, bu en popüler saldırılardan biridir.
Birçok uygulama bir tür Veritabanı kullanır. Test edilmekte olan bir uygulama, aşağıdaki görevleri gerçekleştirmek için kullanılan kullanıcı girişini kabul eden bir kullanıcı arayüzüne sahip olabilir:
# 1) İlgili saklanan verileri kullanıcıya gösterin, örn. uygulama, kullanıcı tarafından girilen oturum açma bilgilerini kullanarak kullanıcının kimlik bilgilerini kontrol eder ve yalnızca ilgili işlevselliği ve verileri kullanıcıya sunar
#iki) Kullanıcı tarafından girilen verileri veritabanına kaydedin, örn. Kullanıcı bir formu doldurup gönderdikten sonra, uygulama verileri veritabanına kaydetmeye devam eder; Bu veriler daha sonra aynı oturumda ve sonraki oturumlarda kullanıcıya sunulur
SQL Enjeksiyonunun Riskleri
Günümüzde verilerin bir yerde saklanması gerektiğinden, hemen hemen tüm sistemler ve web siteleri için bir veritabanı kullanılmaktadır.
Hassas veriler veritabanında saklandığı için, sistemin güvenliğinde daha fazla risk söz konusudur. Herhangi bir kişisel web sitesi veya blogun verileri çalınırsa, bankacılık sisteminden çalınacak verilere kıyasla çok fazla hasar olmayacaktır.
Bu saldırının temel amacı sistemin veritabanını hacklemektir, bu nedenle bu saldırının sonuçları gerçekten zararlı olabilir.
Aşağıdaki şeyler SQL Enjeksiyonundan kaynaklanabilir
- Başkasının hesabını ele geçirmek.
- Web sitesinin veya sistemin hassas verilerini çalmak ve kopyalamak.
- Sistemin hassas verilerini değiştirme.
- Sistemin hassas verilerini silme.
- Kullanıcı uygulamaya yönetici olarak bile başka bir kullanıcı olarak giriş yapabilir.
- Kullanıcı, diğer kullanıcılara ait özel bilgileri görebilir, örn. diğer kullanıcıların profillerinin ayrıntıları, işlem ayrıntıları vb.
- Kullanıcı, uygulama yapılandırma bilgilerini ve diğer kullanıcıların verilerini değiştirebilir.
- Kullanıcı, veritabanının yapısını değiştirebilir; hatta uygulama veritabanındaki tabloları silebilirsiniz.
- Kullanıcı, veritabanı sunucusunun kontrolünü ele alabilir ve istediği zaman üzerinde komutları çalıştırabilir.
Bir veritabanını veya verilerini geri yüklemek çok maliyetli olabileceğinden, yukarıda listelenen riskler gerçekten ciddi kabul edilebilir. Kayıp verileri ve sistemi geri yüklemek, şirketinizin itibarına ve parasına mal olabilir. Bu nedenle, sisteminizi bu tür saldırılara karşı korumanız ve Güvenlik Testini ürününüzün ve şirketinizin itibarına iyi bir yatırım olarak düşünmeniz şiddetle önerilir.
Bir test uzmanı olarak, olası saldırılara karşı test yapmanın iyi bir uygulama olduğunu söylemek isterim. Güvenlik Testi planlanmadı. Bu şekilde ürünü beklenmedik durumlara ve kötü niyetli kullanıcılara karşı koruyabilir ve test edebilirsiniz.
Bu Saldırının Özü
Daha önce de belirtildiği gibi, bu saldırının özü, kötü amaçlı bir amaçla veri tabanını hacklemektir.
Bu Güvenlik Testini gerçekleştirmek için, öncelikle, savunmasız sistem parçalarını bulmanız ve ardından bunlar aracılığıyla veritabanına kötü amaçlı SQL kodu göndermeniz gerekir. Bu saldırı bir sistem için mümkünse, uygun zararlı SQL kodu gönderilir ve veri tabanında zararlı eylemler gerçekleştirilebilir.
Bir web sitesinin her alanı, veritabanına açılan bir kapı gibidir. Genellikle sistemin veya web sitesinin herhangi bir alanına girdiğimiz herhangi bir veri veya girdi veritabanı sorgusuna gider. Bu nedenle, doğru veri yerine herhangi bir kötü amaçlı kod yazarsak, veritabanı sorgusunda çalıştırılabilir ve zararlı sonuçlar doğurabilir.
Önerilen Araç
# 1) Kiuwan
SDLC'nin her aşamasında kodunuzda SQL enjeksiyonu gibi güvenlik açıklarını kolayca bulun ve düzeltin. Kiuwan, OWASP, CWE, SANS 25, HIPPA ve daha fazlası dahil olmak üzere en katı güvenlik standartlarıyla uyumludur.
Geliştirme sırasında anında geri bildirim almak için Kiuwan'ı IDE'nize entegre edin. Kiuwan, tüm büyük programlama dillerini destekler ve önde gelen DevOps araçlarıyla entegre olur.
=> Kodunuzu ücretsiz tarayın
Bu saldırıyı gerçekleştirmek için uygun bir veritabanı sorgusunun eylemini ve amacını değiştirmemiz gerekiyor. Bunu gerçekleştirmenin olası yöntemlerinden biri, sorguyu her zaman doğru yapmak ve bundan sonra kötü amaçlı kodunuzu eklemektir. Veritabanı sorgusunu her zaman doğru olarak değiştirmek, ‘veya 1 = 1; - gibi basit bir kodla yapılabilir.
Test uzmanları, sorguyu her zaman doğru olarak değiştirmenin gerçekleştirilip gerçekleştirilemeyeceğini kontrol ederken, tek ve çift olmak üzere farklı tekliflerin denenmesi gerektiğini akılda tutmalıdır. Bu nedenle, 'veya 1 = 1; - gibi bir kodu denediysek, kodu çift tırnak işareti ile de denemeliyiz 'veya 1 = 1; -.
Örneğin, Veritabanı tablosunda girilen kelimeyi arayan bir sorgumuz olduğunu düşünelim:
nt nt notlarından * öğesini seçin, burada nt.subject = ‘arama_sözcüğü’;
Bu nedenle, arama kelimesi yerine, bir SQL Enjeksiyon sorgusu 'veya 1 = 1; - girersek, sorgu her zaman doğru olacaktır.
nt.subject = ‘’ veya 1 = 1 olan notlardan * öğesini seçin; -
Bu durumda, 'konu' parametresi alıntı ile kapatılır ve sonra kodumuz veya 1 = 1 olur, bu da bir sorguyu her zaman doğru yapar. '-' işaretiyle, çalıştırılmayacak olan sorgu kodunun geri kalanına yorum yaparız. Sorguyu kontrol etmeye başlamanın en popüler ve en kolay yollarından biridir.
Sorguyu her zaman doğru yapmak için birkaç başka kod da kullanılabilir, örneğin:
- 'Veya' abc '=' abc '; -
- 'Veya' '=' '; -
Buradaki en önemli kısım, virgül işaretinden sonra çalıştırılmasını istediğimiz herhangi bir kötü amaçlı kodu girebilmemizdir.
Örneğin, 'veya 1 = 1 olabilir; tablo notlarını bırakın; -
Bu enjeksiyon mümkünse, başka herhangi bir kötü amaçlı kod yazılabilir. Bu durumda, yalnızca kötü niyetli kullanıcının bilgi ve niyetine bağlı olacaktır. SQL Enjeksiyonu Nasıl Kontrol Edilir?
Bu güvenlik açığının kontrol edilmesi çok kolay bir şekilde gerçekleştirilebilir. Bazen test edilen alanlara 'veya' oturum açmanız yeterlidir. Herhangi bir beklenmedik veya olağanüstü mesaj döndürürse, o alan için SQL Enjeksiyonunun mümkün olduğundan emin olabiliriz.
Örneğin , Arama sonucu olarak 'Dahili Sunucu Hatası' gibi bir hata mesajı alırsanız, bu saldırının sistemin o bölümünde yapılabileceğinden emin olabiliriz.
Olası bir saldırıyı bildirebilecek diğer sonuçlar şunları içerir:
- Boş sayfa yüklendi.
- Hata veya başarı mesajı yok - işlevsellik ve sayfa girişe tepki vermiyor.
- Kötü amaçlı kod için başarı mesajı.
Bunun pratikte nasıl çalıştığına bir göz atalım.
Örneğin, Uygun bir oturum açma penceresinin SQL Enjeksiyonu için savunmasız olup olmadığını test edelim. Bu amaçla, e-posta adresi veya şifre alanına, aşağıda gösterildiği gibi işaret yazmamız yeterlidir.
Bu tür bir girdi, 'Dahili Sunucu Hatası' hata mesajı gibi bir sonuç veya listelenen herhangi bir uygunsuz sonuç verirse, bu saldırının bu alan için mümkün olduğundan neredeyse emin olabiliriz.
Çok zor SQL Enjeksiyon kodu da denenebilir. Belirtmek isterim ki, kariyerimde işaretin bir sonucu olarak 'Dahili Sunucu Hatası' mesajı olduğunda herhangi bir durumla karşılaşmadım, ancak bazen alanlar daha karmaşık SQL kodu için tepki vermedi.
Bu nedenle, SQL Enjeksiyonunu tek bir alıntıyla kontrol etmek, bu saldırının mümkün olup olmadığını kontrol etmenin oldukça güvenilir bir yoludur.
Tek alıntı uygunsuz bir sonuç vermezse, çift tırnak işareti girmeyi deneyebilir ve sonuçları kontrol edebiliriz.
Ayrıca, sorguyu her zaman doğru olarak değiştirmek için SQL kodu, bu saldırının mümkün olup olmadığını kontrol etmenin bir yolu olarak düşünülebilir. Parametreyi kapatır ve sorguyu 'true' olarak değiştirir. Bu nedenle, doğrulanmazsa, bu tür bir girdi beklenmedik bir sonucu da döndürebilir ve aynı şekilde bu saldırının bu durumda mümkün olduğunu bildirebilir.
Olası SQL saldırılarının kontrolü, web sitesinin bağlantısından da yapılabilir. Bir web sitemizin bağlantısının olduğunu varsayalım: http://www.testing.com/books=1 . Bu durumda, 'kitaplar' bir parametredir ve '1' değeridir. Sağlanan bağlantıya 1 yerine 'işaret' yazarsak, olası Enjeksiyonu kontrol ederdik.
Bu nedenle bağlantı http://www.testing.com/books= web sitesi için SQL saldırısı mümkünse test gibi olacak http://www.testing.com ya da değil.
Bu durumda, eğer bağlantı http://www.testing.com/books= 'Dahili Sunucu Hatası' gibi bir hata mesajı veya boş bir sayfa veya başka bir beklenmedik hata mesajı verir, o zaman o web sitesi için SQL Enjeksiyonunun mümkün olduğundan emin olabiliriz. Daha sonra, web sitesinin bağlantısı yoluyla daha karmaşık SQL kodu göndermeyi deneyebiliriz.
Bu saldırının web sitesinin bağlantısı üzerinden mümkün olup olmadığını kontrol etmek için 'veya 1 = 1; - gibi kodlar da gönderilebilir.
Deneyimli bir yazılım testçisi olarak, sadece beklenmedik hata mesajlarının bir SQL Enjeksiyon zafiyeti olarak değerlendirilemeyeceğini hatırlatmak isterim. Birçok test görevlisi olası saldırıları yalnızca hata mesajlarına göre kontrol eder.
Ancak unutulmamalıdır ki hiçbir doğrulama hata mesajı veya kötü amaçlı kod için başarı mesajı da bu saldırının mümkün olduğuna dair bir işaret olamaz.
Web Uygulamalarının SQL Enjeksiyonuna Karşı Güvenlik Testi
Web uygulamalarının güvenlik testi basit örneklerle açıklanmıştır:
Bu güvenlik açığı tekniğine izin vermenin sonuçları ciddi olabileceğinden, bu saldırının bir uygulamanın güvenlik testi sırasında test edilmesi gerektiği sonucu çıkar. Şimdi bu tekniğe genel bir bakışla, SQL enjeksiyonunun birkaç pratik örneğini anlayalım.
Önemli: Bu SQL Enjeksiyon Testi yalnızca test ortamında test edilmelidir.
Uygulamanın bir oturum açma sayfası varsa, uygulamanın aşağıdaki ifade gibi dinamik SQL kullanması mümkündür. Bu ifadenin, SQL deyiminde girilen kullanıcı adı ve parolanın olduğu bir satır olduğunda sonuç kümesi olarak Kullanıcılar tablosundaki kullanıcı ayrıntılarını içeren en az tek bir satır döndürmesi beklenir.
SEÇİN * Kullanıcılardan NEREDE User_Name = ‘” & strUserName & “‘ AND Password = ’” & strPassword & '’; '
Test kullanıcısı strUserName (kullanıcı adı metin kutusuna) olarak John ve strPassword (parola için metin kutusuna) olarak Smith girerse, yukarıdaki SQL ifadesi şöyle olur:
SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;
Test kullanıcısı John’u strUserName olarak girerse ve strPassword girmezse, SQL ifadesi şu olur:
SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;
SQL ifadesinin John'dan sonraki kısmının yoruma dönüştürüldüğüne dikkat edin. Kullanıcılar tablosunda John kullanıcı adına sahip herhangi bir kullanıcı varsa, uygulama test edenin John kullanıcısı olarak oturum açmasına izin verebilir. Test cihazı artık John kullanıcısının özel bilgilerini görüntüleyebilir.
Test kullanıcısı, uygulamanın mevcut herhangi bir kullanıcısının adını bilmiyorsa ne olur? Böyle bir durumda, test uzmanı yönetici, yönetici ve sistem yöneticisi gibi yaygın kullanıcı adlarını deneyebilir. Veritabanında bu kullanıcılardan hiçbiri yoksa, test eden kişi strUserName olarak John 'veya' x '=' x ve strPassword olarak Smith 'veya' x '=' x girebilir. Bu, SQL ifadesinin aşağıdaki gibi olmasına neden olur.
SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;
'X' = 'x' koşulu her zaman doğru olduğundan, sonuç kümesi Kullanıcılar tablosundaki tüm satırlardan oluşur. Uygulama, test edenin Kullanıcılar tablosundaki ilk kullanıcı olarak oturum açmasına izin verebilir.
Önemli: Test uzmanı, aşağıdaki saldırıları denemeden önce veritabanı yöneticisinden veya geliştiriciden söz konusu tabloyu kopyalamasını istemelidir.
Test kullanıcısı John’a girerse; DROP tablosu users_details; ’- strUserName ve strPassword olarak herhangi bir şey, SQL ifadesi aşağıdaki gibi olur.
SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';
Bu ifade, 'users_details' tablosunun veritabanından kalıcı olarak silinmesine neden olabilir.
Yukarıdaki örnekler, SQL enjeksiyon tekniğini yalnızca oturum açma sayfasını kullanmayı ele alsa da, test uzmanı bu tekniği uygulamanın metin biçiminde kullanıcı girişini kabul eden tüm sayfalarında test etmelidir, ör. arama sayfaları, geri bildirim sayfaları vb.
SSL kullanan uygulamalarda SQL enjeksiyonu mümkün olabilir. Bir güvenlik duvarı bile uygulamayı bu tekniğe karşı koruyamayabilir.
Bu saldırı tekniğini basit bir şekilde anlatmaya çalıştım. Bu saldırının yalnızca bir test ortamında test edilmesi gerektiğini ve geliştirme ortamında, üretim ortamında veya başka herhangi bir ortamda test edilmemesi gerektiğini tekrarlamak istiyorum.
test senaryosu excel ücretsiz indir
Uygulamanın SQL saldırısına karşı savunmasız olup olmadığını manuel olarak test etmek yerine, bir Web Güvenlik Açığı Tarayıcısı bu güvenlik açığını kontrol eder.
İlgili okuma: Web Uygulamasının güvenlik testi . Farklı web güvenlik açıkları hakkında daha fazla ayrıntı için bunu kontrol edin.
Bu Saldırının Savunmasız Parçaları
Test sürecine başlamadan önce, her samimi test uzmanı aşağı yukarı hangi parçaların bu saldırıya karşı en savunmasız olduğunu bilmelidir.
Ayrıca sistemin hangi alanının tam olarak ve hangi sırayla test edileceğini planlamak da iyi bir uygulamadır. Test kariyerimde, bazı alanlar gözden kaçabileceği için alanları rastgele SQL saldırılarına karşı test etmenin iyi bir fikir olmadığını öğrendim.
Veritabanında bu saldırı gerçekleştirildiği için, tüm veri giriş sistemi parçaları, giriş alanları ve web sitesi bağlantıları savunmasızdır.
Savunmasız parçalar şunları içerir:
- Giriş alanları
- Arama alanları
- Yorum alanları
- Diğer veri girişi ve kaydetme alanları
- Web sitesinin bağlantıları
Bu saldırıya karşı test ederken yalnızca bir veya birkaç alanı kontrol etmenin yeterli olmadığını fark etmek önemlidir. Oldukça yaygındır, bir alan SQL Enjeksiyonuna karşı korunabilir, ancak diğerinde korunmaz. Bu nedenle, web sitesinin tüm alanlarını test etmeyi unutmamak önemlidir.
SQL Enjeksiyon Testlerini Otomatikleştirme
Test edilen bazı sistemler veya web siteleri oldukça karmaşık olabileceğinden ve hassas veriler içerebileceğinden, manuel olarak test etmek gerçekten zor olabilir ve çok zaman alır. Bu nedenle, bu saldırıya karşı özel araçlarla test etmek bazen gerçekten yardımcı olabilir.
Böyle bir SQL Enjeksiyon aracı SABUN UI . API düzeyinde otomatik regresyon testlerimiz varsa, bu aracı kullanarak bu saldırıya karşı denetimi de değiştirebiliriz. SOAP UI aracında, bu saldırıya karşı kontrol etmek için önceden hazırlanmış kod şablonları vardır. Bu şablonlar ayrıca kendi yazılı kodunuzla desteklenebilir.
Oldukça güvenilir bir araçtır.
Ancak, bir testin zaten API düzeyinde otomatikleştirilmesi gerekir ki bu o kadar kolay değildir. Otomatik olarak test etmenin başka bir olası yolu, çeşitli tarayıcı eklentileri kullanmaktır.
Otomatikleştirilmiş araçlar zamandan tasarruf etse bile, her zaman çok güvenilir olarak görülmediklerini belirtmek gerekir. Bir bankacılık sistemini veya çok hassas verileri olan herhangi bir web sitesini test ediyorsak, manuel olarak test etmeniz şiddetle tavsiye edilir. Kesin sonuçları görebileceğiniz ve analiz edebileceğiniz yer. Ayrıca bu durumda hiçbir şeyin atlanmadığından emin olabiliriz.
Diğer Saldırılarla Karşılaştırma
SQL Injection, veritabanını etkilediği ve verilerinize ve tüm sisteme ciddi zararlar verebileceği için en ciddi saldırılardan biri olarak düşünülebilir.
Elbette, her ikisi de istemci tarafında gerçekleştirildiğinden, bir Javascript Enjeksiyonu veya HTML Enjeksiyonundan daha ciddi sonuçlara sahip olabilir. Karşılaştırma için, bu saldırı ile tüm veritabanına erişebilirsiniz.
Bu saldırıya karşı test etmek için oldukça iyi SQL programlama dili bilgisine sahip olmanız ve genel olarak veritabanı sorgularının nasıl çalıştığını bilmeniz gerektiği belirtilmelidir. Ayrıca bu enjeksiyon saldırısını gerçekleştirirken daha dikkatli ve dikkatli olmalısınız, çünkü herhangi bir yanlışlık SQL açıkları olarak bırakılabilir.
Sonuç
Umarım SQL Enjeksiyonunun ne olduğu ve bu saldırıları nasıl önlememiz gerektiği konusunda net bir fikriniz olur.
Ancak, veritabanı içeren bir sistem veya web sitesi test edilirken her seferinde bu tür saldırılara karşı test yapılması şiddetle tavsiye edilir. Herhangi bir kalan veritabanı veya sistem güvenlik açıkları, bir şirketin itibarına ve tüm sistemi geri yüklemek için çok fazla kaynağa mal olabilir.
Bu enjeksiyona karşı yapılan testler en çok önemli güvenlik açıkları , ayrıca bilginize ve test araçlarınıza yatırım yapmanız önerilir.
Güvenlik Testi planlanıyorsa, SQL Enjeksiyonuna karşı test, ilk test parçalarından biri olarak planlanmalıdır.
Herhangi bir tipik SQL Enjeksiyonuna rastladınız mı? Aşağıdaki yorumlar bölümünde deneyimlerinizi paylaşmaktan çekinmeyin.
Önerilen Kaynaklar
- HTML Enjeksiyon Eğitimi: Örneklerle Türler ve Önleme
- En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
- Yeni Başlayanlar İçin Derinlemesine Tutulma Öğreticileri
- Yıkıcı Muayene ve Tahribatsız Muayene Eğitimi
- Primer e-Kitap İndirmeyi Test Etme
- Fonksiyonel Test ve Fonksiyonel Olmayan Test
- SOA Test Eğitimi: SOA Mimari Modeli İçin Test Metodolojisi
- Araçlar ve Örneklerle İkili Test veya Tüm Çiftler Testi Eğitimi