Injeciton korumalı bir web sitesi başlatmak

Ben yeni bir PHP "geliştirici" ve SOF sitesinin yeni bir üyesiyim. İlk kez bir web sitesi açıyorum ve online araştırmamda PHP'nin yüzeyde kolay olmasına rağmen, geliştiricilerin göz ardı ettiği en önemli şey enjeksiyonlar olduğunu söyledi.

SOF'un burada bir soru sormadan önce araştırmanız gerektiğini belirttiği gibi, yaptım ve öyle görünüyor ki mysql_real_escape_string (); veritabanına zarar verebilecek karakterlerden kaçmak için gereklidir. Ben de hazırlamış olduğunuz ifadeleri buldum. Bununla birlikte, hem SOF hem de Google'da arama yaparken, kullandığınız ikisinden hangisinin daha azının önemli olduğunu buldum, çünkü kullanıcı tarafından girilen veriler db'ye sorgulamak/eklemek için kullanılıyor.

Öyleyse şimdi gerçekten kafam karıştı, çünkü daha fazla insanın escape_string ifadeleri için ve birkaç tane de Prepared ifadesi için yarıştığını gördüm.

Yaptığım şey bu:

 For Post variables: 

 $thething = mysql_real_escape_string($_POST['field']);


 For Get variables: 

 $thething = mysql_real_escape_string($_GET['id']);


 For Request variables: 

 $thething = mysql_real_escape_string($_REQUEST['id']);

Lütfen ne düşündüğünüzü bana bildirin.

 1
katma düzenlendi
Görünümler: 12
kaynak
ro ru fr es pt de hi bn ar kk uk
@tom teşekkürler ama şaşkın lol olsam iyi olan ne
katma yazar Sam Khan, kaynak
@ col.shrapnel Değişkenlerinizi doğru bir şekilde bağlar veya biçimlendirirseniz, güvenlik hakkında konuşmak, her iki yöntem arasında fark yoktur. Bağlama sadece daha basittir, çünkü sadece kaçış için kullanılamazken kaçmak mümkün değildir (bu yüzden kaçmak/alıntılamak yerine bazı değişkenler atmanız gerekir). Ayrıca, hiçbir bağlayıcı veya kaçmanın tanımlayıcıyı güvenli hale getiremeyeceğini unutmayın. Dolayısıyla, sorgunuzda bir alan adı veya operatör kullanmanız gerekiyorsa, kodunuzda kodlanmış bir değer kullanmanız gerekir. //// Yani haklı mıydım? hangisini kullandığınız önemli değil mi?
katma yazar Sam Khan, kaynak
olası bir kopyası İçeride PHP değişkeni nasıl eklenir? MySQL ek ifadesi
katma yazar Your Common Sense, kaynak
evet, ne yaptığınızı ve kurallara uyup uymadığınızı biliyorsunuz.
katma yazar Your Common Sense, kaynak
PHP'de SQL Injection'ı durdurmanın en iyi yolu
katma yazar Quentin, kaynak
En azından yeni bir PHP geliştiricisi olarak Mysql enjeksiyon korumasına bakmanın bir anlamı vardı! Kudos sana efendim. Bunu her gün görmüyorsun.
katma yazar Tom, kaynak
Yeni bir geliştirici olarak kaçan dizgeye güvenirsiniz, ilerledikçe siz de enjeksiyondan kaçınmanıza yardımcı olacak bir kütüphane kullanırsınız ve pdo_mysql gibi hayatınızı kolaylaştırır. Bu SELECT, INSERT, UPDATE yazısını kendi başınıza bir acıdır. Güven bana :) Belki bir süre içinde daha fazla yardımcı olacak bir çerçeve kullanacaksın.
katma yazar evildead, kaynak

5 cevap

Hazırlanan ifadeleri her zaman kullanmanın, tüm parametrelerin düzgün bir şekilde kaçtığından emin olmaktan daha kolay olduğunu buluyorum. Bu yüzden hazırlanmış ifadeleri tavsiye ediyorum.

İlgili sorular:

mysqli hazırlanmış ifadeler ve mysqli_real_escape_string

real_escape_string vs. hazırlanan ifadeler

1
katma
kaynak

Muhtemelen kötü niyetli kullanıcı girişinden çıkmak için mysql_real_escape_string kullanma eğilimindeyim.

Hazırlanan ifadeler de aynı sonuca ulaşır, bu nedenle, kullanıcı girdisini manuel olarak çıkarmayı unuttuğunuzu fark ederseniz, hazırlanmış ifadeleri kullanabilirsiniz, ancak bir süredir kaçan girdilerden sonra, ikinci doğa haline gelir.

CakePHP veya CodeIgniter gibi bir PHP çerçevesi kullanıyorsanız, genellikle aynı işlevleri sağlarlar. Örneğin, CodeIgniter'ın Aktif Kayıtlar sizin için tüm giriş sanitizasyonunu üstlenir.

Ekstra güvenlik bilgileri:

Web geliştirmede yeni olduğunuza göre (aynı şekilde), ayrıca XSS Enjeksiyonlarına da dikkat edin. , başka bir güvenlik açığı.

Son olarak, savunma kodu. Web siteniz kamuya açık olduğundan, Web geliştirme durumunda bu çok daha önemlidir. Form verisini Javascript ile doğruladığınız durumlarda, PHP betiğinizde doğrulama gerçekleştirin. Gereksiz görünebilir, ancak JS'yi atlamak mümkündür (tek yol tarayıcıda JS'yi devre dışı bırakmaktır).

