SQL enjeksiyonuna karşı koruma neden yüksek öncelikli değil?


39

Yığın Taşması konusunda, on yıldan fazla bir süredir yaygın olarak bulunabilecek temel geçici çözümlere rağmen, SQL enjeksiyon saldırılarına karşı oldukça savunmasız olan MySQL sorguları olan soru ve cevaplarda birçok PHP kodu görüyorum.

Bu tür kod parçacıklarının halen kullanımda olmasının bir nedeni var mı?


37
kötü yazılmış çevrimiçi öğreticiler suçluyorlar. çoğu zaman, insanlar internette buldukları kodu kopyalayıp yapıştırıyorlar. JavaScript de bu tür bir uygulamanın kurbanıdır.
KJYe.Name

34
Blogları suçla. Oh, ve W3Schools ...
Brian Driscoll

13
Evet, kesinlikle W3Schools - bkz w3fools.com
DisgruntledGoat

2
İnsanları sql enjeksiyonu konusunda sürekli uyarıyorlar - bu nedenle bu sorunun öncülünün geçerli olduğunu sanmıyorum. Bu ise yüksek öncelikli.
GrandmasterB

3
Cevapların çoğunda gördüğüm şey, eleştirel olarak kırılmış PHP'yi öğretmekten çok, eleştirel olarak kırılmayan PHP'yi öğretmekten daha kolay olmasıdır. Bu argümanı kabul edemez ve hala PHP'nin kötü bir dil olmadığını iddia edemezsiniz
user16764

Yanıtlar:


34

Sanırım çoğunlukla a) cehalet b) tembellikten kaynaklanıyor. Yeni başlayanlar genellikle sql enjeksiyonu hakkında çok fazla şey bilmezler ve duydukları zaman bile, bunu görmezden gelirler, çünkü bu şekilde kodlanması çok daha basit ve kolaydır.


8
Bu tür sorunları başka yerlerde düzeltmeye çalıştım, yalnızca eldeki sorunla alakalı olmadığını söylemek için. Bu yüzden birçok insan, biraz daha karmaşık bir iyi çözüme basit bir hack atmayı tercih ettiğinden, kötü örnekler yalnız kalır.
l0b0

6
Çoğu insan, kendisine isabet edene kadar SQL enjeksiyonunu gerçekten umursamıyor. Sonra aniden masalarının nereye gittiğini merak ediyorlar.
Joel Etherton

1
Diğer bir sebep de, SQL enjeksiyonunun her zaman dahili uygulamalar için ilgili bir endişe olarak görülmemesidir. (Doğru değiller.)
John Fisher

1
Unutma, cevaplar soruyu cevaplamak için orada. Genellikle soruyu cevaplaması amaçlanan sözde koddur (veya SQL), mutlaka güvenli ve güvenli bir kopyala ve yapıştır çözümü sağlamaz (cevabın gerçekte nasıl kullanılmasına rağmen).
Dalin Seivewright

1
@ l0b0 İnsanları SQL enjeksiyonundan alan kişilerin gerçekten geçerli üretim koduna karşı bir SQL enjeksiyon saldırısı göstererek ciddiye aldıklarını biliyorum.
user16764

26

PHP, kasten, gerçekten çok kullanışlı insanlar için dinamik web sayfaları oluşturmak için çok az şey bilenler için yapar. Bu, PHP'nin faydalı bir şeyler yaratan, diğer yararlı görünen örneklerden öğrenen ve diğerlerine bu güzel ve faydalı şeyi nasıl yapacaklarını öğretmek için birçok yeni başlayanın dikkatini çekeceği anlamına gelir. Sonuç, birçok kötü kod ve daha iyisini bilmeyen bir programcı kaynağıdır.

Yetkili programcıların büyük bir kısmının PHP ile hiçbir şey yapmak istememesi, işleri daha da kötüleştirir. Bu, başkalarına daha iyi öğretmek isteyen deneyimli insanların temelini azaltır. Ama neden PHP'den kaçıyorlar? Faktörlerin bir kombinasyonu için iyi. Kısmen dil siğilleriyle uğraşmayı sevmiyorlar. Ve kısmen bunun nedeni iyi kodla çalışmayı tercih etmeleridir ve orada pek iyi PHP yoktur.

