Parametreli SQL sorgularının, kullanıcı girdisi içeren sorguları oluştururken kullanıcı girişini sterilize etmenin en iyi yolu olduğunu anlıyorum, ancak kullanıcı girdisi alarak ve tek tırnaklardan kaçarak ve tüm dizeyi tek tırnaklarla çevreleyende neyin yanlış olduğunu merak ediyorum. İşte kod:

sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"

Kullanıcının girdiği herhangi bir tek tırnak, kullanıcının dizeyi bitirme yeteneğini ortadan kaldıran çift tek tırnakla değiştirilir, böylece noktalı virgül, yüzde işareti vb. Yazabilecekleri her şey dizenin bir parçası olur ve aslında komutun bir parçası olarak yürütülmez.

Biz tek tırnak tek dize sınırlayıcı ve dize sınırlayıcı kaçmak için tek yol olduğuna inanıyorum Microsoft SQL Server 2000 kullanıyoruz, bu yüzden kullanıcı yazdığı bir şey yürütmek için hiçbir yolu yoktur.

Buna karşı bir SQL enjeksiyon saldırısı başlatmanın herhangi bir yolunu görmüyorum, ancak bu bana göründüğü kadar kurşun geçirmez olsaydı, başka birinin zaten bunu düşüneceğini ve yaygın bir uygulama olacağını fark ediyorum.

Bu kodda yanlış olan ne? Bu sanitizasyon tekniğini geçmiş bir SQL enjeksiyon saldırısı almanın bir yolu var mı? Bu tekniği kullanan örnek kullanıcı girişi çok yardımcı olacaktır.

GÜNCELLEME:

Hala bu koda karşı etkili bir SQL enjeksiyon saldırı başlatmak için herhangi bir yol bilmiyorum. Birkaç kişi, ters eğik çizginin bir tek tırnaktan kaçacağını ve dizenin geri kalanının SQL komutunun bir parçası olarak yürütülmesini sağlamak için diğerini bırakacağını ve bu yöntemin SQL içine enjekte etmek için çalışacağını fark ettim. bir MySQL veritabanı, ancak SQL Server 2000'de tek bir alıntıdan kaçmanın tek yolu (bulabildiğim) başka bir tek alıntıdır; ters eğik çizgiler bunu yapmayacak.

Ve tek tırnaktan kaçmayı durdurmanın bir yolu yoksa, kullanıcı girdisinin geri kalanının hiçbiri yürütülmeyecektir, çünkü hepsi bir bitişik dize olarak alınacaktır.

Girdiyi sterilize etmenin daha iyi yolları olduğunu anlıyorum, ancak yukarıda verdiğim yöntemin neden işe yaramadığını öğrenmekle daha çok ilgileniyorum. Herkes bu sanitizasyon yöntemine karşı bir SQL enjeksiyon saldırısı monte etmek için herhangi bir özel yol biliyorsa ben görmek isterim.

Her şeyden önce, bu sadece kötü bir uygulamadır. Giriş doğrulaması her zaman gereklidir, ancak aynı zamanda her zaman iffy.
Daha da kötüsü, kara liste doğrulaması her zaman sorunludur, hangi değerleri / biçimleri kabul ettiğinizi açıkça ve kesin olarak tanımlamak çok daha iyidir. Kuşkusuz, bu her zaman mümkün değildir - ancak bir ölçüde her zaman yapılmalıdır.
Konuyla ilgili bazı araştırma yazıları:

• http://www.imperva.com/docs/WP_SQL_Injection_Protection_LK.pdf
• http://www.it-docs.net/ddata/4954.pdf (Açıklama, bu sonuncusu benimdi;))
• https://www.owasp.org/images/d/d4/OWASP_IL_2007_SQL_Smuggling.pdf (artık mevcut olmayan önceki makaleye dayanarak)

