Bu sanitasyonuyla olmadan bazen dinamik SQL izin için Tamam mı?

8 Cevap php

PHP proje üzerinde eşim her zaman dinamik SQL tamsayı değerleri sanitasyon benim uygulama nesneleri. Biz mümkün olduğunda parametreli sorgular kullanırız. Ama GÜNCELLEME ve koşulları DELETE için Zend_Db_Adapter olmayan bir parametreli SQL dizesi gerektirir. Ben bile düşünmeden, her zamanki gibi bir şey yazmak yüzden:

$db->delete('table_foo', 'id = ' . intval($obj->get_id()));

Eşdeğerdir, ama (ben ZF kaynak kodunu kontrol ettim) daha kısa bir versiyonu olan:

$db->delete('table_foo', $db->qouteInto('id = ?', $obj->get_id(), 'INTEGER'));

Eşim şiddetle $obj Kimlik (nesne henüz DB kaydedilmez) null ise, ben bir hata fark etmez, ve DB işlemi sadece irade olduğunu söyleyerek, bu intval() nesneleri sessizce yürütmek. Bu aslında ona ne oldu bu.

Hepimizin HTML formları girdileri varsa, orada bir tamsayı kimlik muhtemelen ''; DROP TABLE ...' içine almak, ya da ' OR 1 = 1 hiçbir şekilde veya başka kötü bir değer, ve takılı olsun diyor bizim SQL sorguları. Böylece, sadece paranoyak değilim, ve hayatımızı gereksiz yere daha karmaşık yapıyorum. "Ardından $_SESSION değerleri güvenmeyi durdurma" diyor.

Ancak, dize değeri koşulları için o kabul etmez:

$db->update->(
    'table_foo',
    $columns,
    'string_column_bar = ' . $db->qoute($string_value))
);

Ben onu yanlış kanıtlamak için başarısız oldu, ve o bana yanlış kanıtlamak için başarısız oldu. Eğer birini yapabilirsiniz?

8 Cevap

Eğer daha fazla sorun düşünüyorsunuz hangisi:

  • Başarısız bir SQL sorgusu neden olmadı bir hata izini olması.
  • Eğer form girişi sterilize bir hata yapmak ve kimse bu patlatır sonra verileri geri yüklemek zorunda.

Seçtiğiniz hangisi cevap var. Şahsen, ben de şeylerin paranoyak tarafına doğru yalın eğilimindedir.

Eğer bir şey, hem yapabileceğini: o ilk boş denetler ve ardından intval() çağırır ve kullanım yerine kendi işlevi oluşturun. Sonra her iki dünyanın en iyi olsun.

Açıkçası, eşiniz onun rocker kapalı: sanitasyon ucuz, bunu yapmak için hiçbir iyi neden yok. Even if you are sanitizing what is in the HTML forms, if those checks somehow break on production, you'll be happy that you have a backup in other places. Ayrıca, iyi bir uygulama teşvik etmektedir.

You should sanitize—always

Ben eşinizin yanlış olduğunu düşünüyorum - o modelde verilerin sanatisation arasındaki endişeleri ayrımı (DB kodu nerede yaşadığını) ve veri validation sizin formları dikkate alınarak değil.

Normalde form doğrulama mantık modeline uygulama ayrı bir alanda olacak. Yani unsurları oluşturmak için doğrulayıcılar ekleyerek, ve bu sık sık formu sınıfın kendisi yapıldığı zaman. Doğrulama kodu Bu katmanın amacı formun girişini doğrulamak ve yanlış bir şey varsa uygun mesajlar döndürmektir.

Yani Model gerçekten bağımsız bir sınıf olarak modelinde veri sanitisation, bu ayrı ayrı dikkate alınması gerektiğini düşünüyorum - ve böylece kendi veri sanitisation sorumlu olmalıdır. Teoride başka bir yerde uygulamanızda Bu modeli yeniden kullanmak gerekir, çünkü modeli sonra yani form doğrulama katmanının bir parçası olarak, sanitisation başka yapıldığını düşünmemeleri gerekir.

Sizin ortakları başarısız SQL sorguları fark olmadığı konusunda ana nokta gerçekten pratikte bir sorun değildir - bu savunmaya kod iyidir.

Siz tabii ki her zaman dezenfekte ve HTML formları güvenmemelisiniz. Eğer kodu değiştirmek ve bazı diğer veriler ile o kısmı yeniden ne varsa, o HTML formundan ama webservice veya e-posta ya da bir yıl sonra eklemeye karar herhangi başka bir kaynaktan değil mi geldi? Intval Kullanma () burada iyi olacak gibi görünüyor.

form input should idd always be sanitized, but not every variable that goes into a query should be sanitized imo...
The origin of the variable does play a significant role here.

Sadece kullanılan verilerin güvenilir olup olmadığını bilmek zorunda ...

Eğer Zend framework kodu içinde derin bakarsanız, o $ db-> quoteInto () $ db-> alıntı türü olarak INTEGER ile (dize) intval ($ değer) döndürür dönüşür görürsünüz.

Tip tanımsız ise, $ db-> _quote () denir. Onun kodu aşağıdaki gibidir:

protected function _quote($value)
{
    if (is_int($value) || is_float($value)) {
        return $value;
    }
    return "'" . addcslashes($value, "\000\n\r\\'\"\032") . "'";
}

(Ya da türü belirtmeden) kullanılan arama yöntemi, $ db-> silmek tamamen güvenlidir olursa olsun.

Önce kimliği null olmadığını kontrol etmelisiniz. Eğer durum bu ise, bir işe yaramaz sorgu yapmak ve oradan devam etmek değil biliyorum. Bu başarısız SQL sorguları ya da öylesine okuyarak sorunları izini mantıklı değil.

Bir form alınan tüm veriler sterilize edilmelidir. İstisna yok. Sisteminizden alınan tüm veriler bu sistem içine girmeden önce zaten dezenfekte edilmiş olmalı ve tekrar sisteminden alınan, bu nedenle dezenfekte edilmemelidir.

Yani, soru - nerede bu tamsayı geliyor?

etiketler