web-gelistirme-sc.com

PHP Bloklar, düğümler, görünümler-argümanlarda filtre kodu kullanmanın dezavantajları nelerdir?

Ben bloklar, düğümler, görünümler-argümanlar, kurallar, vb özel PHP/PHP filtre (Drupal UI) kullanmak değil diyerek birçok kez gördüm Biraz etrafında aradım ve çok bulamadım , bu "sadece" bildiği Drupal en iyi uygulama gibi görünüyor.

Özellikle son kullanıcıların veya Drupal veya PHP'de yeni olan kişilerin elinde potansiyel bir güvenlik riski oluşturduğunu anlıyorum, ancak bir geliştirici/site oluşturucusu olarak özel PHP 'yi kullanmamanın gerçek nedenleri nelerdir? Drupal Kullanıcı arayüzü?

95
Laxman13

Bazı nedenler:

  • Veritabanınızdaki kod sürüm kontrollü olamaz ve daha sonra genel olarak bulmak daha zordur.
  • Eval () 'd kodu çok dosyadaki sabit kodlanmış bir şeyden daha yavaştır.
  • Bu kodda bir yerde bir hata varsa, çok yararsız bir hata mesajı alırsınız (satır 3'deki eval () 'de hata kodu) ve hatayı bulmak ve düzeltmek için veritabanınızı manuel olarak bile geçmiş olabilirsiniz. Örneğin, tüm sayfalarda görüntülenen ve her zaman ölümcül bir hatayla sonuçlanan bir bloğun içindeyse.
  • Yukarıdakiler aynı zamanda Drupal 6'dan 7'ye ve kullandığınız API'ların değiştirildiği her durumda değiştirilirken de geçerlidir. Bu nedenle, taşıma sırasında kodunuzu taşımanız gerekir. Kod bir modüldeyse, kod bir bağlantı noktası veya blok içinde yalnızca Drupal 6 veya 7 ile çalışır).
  • Bu kodu yazmak ve bakımını yapmak zordur, çünkü tarayıcınızın içindeki bir metin alanında çalışıyorsunuz. Bir modüle sahip olmak, sözdizimi vurgulama, otomatik tamamlama ve benzeri bir düzenleyici/IDE kullanmanızı sağlar.
  • Her zaman insanlara php yürütme etkin bir metin formatı/blok/ne olursa olsun erişim sağlayan bir yanlış yapılandırma olasılığı vardır. Php.module (D7'de D6, örneğin blok erişim kuralları için) çok katı değilse bile, bu risk zaten çok daha düşüktür.
  • CMS'niz PHP) yürütülmesine izin veriyorsa, XSS veya ayrıcalık yükseltme işleminin güvenlik açığını bulan bir saldırgan artık sunucunuzu çok kötü niyetli şeyler için kullanabilir (DDOS'un bir parçası olarak, spam gönderme, kötü amaçlı yazılım barındırma sunucudaki diğer sitelere/veritabanlarına saldırmak, ağdaki güvenlik duvarlarının arkasında olabilecek diğer sunuculara saldırmak) Küçük güvenlik açıklarını daha acı verici hale getirmenin yanı sıra, sitenin, php yürütmek için kullanılabilir.

Daha fazla neden olabilir, ama bu yeterli olmalı :)

129
Berdir

Bu kodun hata ayıklanması ve bakımı zordur. Ben php kodu bu tür için sürüm kontrolü kullanmak için herhangi bir yol bilmiyorum.

Ve bu gerçekten Drupal veya PHP,

17
ya.teck

Bir düğümde kullanılan PHP filtresinin durumu dikkate alındığında, bunu kullanmamanın nedeni, tüm kullanıcılara izin vermek istemiyorsanız, bu düğümü düzenleyebilecek kullanıcıları sınırlamanızdır. PHP filtresini kullanmak için).
PHP filtresini kullanmak yerine, düğüm içeriğindeki belirli metni yürüttüğü kodun sonucu ile değiştiren özel bir modül kullanmak daha iyidir (eval()) veya düğümlerin gövde içeriğine kendi metnini ekler.Bu durumda, herhangi bir kullanıcı keyfi PHP) ekleme iznine sahip olmadan düğümü düzenleyebilir. daha sonra PHP filtresi tarafından çalıştırılan kod).