Bu, Perl'e zarar vermek için kullanılan problemlerin tam takımyıldızıdır. Parlayan bir örnek olarak, 1990'larda geri CGI senaryoları yerleştirmek için pek çok yararlı, iyi belgelenmiş ve kolay kurulum sağlayan hevesli bir genç olan Matt Wright'ın durumunu düşünün. Maalesef güvenlikle ilgili hiçbir şey anlamadı ve eşyalarını kullanmak isteyenler de yoktu. Sonuçta, erken CGI betikleri için sınırsız bir güvenlik problemi akışı olan Matt Wright Script Arşivleri vardı. Http://www.scriptarchive.com/nms.html gibi çabalara rağmen , paylaşılan barındırma sağlayıcıları PHP'yi her şeyden daha kullanışlı hale getirene kadar sorun Perl için düzelmedi. Bu Perl'den PHP'ye geçerken soruna yol açar.


Dediğiniz gibi, sorun perl veya PHP değil, bu dillerin yeni başlayanlara birçok şey yapmasına izin veriyor, ki bu iyi, ancak her zaman onları açıkça görecek kadar iyi yapmanın yollarını sunma.
Zachary K

2
@ ZacharyK: O zaman dil varsayılan olarak bu hatam değil mi?
Monica

6
@ tomalak-geretkal: "Fail" kelimesini kullanıyorsunuz, sanırım yapabileceğiniz şeyleri yapmak kötü bir şey. Pek çok kötü kodla sonuçlanan aynı özellikler, birçok gerçek sorunun çözülmesine de yol açar. Bunun genel olarak kötü bir şey olduğu açık değildir.
btilly

Re 'hata': HTML (ya da onu yorumlayan tarayıcılar) XSL kadar hataya dayanıklı olsaydı, hiçbir zaman dünya çapında bir ağ
olmazdı

8

Ne yazık ki, orada fazladan fazla PHP öğreticisi yok ve bazı eski PHP kitapları da insanlara uygun kod yazmalarını söyleyerek emiliyor (register_globals vb. Kullanılmıyor).

Ek olarak, magic_quotes_gpcgeçmişte etkin hale geldiklerinde, insanlar “sadece işe yaradı” diye kaçmayı umursamadılar.


4

Şahsen, PHP'nin kullanımı kolay olduğuna inanıyorum, bu yüzden doğal olarak kötüye kullanımı da kolay.


2

Bir insan ve bir programcı olarak, hata yapmak ve özellikle zaman için basıldığında bazı şeyleri gözden kaçırmak oldukça kolay.

Belirli bir dili suçlamak, kendi iyiliği için fazla erişilebilir olmak kolay ve belki de çok cazip. Fakat bu, programlamak için seçilen dilden bağımsız olarak, daha büyük insan yanılabilirliği sorununu aydınlatacaktı.

Kabul, montaj dilinden bu yana çok yol kat ettik ve sanırım PHP, Python, Ruby veya Java gibi daha modern bir dilde çok daha üretken programlama yapacağımı düşünüyorum.

PHP (ve diğer betik dilleri) aslında giriş engelini azaltmıştır. Bu, programlamaya yeni başlayanların önce PHP'yi denediği anlamına gelebilir. Ancak bu kesinlikle tüm PHP programcılarının bir şekilde daha az nitelikli oldukları veya hatalarından başka dillerin programcılarından daha az öğrenebilecekleri anlamına gelmez.

Rasmus Lerdorf, 1994'te PHP'yi orijinal haliyle yarattı, o zamandan beri önemli ölçüde gelişti. En modern enkarnasyonunda, nesne yönelimli programlamanın yanı sıra Symfony gibi mükemmel çerçeveleri de destekler. Dil olarak PHP, orijinal kısıtlamalarından kurtuldu ve programcıların onu kullanmayı nasıl seçebileceği konusunda büyük esneklik sunacak şekilde büyüdü. 9.000 satırlık bir spagetti kodu yazması için kullanabilirsiniz veya Symfony gibi modern bir MVC çerçevesi bağlamında kullanabilirsiniz: Bu sizin seçiminiz!

