web-gelistirme-sc.com

Tek teklif filtreleme saçmalık mı?

Sızma testi yapan kişiler, gönderilen veri alanlarında tek tırnaklara izin verdiğimizi öğrendiler ve herhangi bir değerde izin vermemek için kurallar (giriş doğrulama) uygulamamızı istiyorlar.

Tek tırnakların SQL enjeksiyon saldırıları için popüler olduğunun farkında olduğum halde, geçerli giriş olarak izin verilmemeleri gerektiğini kesinlikle kabul etmiyorum. Aslında uzaktan SQL parçası olmak gibi görünüyor bir şey filtreleme yerine hazırlanan ifadeler (bu düzgün değerleri alıntı) kullanarak SQL enjeksiyonunu önlemek için savunuyorum.

Benim olayım:

  • Kişi adları tek tırnak içerebilir ( O'Reilly)
  • Metin alanları tek tırnak içerebilir ( Eminim)
  • Sayı alanları tek tırnak içerebilir ( 1'000'000 EUR)
  • ve daha fazlası

SQL enjeksiyon önleme kurallarının uygulanmasının en basit nedenlerden dolayı geçerli verileri belirlediği başka durumlar gördüm (isim " Andreas" bir [~ # ~] ve [~ # ~] ve " select", " insert" anahtar kelimelerini içerdikleri için düz metin alanlarındaki çeşitli yaygın kelimeler reddediliyor, " güncelleme" veya " sil").

Güvenlik profesyonellerinin bu konudaki tutumu nedir?

Belirttiğim nedenlerden dolayı tek tırnak için giriş doğrulaması uygulamasını reddedelim mi?

237
Peter Walser

Giriş doğrulama işlemini kapsamlı bir savunma yöntemi olarak uygulamalısınız. Bu nedenle girdi doğrulaması, SQL enjeksiyonuna karşı birincil savunmanız olmamalı, bu ifadeler hazırlanmalıdır. Ek bir savunma olarak izin verilen girdileri kısıtlamalısınız.

Bu asla işlevselliği kısıtlamamalıdır. Girişte kesme işaretlerinin bulunması için yasal bir kullanım durumu varsa, buna izin vermelisiniz. Bu nedenle, ad alanlarında, açıklamalarda, parolalarda tek tırnaklara izin vermelisiniz, ancak sayı alanlarında, kullanıcı adı alanlarında, plaka alanlarında izin verilmemelidir.

Tüm girişlerde tek tırnak engellemek için delilik olduğunu. Bu, uygulamanın işlevselliğini bozar ve SQL enjeksiyonuna karşı doğru çözüm bile değildir.

Pentesting şirketini yanlış anlama olasılığını düşünün. Bu ciddi bir tavsiye ise, bu pentesting şirketine kötü bir şekilde yansır ve yazılımınızı kullanılamaz hale getirmek yerine düzgün bir şekilde güvenliğini sağlamaya yardımcı olan bir pentesting ortağı aramanızı öneririm.

321
Sjoerd

Enjeksiyon saldırıları bağlamında bu yanlıştır - ya veritabanı katmanınız dizeleri doğru bir şekilde işliyor ya da yapmıyor. Kesme işaretleri adlarda ve serbest metinlerde geçerli olduğundan, bunları tamamen engellemek uygulamayı bozar ve seçici olarak engellemek enjeksiyon sorunlarını çözmez.

Ancak katı girdi doğrulaması is genel ilkeler üzerinde iyi uygulama ve aşırı derecede müsamahakar olmak, kesme işaretinin meşru bir değerin parçası olmadığı durumlarda mantıklı değildir. EUR 1'000'000, yerel ayara özgü bir biçimdir (yalnızca İsviçre, AFAIK) - ancak biçimin değerin bir parçası olmasına izin vermek burada bir anlam ifade etmez. Kullanıcı 1,500, uygulamanız bunu olduğu gibi saklamalı mı? Her işlendiğinde 1.5 mi yoksa 1500 olarak mı yorumlanacağına karar vermeniz gerekecek mi? Yerel tarafa özgü sunuyu istemci tarafında işlemek ve sayısal değeri dahili olarak kurallı bir biçimde işlemek daha mantıklı olacaktır.

Dolayısıyla bu sorunun cevabı, denetimin mantıklı olduğu belirli alanlardan şikayet edip etmediğine veya kesme işaretlerine battaniye yasağı önermesine bağlı olacaktır. Birincisi, bu meşru bir noktadır. İkincisi, aptallar ve muhtemelen körü körüne bir kontrol listesini takip ediyorlar.

27

Adım 1) SQL'inizi parametrelendirin.

Adım 2) Parametreleriniz için değerleri ayarlamak için SQL DB Bağlantı kütüphanesini kullandığınızdan emin olun, değil sadece bunları satır içinde ayarlayın. Bu SQL enjeksiyonuna karşı gerçek savunmadır.

Adım 3) SQL'de sorgu oluşturma. Bu şekilde delilik yatar.

