Programcıların SQL enjeksiyonuna açık kod yazmayı bırakmasını nasıl sağlayabilirim?

11

Bazen meşgul olur ve küçük görevleri genç programcılara devredersiniz. Ancak yeterince dikkat etmezseniz, kendinizi bu tür kodlarla üretimde bulursunuz:

class DivtoggleController extends Zend_Controller_Action {

    public function closeAction() {
        /* ... code removed for brevity ... */

        $req = $this->getRequest();
        $formData = $req->getPost();

        $d = $formData['div'];
        $i = $formData['id'];

        $dm = new Model_DivtoggleManager();
        $rs = $dm->setDivToggleById($d, $i);

    }

}


class Model_DivtoggleManager extends Zend_Db_Table {

    public function setDivToggleById($div, $id) {
        $result = $this->getAdapter()->query(
           "update div_toggle set " . $div . "=1 where id=" . $id
        );
    }

}

Yani, kısalık için kimlik doğrulama / oturum yönetimi mantığını kaldırdığım göz önüne alındığında, bana bu örnekte ne gibi bir sorun olabileceğini kim söyleyebilir?

php sql training

— Roger Halliburton
kaynak

Bu neden basit bir çerezde saklanmıyor?

— Darknight

1

@Darknight, çerezin saklanacağı bir oturum olduğunu varsayıyorsunuz. Daha büyük bir güvenlik sorunu olup olmadığı önemli değildir.

— Roger Halliburton

24

Onlara öğretebilirsin. Bunu başlangıçta herkes yapar, sen bile. Bu tür bir kod üretime geçerse, yaşlılar hatasıdır; genç değil.

Düzenle:

Yaptığım şeylerden biri, şahsen proaktif olarak insanlardan bir sürümden önce kodumu (gençler dahil) incelemelerini istemekti. Kod gözden geçirilir, küçükler bunu bir öğrenme deneyimi olarak görür, insanlar kod gözden geçirme korkusunu bir ceza olarak kaybeder ve aynı şeyi yapmaya başlarlar.

— John Kraft
kaynak

2

+1 Kabul etmek zorundasınız. (Muhtemelen) bir genç programcıyı suçlayamazsınız çünkü sahip olamayacakları bir düzeyde bilgi aldınız. (Yani ediyorum dedi gibi bu tür konular da bu çağda bilinir düşünmek Sonra tekrar, istiyorum. Gibi ben vb seyir yetenekli ve iyi olduğunu düşünmek :-))

— John Parker

Yeterince adil bir ifade. Sanırım yönetimin neden kıdemli programcılar tarafından onaylanmamış üretimde kod başlatmakta ısrar edeceğini soran bir takip sorusu sormalıyım. Küçük bir güvenlik sorunu nedeniyle işimi riske atar mıyım?

— Roger Halliburton

1

@Roger Halliburton: Eh, bu güvenlik sorunu eğer yok nasılsa istismar olsun, o Olabilecek en kötü ne var? Ve neden güvenlik sorunlarına işaret etmek işinize mal olur? Yönetim bu konuyu ele almak istemiyor mu?

— FrustratedWithFormsDesigner

1

@ Roger - Saldırılana kadar sadece küçük. :) Bir inceleme olmadan (geliştiricinin seviyesi ne olursa olsun) kodu üretime sokmanın bir hata olduğunu düşünüyorum. Ne yazık ki, birçok şirkette çok yaygın bir uygulamadır; ve ime, yönetim kod değerlendirmeleri gibi şeylere değer vermeye başlamadan önce genellikle büyük bir oh- 4 $! t alır.

— John Kraft

1

@Roger: Sadece "junior" programcılar tarafından yazılan kodlar değil, tüm kodlar gözden geçirilmelidir. Üst düzey programcılar bile hata yapar.

— Dean Harding

20

Kodlarını gözlerinin önünde kesin, sonra nasıl düzelteceklerini gösterin. Anlayana kadar tekrar tekrar.

— Joe Phillips
kaynak

4

Onlara her sabah e-posta gönderin: "Bu arada, kodunuzu bıraktığınız başka bir SQL enjeksiyon güvenlik açığı aracılığıyla dün gece veritabanınızı tekrar bıraktım. Veritabanı yedeklemelerini geri yüklemeyi ne kadar sevdiğinizi biliyorum!: D"

— Ant

2

@Ant: İyi ol. Kısa bir süre önce değil, planlanan yedeklemeden kısa bir süre sonra yapın .

— Donal Fellows

@ Donal: Yedeklemeden kısa bir süre sonra yapın, ardından yedeklemenin başarısız olduğunu söyleyin ve yedeklemeyi gece boyunca geri yüklemeden önce günün geri kalanında terlemelerine izin verin.

— jwenting

8

Onları kaynak enjeksiyonlarına erişmeden önce, SQL enjeksiyonlarına, siteler arası komut dosyasına, siteler arası istek sahteciliğine ve diğer yaygın güvenlik açıklarına tanıtan, şirketinize katılır katılmaz bir sınıf almalarını zorunlu kılabilirsiniz. Kapak örnekleri yüz yüze, önlerinde kötü kod kırmak, kötü kod kırmak ve "mezun olduktan sonra daha fazla bilgi için onları OWASP sitesine yönlendirin.

Ayrıca, bunu sizin için işleyen özel bir kitaplığın kullanımını zorunlu kılabilirsiniz, ancak bu daha uygun hale geldiğinde özel sorguları çalıştıracağından emin oldukları için yalnızca ikincil bir çözümdür.

