Ben kullanıyorum bu işlevi var ve ben tam bir SQL enjeksiyon saldırılarına karşı korur emin olmak istiyorum:
function MakeSafeForQuery($string)
{
// replace all of the quote
// chars by their escape sequence
$ret = str_replace("\\","\\\\",$string);
$ret = str_replace("'","\\'",$ret);
$ret = str_replace("\"","\\\"",$ret);
return $ret;
}
Ben ciddi bir şey eksik?
Düzenleme: Ben arada MySQL kullanıyorum.
GBK, 0xbf27 geçerli bir multi-byte karakter değil, ama 0xbf5c olduğunu. Tek bayt karakter olarak yorumlanır 0xbf27 (
¿) 0x27 takip (') 0xbf ve 0xbf5c (¿) 0x5C takip 0xbf olan ({ [(3)]}).Bu nasıl yardımcı olur? Ben bir ile öncelenmedikçe tek tırnak olan, bir MySQL veritabanı karşı bir SQL enjeksiyon saldırısı için isterseniz bir serseri. Eğer
addslashes()kullanıyorsanız, ancak, ben şanslıyım. Yapmam gereken tüm 0xbf27 gibi bir şey enjekte olduğunu veaddslashes()Bu, tek bir teklifle ardından geçerli bir multi-byte karakter 0xbf5c27 haline değiştirir. Diğer bir deyişle, ben başarıyla kaçan rağmen tek bir alıntı enjekte edebilir. 0xbf5c tek bir karakter değil, iki olarak yorumlanır olmasıdır. Üzgünüz, eğik çizgi gider.Bu saldırı türü
addslashes()geçerli bir çoklu-bit karakterini oluşturmak yerine tek alıntı kaçan içine kandırdın olabilir çünkü 0x5C biter geçerli bir multi-byte karakter var, herhangi bir karakter kodlaması ile mümkün olduğunu takip eder. UTF-8 bu açıklamasına uymuyor.Açığına bu tür önlemek için kullanın
mysql_real_escape_string()
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
SQL enjeksiyon karşı korumak için, kendinizi yazarken bir işlevini kullanmanız gerekir.
Bunun yerine, veritabanı sürücüsü tarafından sağlanan olan bir işlevini kullanmanız gerekir.
Örneğin:
The right way to escape strings depends on both the database system, and its configuration (which is why escaping functions generally require an active database connection) -- which means your function could/would work in most cases, but not necessarily always.
Bu gün, prepared statements, kimin parametreler enjeksiyon savunmasız değildir, yerine işlevlerini hijyen kullanmanız gerekir. PDO onları destekler. Daha fazla bilgi için "Writing MySQL Scripts with PHP and PDO" okuyun.
Sadece skaler değerler çoğu DB sürücüleri ile parametreli olabilir unutmayın. operatörü) ve tabloların diğer bölgelerinde (örneğin IN (list kullanılan) Bileşik değerleri genellikle parametreli edilemez. Bunlar için, yine ifadesine değerleri katmak gerekir. Her zamankinden değerlerinden başka bir şey için doğrudan kullanıcı girişi kullanmak için iyi değil.
Çünkü bazı egzotik kodlamaları hayatında karşılamak, ama, çünkü o escaping alone helps nothing basit gerçeği asla olmaz.
Bölü ekleme anında enjeksiyon korkutuyorsun engelleyen bazı ilahi müdahale gibi değildir.
Aslında, tırnak ile birlikte sadece çalışır. Eğer kaçtı verilerinizi alıntı ise - hatta ev demlenmiş kaçan fonksiyonu (sürece kodlama tek bayt veya UTF-8 olarak ya) ile, kendinizi güvende düşünebilirsiniz. Ancak, bazen biz değil (hatta yapamam) bizim değişkenler tırnak kullanmak ve böyle bir yerde anında bir güvenlik deliği haline gelir.
http://stackoverflow.com/a/8061617/285587: daha fazla açıklama için, benzer soruya benim önceki cevaba bakınız edebilir
Kabul edilen yanıt gelince, sadece her mysql_real_escape_string () ve PDO gerekli önlemleri almadan, tek başına kullanıldığında tam olarak aynı güvenlik açığını sahip tablolarını unutmayın. Düzgün beklendiği gibi onları çalışması için istemci kodlamasını belirlemek için gelmiştir.
So, in fact just use mysql_real_escape_string(), kendi işlevi daha size daha fazla yardımcı olacaktır.
mysql_set_charset() have to be used with mysql_real_escape_string() and in PDO either emulation mode have to be turned off or encoding should be set in DSN