Adım 4) Hatayı kullanıcıya geri yaymak için bir yapılandırma anahtarı ekleyin. Test sırasında açın.

Adım 5) Penetrasyon test edicilerinize, tek sayıda tek tırnak veya kapanma ile bir SQL hatası oluşturmanın bir yolunu bulmalarını söyleyin.

17
Joshua

Hazırlanan ifadeler (parametrelenmiş sorgular) mükemmeldir, sadece doğru şekilde uyguladığınızdan emin olun. Her açıdan savunmasız olan "hazırlanmış ifade" uygulamaları gördüm. Uygulama ayrıntılarının tartışılması için yığın taşmasını öneriyorum.

Ayrıca derinlemesine savunma ile yanlış bir şey yok (bu durumda giriş doğrulama) ama iyi yapın ... tüm tek tırnakları reddetmek muhtemelen en iyi uygulama değildir :)

12
DarkMatter

Ben güvenlik görevlisi değilim. Güvenli kodu korumak zorunda olan bir programcıyım. Ben buna "kırılgan" uygulama diyorum. Giriş noktaları tipik bir projenin her tarafına dağılmıştır. Hepsini bulmak ve sterilize etmek, sadece tek bir sorunu, kod değiştikçe etkili kalmasını sağlamak için çok dikkatli bir bakım ve güçlük ve onu etkisiz hale getiren varsayımlarla dolu olmak için çok fazla iştir.

Bunun yerine, bakımı daha kolay, katmanlı, bağlamsal ve çok çeşitli sorunları çözen uygulamaları kullanın. O zaman pahalı, aşırı geniş filtrelemeye ihtiyacınız yoktur.

Bunların nasıl kullanılacağını bilmiyorsanız girişi güvence altına alamazsınız.

Diyelim ki, karttaki tüm girdilerden alınan tüm tekli alıntıları çıkararak sisteminizi "güvence altına aldınız". Harika, bir tür SQL enjeksiyon saldırısına karşı güvendesiniz. Bu giriş bir ...

  • Çift tırnak işareti sağlayan MySQL sorgusu
  • Dosya sistemi çalışması
  • Kabuk komutu
  • Ağ sorgusu
  • Yöntem adı
  • Sınıf adı
  • eval

Bunların her birinin farklı özel karakterleri, kaçış dizileri, alıntı kuralları ve güvenlik uygulamaları vardır. Girişinizin içeri girdiğinde nasıl kullanılacağını tahmin edemezsiniz. Tüm özel karakterleri çıkarmaya çalışmak deliliktir ve sadece bir saldırı sınıfını "çözer".

Ya da kullanıcının bir sayfa sınırı girmesine izin verilirse ne olur. Bu sınır, parametreli bir sorguda açıkça kullanılır; SQL enjeksiyonu yok, yay! Kullanıcı 9999999999 ve şimdi bir DOS saldırısına açıksınız.