Güvenlik açıklarının tek bir dille sınırlı olmadığından şüpheleniyorum. Tüm PHP programcılarını bir şekilde daha az yetenekli ya da güvensiz kod yazmaya meyilli olarak yazmak caziptir. Fakat bunun dil önyargısının ne kadar olduğunu ve bunun gerçekte ne kadar olduğunu merak ediyorum?


"Bütün PHP programcıları" hakkında hiçbir şey söylemedim.
Monica ile Hafiflik Yarışları,

2

Bence problemin bir kısmı, ne yaptıklarını öğrenmeye zahmet etmeden basitçe kod kopyalayan insanlar, ama gerçekten aklımda porgamnming öğretme şeklimiz bozuldu ve bu çok kötü kodun olmasının sebeplerinden biri. Bağlam dışı sözdizimini öğretiyoruz ve yeni başlayanlar bir şeyi ne zaman kullanacaklarını, ne zaman kullanmayacaklarını veya ne tür problemleri çözmeyeceklerini ve ne problemleri çözmeyi amaçlamadıklarını bilmiyor. Bu yüzden bir anahtar daha iyi bir araç olduğunda bir çekiç kullanırlar.

Örneğin, sadece sözdizimi öğretmek yerine, kursu şu şekilde düzenlersiniz (Açıkça daha fazla adım olacaktır, bu sadece sözdizimi öğretmek yerine temelden karmaşık sorunlara kadar temel bir yapı örneğidir):

  1. Temel bir web sayfası bu şekilde kurulur
  2. Bu, web sayfasını bir veritabanından veri çekme şeklinizdir
  3. Bir web sayfasından veri tabanına veri göndermenin yoludur.
  4. Bu, doğru verilerin gönderildiğinden emin olmanızı sağlar.
  5. Veritabanınızı zararlı veri girişinden bu şekilde korursunuz

Bu daha az ya da çok, php +1 'e öğretilme şekli
Rémi

1

Benzer derecede MS SQL + ASP / ASP.NET örnekleri kadar savunmasız olduğunu düşünüyorum.

Sorunun kısmen bir şeyleri öğretmeye çalıştığınızda, bir WHERE yan tümcesi kullanarak verileri filtreleme derken, o zaman gerçekten sorgu dizginizden kaçan veya parametrik bir komut kullanarak örneğinizi karıştırmak istemediğinizden kaynaklandığını hissediyorum.

Uzun yıllardır geliştiricilerin eğitimi aldım ve öğreticilerde korkunç kod yazan insanlarla empati kurabiliyorum. Bazen en kolay anlaşılan budur. Ancak, bir kenara her zaman savunmasız olan bir kodu işaret ediyorum ve onu ilginç bir konu haline getirdim.


6
Bu bir yana olmamalı. Bu temel dersin bir parçası olmalı. Muhtemelen büyük, şişman, bir şeyler yapmanın yanlış yolu hakkında uyarı. İnsanlar ilk gördüklerini kesip yapıştırma eğilimindedirler ve bunun bir şeyler yapmanın doğru yolu olmasını istersiniz.
btilly

Kesinlikle. NET dünyasında parametreleştirme bugünlerde oldukça basittir ve aslında 'birinci sayfa' olması gerekir.
Alan B

1

PHP'nin orijinal yazarı Rasmus Lerdorf , rezil blog girişinde "çerçevesiz" gelişmeyi savunuyor . SQL sorguları için PDO kullanmasına rağmen, SQL enjeksiyon riski yoktur. Yine de ORM katmanlarıyla modern MVC çerçevelerine kıyasla oldukça çirkin ve modası geçmiş.


5
İhtiyacınız olmayan karmaşık çerçevelere sahip siteleri fazlasıyla geliştirmek kesinlikle mümkün. Bence Rasmus'in önerileri ceza gerektiren tehlikelerden doğuyor, ama kesinlikle akıllıca bir orta yol var.
Monica