Önemli olan, yaptığınız tüm kara listelerin (ve çok izin veren beyaz listelerin) atlanabilmesidir. Makalemdeki son bağlantı, alıntıdan kaçmanın bile atlanabileceği durumları gösteriyor.

Bu durumlar sizin için geçerli olmasa bile, yine de kötü bir fikirdir. Dahası, uygulamanız önemsiz derecede küçük olmadığı sürece, bakım ve belki belirli bir miktar yönetişim ile uğraşmak zorunda kalacaksınız: Her zaman, her yerde doğru yapılmasını nasıl sağlıyorsunuz?

Bunu yapmanın uygun yolu:

• Beyaz liste doğrulaması: tür, uzunluk, biçim veya kabul edilen değerler
• Kara listeye almak istiyorsanız hemen devam edin. Alıntı kaçış iyidir, ancak diğer hafifletmeler bağlamında.
• Hazırlamak ve doğrulamak için Command ve Parameter nesnelerini kullanın
• Yalnızca parametreli sorguları arayın.
• Daha da iyisi, yalnızca Saklı Yordamları kullanın.
• Dinamik SQL kullanmaktan kaçının ve sorgular oluşturmak için dize birleştirme kullanmayın.
• SP'ler kullanıyorsanız, veritabanındaki izinleri yalnızca gerekli SP'leri yürütmekle sınırlayabilir ve tablolara doğrudan erişemezsiniz.
• Ayrıca tüm kod tabanının DB'ye yalnızca SP'ler aracılığıyla eriştiğini kolayca doğrulayabilirsiniz ...

Tamam, bu yanıt sorunun güncellenmesiyle ilgilidir:

"Herkes bu sanitizasyon yöntemine karşı bir SQL enjeksiyon saldırısı monte etmek için herhangi bir özel yol biliyorsa, ben görmek isterim."

Şimdi, MySQL ters eğik çizgisinden kaçmanın yanı sıra aslında MSSQL'den bahsettiğimizi göz önünde bulundurarak, aslında SQL'in kodunuzu enjekte etmenin 3 olası yolu var.

sSanitizedInput = "'" & Değiştir (sInput, "'", "''") & "'"

Bunların her zaman geçerli olmayacağını ve etrafındaki gerçek kodunuza çok bağlı olduğunu göz önünde bulundurun:

1. İkinci derece SQL Enjeksiyonu - Eğer bir SQL sorgusu kaçıştan sonra veritabanından alınan verilere dayanarak yeniden oluşturulursa , veri kaçışsız olarak birleştirilir ve dolaylı olarak SQL enjekte edilebilir. Görmek
2. String truncation - (biraz daha karmaşık) - Senaryo, iki alanınız var, bir kullanıcı adı ve şifre söyleyin ve SQL her ikisini de birleştirir. Ve her iki alanın (ya da sadece ilkinin) uzunluk sınırı zor. Örneğin, kullanıcı adı 20 karakterle sınırlıdır. Diyelim ki bu koda sahipsiniz:

username = left(Replace(sInput, "'", "''"), 20)

Sonra ne olsun - kaçtı ve 20 karaktere kesilmiş kullanıcı adıdır. Buradaki sorun - Alıntıyı 20. karaktere yapıştıracağım (örneğin 19 yaşından sonra) ve kaçan teklifiniz kesilecek (21. karakterde). Sonra SQL

sSQL = "select * from USERS where username = '" + username + "'  and password = '" + password + "'"

yukarıda belirtilen hatalı biçimlendirilmiş kullanıcı adıyla birlikte, parolanın tırnak işaretleri dışında kalmasına neden olur ve yalnızca doğrudan yükü içerir.
3. Unicode Kaçakçılık - Bazı durumlarda, üst düzey bir unicode karakter geçmek mümkün olduğunu görünüyor bir alıntı gibi ama değil - aniden veritabanına gelene kadar öyle . Doğruladığınız zaman bir teklif olmadığından, kolay geçecektir ... Daha fazla ayrıntı için önceki yanıtımı görün ve orijinal araştırmaya bağlantı verin.