Güvensiz olabilecek işlemin gerçekleştirildiği noktada uygun güvenlik önlemlerini uygulamalısınız. Bu, operasyona özgü birçok faktörü dikkate alır; girdi karakterlerini sterilize etmek sadece bir tanesidir.

Bunu yaptığınız sürece, sorgularınızı da parametrelendirebilirsiniz. Sonra battaniye soyma tırnak tüm iş ve hasar yapmak için artık gerek yok.

Tüm girişlere filtre uygulamak zordur.

Belirli bir projede girdi almanın ve aktarmanın birçok, çok, çok yolu vardır:

  • form girişleri
  • uRL'ler
  • dosya adları
  • dosya içeriği
  • veritabanı sorguları
  • ağ okumaları
  • ortam Değişkenleri

Bunlar genellikle oldukça serbest bir formdur ve birçok farklı kütüphane kullanabilir. Tüm potansiyel olarak savunmasız girdilerin filtrelemeden geçtiğini doğrulayan statik analiz araçlarının farkında değilim. Bazı dillerde taint system bulunur, ancak etkin bir şekilde kullanılması zordur. Tüm girişleri filtreleseniz bile, statik bir analiz aracı olmadan, filtrelenmemiş girişler geliştirme devam ederken geri sızar. İşlevselliği engelleyen sonucu korumak için eksik ve pahalı bir çaba.

Buna karşılık, bir projede SQL yürütmenin genellikle tek bir yolu vardır. Statik ve çalışma zamanı araçları, olası SQL enjeksiyonunu otomatik olarak algılamak için mevcuttur. Dizeleri tamamen izin vermeyebilir ve tüm sorguların SQL sorgu nesneleri olmasını isteyebilirsiniz. Bu iyi uygulamaların bakımı kolaydır ve giderek araçlara ve SQL kitaplıklarına dönüştürülür.

"Güvenlik duvarları" gevşek güvenliğe yol açar.

Bazı ofis ağlarının nasıl çok güvensiz uygulamalara sahip olduğuna benzer şekilde, "güvenlik duvarımız var", ekibin kodlarını güvence altına alma konusunda tembel olma riski vardır, çünkü "girdi güvenlidir". Giriş kesinlikle güvenli değil.

Fırsat Maliyeti

Bazıları "neden ikisi birden olmasın?" Bir proje üzerinde çalışmak için sadece çok zamanınız var. Düşük verimlilik, yüksek bakım uygulaması bir zaman emicidir. Bunu uygulamak ve sürdürmek, sınırlı sürenizi daha verimli, bakımı kolay uygulamalardan uzak tutacaktır. En kötü durumda, girdilerle köstebek vurmak için çok fazla zaman harcayacaksınız ve çok agresif filtrelemenin neden olduğu problemler, uygun güvenlik önlemleri için asla zaman bulamayacaksınız.

Kısacası, giriş filtreleme pahalı, sızdıran, bakımı zor, sorunu çözemez ve daha da kötüleştirebilir.

11
Schwern

Kendiniz dediğin gibi, parametrelenmiş sorgular kullanıyorsanız, tek tırnaklar sorun değildir. Bu durumda, tavsiyelerini reddedebilirsiniz. Bunu yaparsanız, parametreli sorguları kullanarak are olduğunuzu ve bunun da kullanılabilirliğe yardımcı olduğunu (önceki örneklerinizi kullanarak) vurgulayın.

8
Philip Rowlands

Her yerde SQL enjeksiyonunu her zaman önlediğinizden% 100 eminseniz, bu gerçekten saçmalıktır.

Bununla birlikte, SQL enjeksiyonu en yaygın güvenlik risklerinden biridir ve uygulamanızı parametreleri kullanmak için doğru yazdığınızdan emin olsanız bile, özensiz bir DBA ikinci derece SQL için risk altında olan bir sorgu yürütebilir) enjeksiyon . Hiçbir yerde depolanmayabilir, sadece tablo kopyalamak için bir sorgu olabilir.