Salt passwords at the time of hashing, avoid md5 hash. Go for either sha256, sha512 or bcrypt.

Güvenliğinizle, meseleniz tehlikeye girmeyecektir, bunun yerine olduğunda sizi tehlikeye atacaksınız. Güvenlik sürekli, bitmeyen bir süreç olmalıdır.

0
katma
kaynak
haha ... şimdi sen beni şaşırttın. Yukarıdaki yorumda yayınladığım linkte yer alan örnek # 2, şifre için izinsiz bir kullanıcı girişinin nasıl yetkilendirilebileceğini göstermektedir. bir göz atabilirsin, ve belki de onlarla uğraştığım için biraz ışık tutabilirsin
katma yazar xbonez, kaynak
mysql_real_escape_string , kullanıcı girdisini dezenfekte etmek zorunda değildir, ancak argüman olarak iletilen herhangi bir diziyi dezenfekte edecektir. Kullanıcı girişini tutan bir $ _ POST değişkenini iletirseniz, kullanıcı girdisini dezenfekte edersiniz, değil mi? Örneğin, örneğin # 2 burada php.net/manual/ en/function.mysql-real-escape-string.php kullanıcı girdisini dolaylı olarak sterilize etmiyorlar ( $ _ POST ['password'] içinde tutuluyor)?
katma yazar xbonez, kaynak
teşekkürler @xbonez tüm önerilerinize bakacak.
katma yazar Sam Khan, kaynak
Sizi bilgilendirmek için mysql_real_escape_string'in kullanıcı girişi ile ilgisi yoktur.
katma yazar Your Common Sense, kaynak
bilmeni isterim ki, mysql_real_escape_string de sanitizing ile ilgisi yok :)
katma yazar Your Common Sense, kaynak
Emin. Bu işlev "dezenfekte" değildir. Bu işlev sadece sınırlayıcılardan kaçmak içindir . Böylece, sınırlayıcılar yok - mysql_real_escape_string için kullanmayın. `` `ve alan = $ _POST ['alan']" `(enjeksiyon değeri de dahil) örneğinize ekleyin ve bakın.
katma yazar Your Common Sense, kaynak

Bunun sql enjeksiyon için oldukça hassas olduğunu düşünüyorum:

$ thething = mysql_real_escape_string ($ _ GET ['id']); mysql_query ("kullanıcıdan kullanıcı kimliğini seçin =". $ thething);

Kavramın ispatı: http: //localhost/index.php? id = uyku (30 )

Bu sayfa, sql enjeksiyonuna karşı savunmasız olduğu için yüklenmesi 30 saniye sürecektir.

Kendinizi sql enjeksiyonundan korumak için daha güvenli bir yaklaşım, PDO veya mysqli gibi parametrized sorgu kütüphaneleridir. Her şeyi test etmelisin. Sitewatch veya atlama balığı .

0
katma
kaynak
Bu şeyi web sitemde denedim. uyku (30) işe yaramadı.
katma yazar Sam Khan, kaynak

Koruma fikrinizin tamamen yanlış olduğunu düşünüyoruz.

  1. hiçbir veri veritabanına zarar veremez. Ancak bazı karakterler bir sorgu 'u kırabilir. Buna izin vermemelisin.

  2. böylece mysql_real_escape_string (); bir dizgiyi kırabilecek karakterlerden kaçmak için.

  3. böylece mysql_real_escape_string (); sadece dizgiler 'den çıkmak için gereklidir. Ve bu, sorgunun herhangi bir parçası ile biraz yardımcı olmaz.

  4. Ayrıca, dizeler yalnızca POST GET ve REQUEST öğelerinden değil, dünyanın herhangi bir kaynağından da sorgulanabilir. bazı kaynaklardan gelmeyen sorguya giden bir dizeden çıkmanız gerekir. Hedef bir sebeptir, kaynak değildir.

  5. Lütfen daha fazla açıklama için yorumlarda bulunan soruya bakın

0
katma
kaynak
Merhaba Albay. # 1 tarafından kafa karışıklığı için özür dilerim (bir sorgu kırma) samthing demek istedim!
katma yazar Sam Khan, kaynak

PreparedStatements, yer tutucu ile kullandığınızda, sizin için girdiden kaçacaktır

SELECT * FROM myTable WHERE `id` = ?

Ancak, onun prosedürel mysql-uzantısı tarafından desteklenmiyor, neden var, neden birçok var olan mysql_ (real_) escape_string() ile kalıyor, ancak Mysqli veya PDO ile kullanabilirsiniz. Geliştirmenin başlangıcında olduğunuzda hazırlanmış ifadeleri kullanmanızı tavsiye ederim.

0
katma
kaynak
mysql kaçış dizesiyle de yapışıyor musun?
katma yazar Sam Khan, kaynak
Neden parantez eklediğiniz herhangi bir sebep: mysql_ (real_) escape_string() ??
katma yazar Sam Khan, kaynak
Ayrıca bir mysql_escape_string() işlevi de vardır.
katma yazar KingCrunch, kaynak
Hayır, özel bir projede ( SQLite3 üstünde) ve şirketimde PDO_Mysql olan PreparedStatements.
katma yazar KingCrunch, kaynak