Ben php mysql enjeksiyon önlemek için kullanıcıdan olsun tüm çerezleri mysql_real_escape_string gerekir?

10 Cevap php

Bir kullanıcı benim siteye gittiğinde, benim komut dosyası otomatik olarak bir tanımlama editörü ile kurabiye içeriğini düzenlemek için onun mümkün onları içeri oturum, kullanıcı kimliği + şifre kısmını depolamak 2 çerezleri denetler, bu yüzden eklemek olası sanırım yazılı bir çerez için bazı zararlı içerik?

Ben bütün çerez aramalara mysql_real_escape_string (ya da başka bir şey) eklemek veya bu olmasına izin vermez prosedürünün yerleşik bir tür var mıdır? Ben gerçekten sadece bu konuda şimdiye kadar hiç düşünmemiştim .....

10 Cevap

Eğer really yapmanız gereken ilk etapta hackable olan bu çerez değerleri göndermek değildir. Bunun yerine, neden kullanıcı adı ve şifre ve (gizli) tuz karma ve çerez değeri olarak ayarlamak değil? yani:

define('COOKIE_SALT', 'secretblahblahlkdsfklj');
$cookie_value = sha1($username.$password.COOKIE_SALT);

Sonra çerez değeri her zaman 40 karakter onaltılık dize olacak biliyorum, ve kullanıcı bunlar geçerli veya değil karar veritabanında ne varsa geri gönderir değeri karşılaştırabilirsiniz:

if ($user_cookie_value == sha1($username_from_db.$password_drom_db.COOKIE_SALT)) {
  # valid
} else {
  #not valid
}

mysql_real_escape_string (bir sürü insan, bir DB bağlantısı gerektirir ve MySQL sorgular farkında değilsiniz) MEZUNLARI, veri tabanına ek bir vuruş yapar.

Eğer app değiştirmek ve hackable çerez değerleri kullanmakta ısrar edemez eğer ne istediğinizi yapmak için en iyi yolu kullanmaktır prepared statements with bound parameters.

Mysql_real_escape_string bir nokta enjeksiyonu saldırılarına karşı korumak için değil, veri doğru bir veritabanında saklanır sağlamak gerekir. Bu nedenle, ne olursa olsun kaynağı, veritabanına girmeden HERHANGİ dize üzerinde aranmalıdır.

Ancak, also SQL enjeksiyon kendinizi korumak için (mysqli'nin veya PDO) parametreli sorgular kullanarak olmalıdır. Aksi takdirde little Bobby Tables' school gibi biten riski.

Ben sadece bir SQL deyimi haline değişkenleri takmadan önce mysql_real_escape_string kullanın. Lütfen bazı değişkenler already kaçtı, ve sonra tekrar kaçış eğer sadece kendiniz karışık alırsınız. Bu newbies 'blog webapps görmek klasik bir hata var:

Birisi bir kesme işareti yazdığında bu blog \ \ \ \ \ \ \ 's sayfaları bozma bölü eklemeye devam ediyor.

Bir değişkenin değeri tek başına tehlikeli değildir: o bir dize ya da tehlikeli sulara ayrılmanın başlamak benzer bir şey koymak sadece bulunuyor.

Tabii rağmen, istemci tarafında gelen bir şey asla güvenme.

Bağlayıcı Hazırlanan tablolar ve parametre her zaman gitmek için iyi bir yoldur.

ARMUT :: MDB2 örneğin, hazırlanan ifadeleri destekler:

$db = MDB2::factory( $dsn );

$types = array( 'integer', 'text' );
$sth = $db->prepare( "INSERT INTO table (ID,Text) (?,?)", $types );
if( PEAR::isError( $sth ) ) die( $sth->getMessage() );

$data = array( 5, 'some text' );
$result = $sth->execute( $data );
$sth->free();
if( PEAR::isError( $result ) ) die( $result->getMessage() );

Bu sadece uygun veri ve değişkenler önceden ayarlanmış bir miktar veritabanına girmek için izin verecektir.

Siz tabii ki bu kadar girmeden önce, verileri doğrulamak, ancak tabloların hazırlanmasında yapılmalıdır nihai doğrulama olduğunu gerekir.

O potansiyel olarak zararlı olabilecek anything mysql_real_escape_string gerekir. Kullanıcı tarafından değiştirilebilir giriş herhangi bir tür güvenme.

Sana katılıyorum. Bu tanımlama değiştirmek ve kötü niyetli veri göndermek mümkündür.

Ben bunları kullanmadan önce çerezleri almak değerlere filtre iyi bir uygulama olduğuna inanıyoruz. Genel bir kural olarak, ben tahrif olabilecek diğer filtre girişi yok.

Yah ben kuralları biliyorum, ama ben her zaman asla kurabiye ötesine baktı ve nedense onları bir tehdit olarak kabul.

Olacak şimdi tüm siteler yama gerekiyor.

Yegor, bir kullanıcı hesabı oluşturulduğunda bir oturum başlatılır zaman / güncellenen, o zaman, sunucuya gönderilen verileri karma karma saklamak ve bu bir kullanıcı adı için veritabanında saklanan ne karşı karşılaştırabilirsiniz.

(Gevşek php Kafamın üst Off - sahte kod gibi davranın):

$usernameFromPostDbsafe = LimitToAlphaNumUnderscore($usernameFromPost);
$result = Query("SELECT hash FROM userTable WHERE username='$usernameFromPostDbsafe' LIMIT 1;");
$hashFromDb = $result['hash'];
if( (sha1($usernameFromPost.$passwordFromPost.SALT)) == $hashFromDb ){
    //Auth Success
}else{
   //Auth Failure
}

Başarılı bir kimlik doğrulama sonra, $ _SESSION veya önbelleğe doğrulanmış kullanıcı adı / karma bir veritabanı tablosunda karma saklamak. Sonra böylece sonraki sayfayı yükler seçtiğiniz oturum depolama düzenlenen karma karşı karşılaştırılmak üzere sunucuya geri göndermek karma (örneğin bir tanımlama) tarayıcıya geri karma gönderin.

mysql_real_escape_string modası geçti ... Bu gün gerçekten yerine bağlama parametre kullanmanız gerekir.

Ben prepared statements kastettiğini mentionning tarafından ayrıntılı ve bazen mysl_real_escape_string yeterli olmadığını gösteren bir makale için bir bağlantı sağlamak olacak: http://www.webappsec.org/projects/articles/091007.txt

Bu da gerçek HTML kodu herhangi bir kaza sonucu çıktısı önleyecek şekilde yerine mysql_real_escape_string arasında htmlentitiesi ($ girdi, ENT_QUOTES) kullanarak öneriyoruz. Tabii ki, mysql_real_escape_string ve htmlentitiesi kullanabilirsiniz, ama neden ki?

etiketler