Günümüzde ORM kullanarak aşırı mühendislik değildir; bu standart. Yani MVC desen kullanıyor.
vartec

3
@vartec: Tüm koyunlar ( 's değerinde bile değil ne için ve bunu kullanıyor sırf Pek "standart" var bütün koyunlar vardır kullanmadan). Küçük senaryolar için kolayca fazla mühendislik yapılabilir.
Monica

1
@Tomalak: Standart, çünkü temiz ve sürdürülebilir projeler yürütmenin yolu budur. "küçük senaryolar" zamanla büyür ve sürdürülemez canavarlıklara dönüşür.
vartec

2
@vartec: "Standart" ın anlamını yanlış anladığını düşünüyorum.
Monica

1

Bu zayıf uygulamayı PHP'nin kendisinde suçlayabilirsiniz. PHP'nin eski sürümleri (yaklaşık 2006 yılına kadar), tüm GET ve POST giriş değişkenlerinden kaçar, böylece DEFAULT BY veritabanı sorgu enterpolasyonu için uygun olurlardı. Http://php.net/manual/tr/security.magicquotes.php adresine bakın.


2
TÜM değişkenlerden kaçıyorlardı, özel olarak MySQL'e giriyorlardı, hiç olsunlar olmasınlar gibi . Dil tasarımcılarına not: Kendinizi uygulamak zorunda hissettiğinizde stripslashes(), zaten yanlış yaptınız.
Dan Ray

0

Bir üretim ortamında yapılması gerekenlerle basitçe bir şey göstermek için yapılan bir öğreticinin amacını karıştırmayın. Örneğin, yazdığım çoğu öğretici kodun hata / istisna kontrolü çok az veya hiç yok. Okuyucuya, kodun tüm olası sonuçları nasıl kapsayacağını değil, sadece belirli bir görevi nasıl yerine getirdiğini gösterdiğini hatırlatmaya çalışıyorum.


3
Üzgünüz, fakat kesinlikle hiçbir örnek kod, mySQL sorgularını PHP ile karıştırmamalıdır. Bu sadece yanlış yapıyor.
Raynos

1
Ve sorumsuzca.
Monica

-1 most tutorial code I have written has little or no error/exception checking..
yannis

OP'nin amacını görebiliyorum. Sorumsuz, bir işveren, SQL enjeksiyonu ve benzeri hakkında bilgisi olmayan bir adamı işe aldığında.
Raffael

Doğrudan bu açıklamaları "Üretimde kullanmayın!" Koduna eklerseniz, bu yaklaşımın savunulabileceğini düşünüyorum . Bu şekilde kopya / pasterlerin mazereti yoktur.
Benjol

-1

PHP öğrenirken bazı PHP + MySQL kitaplarına baktım ve evet, bu kötü uygulamaya katkıda bulunduğunu hissediyorum. Ancak , iyi programlama uygulamaları değil , dili öğrettikleri için sempati duyuyorum . Aksi takdirde nerede bitecek?


2
Ancak dili öğretirken, örneklerde yine de tercih edilen API'leri kullanmalısınız. Her zaman olduğu gibi, her zaman olduğu gibi SQL sorgularının parametrik formunu kullanın, muhtemelen "Bunun yerine SQL oluşturmak için enterpolasyon kullanmayı düşünmeyin. Bu biraz daha kolay görünüyor, ancak güvenlik açıklarına aşırı derecede eğilimli" gibi bir dipnot ile.
Jan Hudec

Evet, iyi noktalar. Dipnotlar iyi bir hatırlatma olurdu ve bu çevrimiçi öğreticiler için de geçerli. Yine de tüm ciddiyetle, bütün dillerin kitap yazarlarının OWASP'dan gelen önerileri başlangıç ​​metinlerine dahil etmeleri harika olurdu. Sadece bir referans olarak bile. OWASP Vakfı iyi bir iş çıkardı.
Steve Rathbone

@indifferentDrum: İnsanlara ayaklarıyla da araba kullanmayı öğretebilirsiniz - bunun iyi bir fikir olduğu anlamına gelmez.
Monica
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.