Kaynaklara sahipseniz, daha üst düzey üyelerin taahhütte bulunmadan önce farklarını doğrulamasını sağlamak da yararlı olabilir.

Bilgi Güçtür!

— yan
kaynak

3

Şirketinize katılmadan önce onları ayıklamak daha iyidir. SQL kullanan bir şey yazması için birini işe alıyorsanız, yetersizlikle ilgili enjeksiyon sınırları hakkında röportaj soruları sormayın.

— Wooble

Genelde aynı fikirdeyim, ancak çok akıllı ve hırslı bir genç kiralama, "N yıllık tecrübeye sahip bir PHP geliştiricisi" ne göre çok daha ucuzdur. Akıllı genç geliştiriciler bu şeyleri hızlı bir şekilde alabilir ve oldukça değerli olabilir.

— yan

3

Herhangi bir seviyenin geliştiricisi olarak başkalarının bahsettiği güvensizlik olduğunu varsayarsak, getPost () 'un önce verileri güvence altına almadığını unutmak kolaydır.

Bunun bir yolu:

Tüm POST / GET verilerini alan ve 'insecure_data' adlı bir Singleton sınıfına olduğu gibi yazan bir sınıf yazın. Ardından POST / GET dizilerini temizleyin.
Geliştiriciler POST / GET verilerini POST / GET dizilerinden değil, 'insecure_data' dizisinden almak zorunda.

'İnsecure_data' adlı bir diziden bir şey alan ve bunu güvence altına almayan herhangi bir geliştirici, cahil veya tembeldir. Eğer eskisi ise, eğitim sağlayın, bundan sonra ikincisi olmalıdır - ve sonra programlama değil, bir disiplin sorununuz var.

— Dan darbeler
kaynak

Vay be, bu gereksizce kıvrık ve hala sorunu çözmüyor. Bu, girdiyi sadece eğlence için değil, veritabanına koyduğunuz verileri ovalama meselesi değildir ve bu veriler teorik olarak herhangi bir yerden, bir web formundan, bir e-postadan veya bir XML belgesinden gelebilir. birisi yükler. Tüm bu durumlarda, veritabanına giderken ovmanız gerekir.

— Roger Halliburton

@RogerHalliburton Tabii ki her şeyi çözmüyor, ancak güvensiz verilerin güvensiz görünmesini sağlamak için tam bir güvenlik önlemi yerine bir kavram (eğer yapacaksanız bir tür tasarım deseni) .

— Dan darbeler

Ah, anlıyorum. Ama sadece insan doğasıyla savaşıyorsunuz, eğer birine "Bu nesne güvenli olarak işaretlenmedikçe güvensizdir" derseniz ve bir şey için kullanmaya çalışırlar, çoğu zaman gerçekten kontrol etmeden güvenli olarak işaretlerler. İtibar artışının tadını çıkarın.

— Roger Halliburton

Küçük bir geliştiricinin bakış açısına göre, sadece $ insecure_data görmek sadece $ postdata (ya da ne olursa olsun) görmeyecek şekilde bir bayrak oluşturur. Fikir Joel Spolsky'nin "Yanlış kodu yanlış göster" den geliyor . Geliştiricilerinizin insan doğası bu kırmızı bayrağı görmezden geliyorsa, çok fazla eğitim vermeniz veya yeni geliştiriciler almanız gerekir.

— Dan darbeler

Spolsky'yi kaide üzerinde tutmuyorum. Bunlar, tutarsız sekmeleri kolayca görmezden gelen geliştiricilerdir, "güvensiz" adı verilen bir şeyi kullanma hakkında iki kez düşünmeyeceklerdir.

— Roger Halliburton

1

Web güvenliği hakkında okuduğum en iyi rehberlerden biri bu Ruby on Rails güvenlik kılavuzudur. Ruby on Rails olmasına rağmen, kavramların çoğu herhangi bir web geliştirme için geçerlidir. Yeni herkesi bu kılavuzu okumaları için teşvik ederim.

— mistagrooves
kaynak

2

Herkes Ruby'nin güvenli olmadığını biliyor.

— Roger Halliburton

5

@Roger: “Herkes bilir” doğru olabilecek veya olmayabilecek her türlü şeyi. Programlamaya gerçeklik temelli bir yaklaşımı savunuyorum, kulaktan kulağa dayalı bir yaklaşım değil.

— Donal Fellows

0

Yukarıda bağladığınız kod, SQL enjeksiyon saldırısına açıktır, çünkü sorguda kullandığınız HTTP girişleri mysql_real_escape_stringveya başka yollarla temizlenmemiştir .

— Ryan
kaynak

1

oh, bunu bir test sorusu gibi cevapladığımızı sanıyordum:]

— Ryan

Downvotes biraz topal, çünkü sorunun ifadesi eski yazı değiştirildi: P

— Ryan

0

"Muhtemelen geçersiz kılma)" programcıların bunu yapmayı nasıl durdurabilirim "sorusu açısından, onlara düzenli olarak rehberlik etmenin, söz konusu sorunu (ve potansiyel serpinti, vb.) kod güvenlik açıklarının önemi (hem SQL enjeksiyonu hem de siteler arası komut dosyası oluşturma vb. açısından) muhtemelen en mantıklı çözümdür.

Yukarıdakilerin hepsine rağmen karışıklıklarını sürdürüyorlarsa ("canlı" bulmak yerine taahhütlerine göz atmak isteyebilirsiniz), sorun ya onları bir akıl hocası olarak başarısız olmanızdır. belki de yaşamak için daha uygun bir şey bulmaları gerekir.

— John Parker
kaynak