Özetle: Asla kendinizden kaçan sorgulama yapmayın. Yanlış bir şeyler yapmak zorundasınız. Bunun yerine, parametreli sorgular kullanın veya bunu herhangi bir nedenden dolayı yapamıyorsanız, bunu sizin için yapan mevcut bir kitaplığı kullanın. Bunu kendiniz yapmak için hiçbir neden yok.

Bunun soru sorulduktan uzun bir süre sonra geldiğini anlıyorum, ama ..

'Argümanı teklif et' prosedürüne saldırı başlatmanın bir yolu dize kesilmesidir. MSDN'ye göre, SQL Server 2000 SP4'te (ve SQL Server 2005 SP1'de) çok uzun bir dize sessizce kesilecektir.

Bir dizeyi alıntıladığınızda, dizenin boyutu artar. Her kesme işareti tekrarlanır. Bu daha sonra SQL'in bazı kısımlarını tamponun dışına itmek için kullanılabilir. Böylece nerede bir maddenin yan tümcesini etkili bir şekilde kesebilirsiniz.

Bu, büyük olasılıkla, 'güncelleme' ifadesini yapması gereken tüm kontrolleri yapmamak için kötüye kullanabileceğiniz bir 'kullanıcı yöneticisi' sayfa senaryosunda yararlı olacaktır.

Bu nedenle, tüm argümanları alıntılamaya karar verirseniz, dize boyutları ile neler olup bittiğini bildiğinizden emin olun ve kısaltma ile karşılaşmadığınızı görün.

Parametrelerle gitmenizi tavsiye ederim. Her zaman. Sadece bunu veritabanında zorlayabilseydim. Ve bir yan etki olarak, ifadelerin daha fazla aynı görünmesi nedeniyle daha iyi önbellek isabetlerine sahip olma olasılığınız daha yüksektir. (Bu kesinlikle Oracle 8 için geçerliydi)

Bu tekniği sıfırdan bir sorgu oluşturmanın tek geçerli cevap olduğu 'gelişmiş arama' işlevselliği ile uğraşırken kullandım. (Örnek: Kullanıcının, ürün öznitelikleri üzerinde sınırsız bir dizi kısıtlamaya dayanarak ürünleri aramasına, kullanıcıların öğrenme eşiğini azaltmak için GUI denetimleri olarak sütunları ve izin verilen değerleri görüntülemesine olanak tanır.)

Kendi içinde AFAIK güvenlidir. Bununla birlikte, başka bir yanıtlayıcının işaret ettiği gibi, arka boşluktan kaçmakla da uğraşmanız gerekebilir (en azından ADO veya ADO.NET kullanarak SQL Server'a sorgu iletilse de, en azından - tüm veritabanları veya teknolojileri için kefil olamaz).

Bu engel, gerçekten hangi dizelerin kullanıcı girdisi içerdiğinden (her zaman potansiyel olarak kötü amaçlı) ve hangi dizelerin geçerli SQL sorguları olduğundan emin olmanız gerektiğidir. Tuzaklardan biri, veritabanındaki değerleri kullanırsanız - bu değerler başlangıçta kullanıcı tarafından sağlanmış mıydı? Eğer öyleyse, onlar da kaçmalıdır. Benim cevabım, SQL sorgusu oluşturulurken olabildiğince geç (ama daha sonra değil!) Sterilize etmek.

Bununla birlikte, çoğu durumda, parametre bağlama gitmek için bir yoldur - sadece daha basittir.

Girdi sanitasyonu, yarı göt yapmak istediğiniz bir şey değildir. Bütün kıçını kullan. Metin alanlarında düzenli ifadeler kullanın. Sayısal öğelerinizi uygun sayısal türe ayarlayın ve işe yaramazsa bir doğrulama hatası bildirin. Girdinizde saldırı düzenlerini aramak çok kolaydır, örneğin '-. Kullanıcıdan gelen tüm girdilerin düşman olduğunu varsayalım.

Bildiğiniz gibi zaten kötü bir fikir.

Ya şu şekilde dizeden alıntı kaçmak gibi bir şey? \ '

Değişiminiz şunlarla sonuçlanır: \ ''

Ters eğik çizgi ilk tırnaktan kaçarsa, ikinci tırnak dizgiyi sonlandırır.

Basit cevap: Bazen işe yarar, ama her zaman değil. Yaptığınız her şeyde beyaz liste doğrulamasını kullanmak istiyorsunuz, ancak bunun her zaman mümkün olmadığını anlıyorum, bu yüzden en iyi tahmin kara listesine gitmek zorundasınız. Benzer şekilde, her şeyde parametreli saklı procs kullanmak istiyorsunuz , ancak bir kez daha bu her zaman mümkün değil, bu nedenle sp_execute'u parametrelerle kullanmak zorundasınız.

Kullanabileceğiniz herhangi bir kullanılabilir kara liste etrafında (ve bazı beyaz listelerde de) yollar var.

İyi bir yazı burada: http://www.owasp.org/index.php/Top_10_2007-A2

Gerçek bir tane almak için size zaman vermek için bunu hızlı bir düzeltme olarak yapmanız gerekiyorsa, yapın. Ama güvende olduğunu düşünme.

SQL enjeksiyonlarından korunmanın iki yolu vardır, istisna yoktur; hazırlanmış beyanlar veya ölçülen saklı yordamlar.

Parametrelendirilmiş sorgularınız varsa bunları her zaman kullanmalısınız. Tek bir sorgu net üzerinden kayma ve DB risk altında.

Evet, birisi SET QUOTED_IDENTIFIER OFF'u çalıştırıp size çift tırnak işareti alana kadar bu işe yarayacaktır .

Düzenleme: Kötü niyetli kullanıcının alıntı yapan tanımlayıcıları kapatmasına izin vermemek kadar basit değildir:

SQL Server için SQL Server Yerel İstemci ODBC sürücüsü ve SQL Server Yerel İstemci OLE DB Sağlayıcısı, bağlanırken otomatik olarak QUOTED_IDENTIFIER değerini AÇIK olarak ayarlar. Bu, ODBC veri kaynaklarında, ODBC bağlantı özniteliklerinde veya OLE DB bağlantı özelliklerinde yapılandırılabilir. DB-Library uygulamalarından bağlantılar için SET QUOTED_IDENTIFIER için varsayılan KAPALI değeridir.

Saklı yordam oluşturulduğunda, SET QUOTED_IDENTIFIER ve SET ANSI_NULLS ayarları yakalanır ve bu saklı yordamın sonraki çağrıları için kullanılır .

SET QUOTED_IDENTIFIER ayrıca ALTER DATABASE ayarının QUOTED_IDENTIFER ayarına karşılık gelir.

SET QUOTED_IDENTIFIER ayrıştırma zamanında ayarlanır . Ayrıştırma zamanında ayarlanması, SET deyimi toplu işte veya saklı yordamda mevcutsa, kod yürütmenin gerçekten bu noktaya ulaşıp ulaşmadığına bakılmaksızın geçerli olacağı anlamına gelir; ve SET deyimi herhangi bir deyim yürütülmeden yürürlüğe girer.

QUOTED_IDENTIFIER'ın mutlaka bilmeden kapalı olmasının birçok yolu vardır. Kuşkusuz - bu, aradığınız sigara silahı sömürüsü değil, ama oldukça büyük bir saldırı yüzeyi. Tabii ki, çift tırnaklardan da kaçtıysanız - o zaman başladığımız yere geri döndük. ;)

Savunmanız şu durumlarda başarısız olur:

• sorgu bir dize yerine bir sayı bekliyor
• aşağıdakileri içeren tek bir tırnak işaretini temsil etmenin başka bir yolu vardı:
  • \ 039 gibi bir kaçış dizisi
  • unicode karakter

(ikinci durumda, yalnızca değiştirme işlemini yaptıktan sonra genişletilmiş bir şey olması gerekir)

Patrick, TÜM girdilere, hatta sayısal girdilere tek tırnak mı ekliyorsunuz? Sayısal girdiniz varsa, ancak tek tırnakları etrafına koymuyorsanız, bir pozunuz olur.

Kullanıcı girdilerinin sanitasyonunun ne kadar çirkin kodlanması olurdu! Sonra SQL deyimi için clunky StringBuilder. Hazırlanan ifade yöntemi çok daha temiz bir kod ile sonuçlanır ve SQL Injection faydaları gerçekten güzel bir ektir.

Ayrıca tekerleği neden yeniden icat ettiniz?

Tek bir alıntıyı iki tek tırnak işareti (neye benziyor) olarak değiştirmek yerine, neden sadece kesme işareti, bir alıntı olarak değiştirmek veya tamamen kaldırmak istemiyorsunuz?

Her iki durumda da, bir miktar çamur ... özellikle meşru olarak tek tırnak işaretleri kullanabilecek şeyler (isimler gibi) olduğunda ...

NOT: Yönteminiz ayrıca, uygulamanızda çalışan herkesin veritabanına ulaşmadan önce girdileri dezenfekte etmeyi hatırladığını varsayar; bu, çoğu zaman gerçekçi değildir.

Dizeler için çalışan bir çözüm bulabilmenize rağmen, sayısal tahminler için bunların yalnızca sayıları geçtiğinden emin olmanız gerekir (basit kontrol, int / double / ondalık olarak ayrıştırılabilir mi?).

Çok fazla iş var.

İşe yarayabilir, ama bana biraz hokey gibi geliyor. Her dizenin yerine normal bir ifadeye karşı test ederek geçerli olduğunu doğrulamanızı öneririm.

Evet, yapabilirsiniz, eğer ...

Konuyu inceledikten sonra, önerdiğiniz gibi sterilize edilmiş girdilerin güvenli olduğunu düşünüyorum, ancak sadece bu kurallar altında:

1. kullanıcılardan gelen dize değerlerinin dize değişmez değerlerinden başka bir şey olmasına asla izin vermezsiniz (yani yapılandırma seçeneği vermekten kaçının: "Buraya ek SQL sütun adları / ifadeleri girin:"). Dizeler dışındaki değer türleri (sayılar, tarihler, ...): bunları yerel veri türlerine dönüştürün ve her veri türünden SQL değişmezi için bir rutin sağlayın.

   • SQL ifadelerinin doğrulanması sorunludur

2. Ya kullanımı nvarchar/ ncharkolonları (ve önek dize hazır Ngirmeden) OR sınır değerleri varchar/ charASCII karakter sütunların sadece (örneğin atış istisna SQL deyimi oluştururken)

   • bu şekilde CHAR (700) 'den CHAR (39)' a (ve belki de diğer benzer Unicode kesmek) otomatik kesme işaretinden kaçınacaksınız.

3. değer uzunluğunu her zaman gerçek sütun uzunluğuna uyacak şekilde doğrularsınız (daha uzunsa istisna atma)

   • SQL Server'da, kesme sırasında atılan SQL hatasını atlamaya izin veren bilinen bir kusur vardı (sessiz kesme)

4. SET QUOTED_IDENTIFIERher zaman olduğundan emin olON

   • dikkatli olun, ayrıştırma zamanında, yani kodun erişilemeyen bölümlerinde bile uygulanır

Bu 4 noktaya uyduğunuzda güvende olmalısınız. Bunlardan herhangi birini ihlal ederseniz, SQL enjeksiyonu için bir yol açılır.