Genellikle, eval() kodunun okunabilirliğini, çalışma zamanından önce kod yolunu (ve bunun olası güvenlik sonuçlarını) tahmin edebilme yeteneğinizi ve dolayısıyla kod hata ayıklama yeteneğini azalttığı için daha iyi olur. .

Ayrıca bir geliştirme veya test sitesinde, PHP filtresini etkinleştirmem veya PHP kodunu eval() 'e geçirmem .

PHP filtresi Drupal 8'den kaldırıldı.) Şimdi bir üçüncü taraf modülü , - güvenlik danışma politikası Bu muhtemelen üretim sunucularında kullanılmamasının bir sebebidir (daha önce verilen nedenler sizi ikna etmediyse).

14
kiamlaluno

Yönetici olmayan kullanıcılarınızın db'yi doğrudan değiştirmesini istemiyorsanız, kullanıcılarınıza bu izni vermekten kaçınmak için güvenlik açığı nedenidir.

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

Drupal db kimlik bilgilerini kesmek

11
lolcode

Yukarıda belirtilen çeşitli sorunlar için bir çözüm olarak - kod bakım zorluğu, sürüm kontrolü, hata bulma, bu biraz "klugey" olasılığınız var:

Her zaman dahil edilen bazı dosyalarda işlevler oluşturun (bunları yaptıklarına göre dikkatlice adlandırın) - site için yazdığınız özel bir modülünüz varsa, bu işlevleri koymak için harika bir yerdir. O zaman girdiğiniz php basitçe: return my_specialfunc($somevar); - $somevar burada potansiyel olarak üzerinde çalışılan düğüm nesnesi veya diğer değişkenler burada alakalı olabilir.

Ben hala genellikle bazı yerlerde kendi kodumu arama esnekliğini istiyorum bulmak. Bu tekniği kullanırken, kodun korunması kolaydır, çünkü bu sadece dosyadaki işlevi değiştirmektir. İşlev bir geri izlemede görüneceğinden hata tespit etmek kolaydır.

Ancak bunun olası güvenlik sorunlarını çözmediğine dikkat edin. Bunlar büyük ölçüde Drupal çekirdeğin güvenliğine bağlıdır. Genel olarak, veritabanının içerdiği kod genellikle bir achillees güvenlik topukudur - veritabanının içerdiği kodu kullanan işlevsellikler daha eğilimli olma eğilimindedir sömürü ve etrafındaki güvenlik çok sıkı olmalı, ancak, Drupal genel olarak bu konular için güvenliği sağlamada oldukça iyiydi - ortaya çıktılar ve daha sonra yeni sürümlerle hızlı bir şekilde yama/çözüldü .

11
James

return functionname($object) gibi bir şey yapmak yerine, jeton/filtre sistemini mümkün olduğunca kullanmak daha iyi olur. Insert View ve Embed Node gibi, kullanıcıların PHP düğümü veya blok gövdelerine yerleştirmek istedikleri genel koşullara yardımcı olabilecek) modüller vardır.

7
Evan Donovan

Verilerinizin taşınabilirliğini önemsemelisiniz. Düğümlerinizi drupal 7'den drupal 8] 'e taşırsanız ve bazı düğümlerin gövde metninde <?php whatever_function_that_does_not_exist_anymore(); ?> varsa ne olur?

Projenizi 5 ay içinde değil 5 yıl içinde düşünmeyin. Güncellemeler, iyi uygulamalar ve taşınabilirlik, bence iyi bir BT projesinin önemli yönleridir.

Mümkün olduğunca az katkıda bulunan modüller kullanmak da bunun bir yönüdür.

0