İkinci dereceden saldırıların gerçekleştirilmesi daha zor, ancak korunması daha zordur. İkinci derece saldırılara karşı koruma, veritabanında yazma izinleriyle çalışan her dinamik SQL ifadesinin, yalnızca güvenilmeyen kaynaklardan gelen girdileri işleyen SQL ifadeleri için değil, SQL enjeksiyonu riski açısından kontrol edilmesi gerektiği anlamına gelir.

Her yerde alıntılara izin vermemek, ikinci dereceden saldırılara karşı özensiz bir korumadır, ancak daha az olası hale getirir. İdeal bir dünyada gerekli olmazdı, ama maalesef bir dünyada yaşamıyoruz.

Birçok kullanıcı veritabanında herhangi bir yazma erişimine sahipse ve kendi SQL deyimlerini yazabiliyorsa, bu mantıklı bir güvenlik önlemi olabilir. Uygulamanız veritabanına erişmenin tek yoluysa ve yalnızca çok bilgili kullanıcılar yazma erişimiyle kendi sorgularını yürütebilirse, bu genellikle gerekli değildir.

8
Erik A

Başvurunuzun ayrıntılarını bilmesem de, argümanınızı takip ediyorum.

Belirli karakterleri içermesi gerekmeyen alanlar var. Bu alanlarla, tek tırnaklara (ve çift tırnaklara ve başka herhangi bir şeye) filtre uygulamak için olabilir giriş doğrulamasını kullanabilirsiniz.

Kaçışınız düzgün çalışmadıysa, giriş doğrulaması bir azaltma stratejisi olabilir, ancak SQL enjeksiyon risklerini azaltmak için hazırlanan ifadeleri (doğru) kullanmak tercih edilebilir bir yaklaşım olmalıdır.

6
Tobi Nary

Bu gerçek bir Penetrasyon Testinin sonucuysa, size bunun istismar edilebilir bir sorun olduğunu kanıtlayan bir değer sunabilmeleri gerekir. Eğer bunu yapamazlarsa, bunun sömürücü olduğunu kanıtladıkları uygun bir penetrasyon testi istemenizi öneririm.

Ancak bu genel bir Güvenlik Açığı Taraması'nın sonucuysa, o zaman bu tür bulanık genel yanıtlar beklerdim, bu sadece tek bir alıntı ekleyebilmeyi işaret eder. Bu durumda, herhangi bir sorun olmadığından memnunsanız, o sonucu mutlu bir şekilde göz ardı edebilirsiniz.

4
Jason Leaman

Bence bu bir perspektif meselesi. Sisteminizin önce gelmesi gereken işlevsel bir gereksinimi vardır. Bu, giriş doğrulaması konusunu dikkate almaya değmeyeceği anlamına gelmez. BTW, ikisi doğrudan doğruya değil. Bunu tavsiye etmiyorum, ancak kodlama ve ön uçta kod çözme ve SQL depolama ve sorgu kodlanmış formu kullanmak mümkün olacaktır.

Denge özneldir ve bahsedilmeyen şeylere bağlıdır. Onlardan netleştirmelerini isteyebilirsiniz. Çok iyi bir nedeni olabilir, olmayabilir.

1
ANone

Eski bir web geliştiricisinden ve şimdi bir kalem test cihazından, kullanıcı girişini kısıtlamak istemem ama bu büyük bir sorun olabilir. Bu tekniği web uygulamalarından ve veritabanlarından ödün vermek için kullandığımı biliyorum.

Benim fikrim DB yükleme ve web dil (php) yapılandırma kaçış karakterleri işlemek için kontrol etmek sonra düzgün biçimlendirilmiş olduğundan emin olmak için giriş yinelemek için bir modül (ler) kodlamak olacaktır.

Kesme işareti geçerli bir girdi olabilir, ancak veritabanı ifadenizin iletilmesinden kaçabilir ve bir saldırı vektörü ekleyebilir. DB ve web dillerinde bu tür örnekleri işleyebilecek modüller bulunur, ancak yine de iki kez kontrol etmek için kendi modülünüzü yazmak iyi bir fikirdir.

1
MrNiceGuy