PHP Filter kodunu bloklarda, düğümlerde, görünüm argümanlarında vs. kullanmanın olumsuz yönleri nelerdir?

Özel PHP / PHP filtresi (Drupal UI'dan) bloklarda, düğümlerde, görünüm argümanlarında, kurallarda vb. Kullanmamayı söyleyen birçok kişi gördüm. Biraz aradım ve fazla bir şey bulamadım, sanırım Bu, tümünün "sadece bildiği" bir Drupal en iyi uygulamasıdır.

Özellikle son kullanıcıların veya Drupal veya PHP’de yeni kişilerin ellerinde potansiyel bir güvenlik riski oluşturduğunu, ancak bir geliştirici / site oluşturucu olarak Drupal UI’dan özel PHP kullanmamanın gerçek nedenleri nelerdir?

Bazı nedenler:

• Veritabanınızdaki kod sürüm kontrollü olamaz ve daha sonra genel olarak bulmak daha zordur.
• Eval () 'd kodu bir dosyada kodlanmış bir şeyden çok daha yavaştır.
• Bu kodda bir yerde bir hata varsa, çok yararsız bir hata mesajı alırsınız (3. satırdaki eval () 'd kodu' ndaki hata kodu) ve hatayı bulmak ve düzeltmek için veritabanınızı el ile bile gözden geçirmiş olabilirsiniz. Tüm sayfalarda görüntülenen ve örneğin her zaman önemli bir hatayla sonuçlanan bir bloğun içindeyse.
• Yukarıdakiler ayrıca Drupal 6'dan 7'ye yükseltme yaparken ve kullandığınız API'ler değiştirilirken de geçerlidir. Bu nedenle, geçiş yaparken kodunuzu taşımak zorunda kalacaksınız. Kod bir modüldeyse önceden taşıyabilir, test edebilir ve yalnızca yeni siteye dağıtabilirsiniz. Bir düğüm veya blok içinde, yalnızca Drupal 6 veya 7 ile çalışır.
• Bu kodu yazmak ve korumak da daha zordur, çünkü tarayıcınızın içindeki bir metin alanında çalışıyorsunuz. Bir modülde olması, sözdizimi vurgulama, otomatik tamamlama vb. İçeren bir düzenleyici / IDE kullanmanızı sağlar.
• İnsanların php yürütme özelliği etkinleştirilmişse ne olursa olsun bir metin biçimine / bloğuna erişmelerini sağlayan bir yanlış yapılandırma olasılığı her zaman vardır. Php.module (D7'de, D6 çok katı değilse, örneğin blok erişim kuralları için) bile etkin değilse, bu risk zaten çok daha düşüktür.
• CMS’niz PHP’nin yürütülmesine izin veriyorsa, XSS’nin güvenlik açıklığını veya ayrıcalık yükselmesini bulan bir saldırgan artık sunucunuzu muazzam derecede kötü niyetli şeyler için kullanabilir (DDOS’un bir parçası olarak, spam göndererek, kötü amaçlı yazılımları barındırarak, sitedeki diğer sitelere / veritabanlarına sızarak) sunucu, ağdaki güvenlik duvarlarının arkasında olabilecek diğer sunuculara hacklenerek). Küçük güvenlik açıklarını daha acı verici hale getirmenin yanı sıra, bu, siteyi php yürütmek için kullanılabileceği biliniyorsa, daha muhtemel bir saldırı hedefi haline getirir.

Daha fazla sebep olabilir ama bu yeterli olmalı :)

Bu kodun hata ayıklaması ve bakımı zordur. Bu tür bir php kodu için sürüm kontrolünü kullanmanın bir yolunu bilmiyorum.

Ve bu gerçekten Drupal veya PHP’de yeni insanlar için potansiyel bir güvenlik riski,

Bir düğümde kullanılan PHP filtresinin durumu dikkate alındığında, bunun kullanılmamasının nedeni, tüm kullanıcıların PHP filtresini kullanmasına izin vermek istemiyorsanız, o düğümü düzenleyebilecek kullanıcıları sınırlamanızdır.
PHP filtresini kullanmak yerine, düğüm içeriğindeki belirli metni yerine koyan (kullanmadan eval()) kodun sonucuyla değiştiren ya da kendi metnini düğümlerin gövde içeriğine ekleyen özel bir modül kullanmak daha iyidir . Bu durumda, herhangi bir kullanıcı, daha sonra PHP filtresi tarafından çalıştırılan rastgele PHP kodu ekleme iznine sahip olmadan düğümü düzenleyebilir.

Genel olarak, kaçınılması daha iyidir eval()çünkü kodun okunabilirliğini, çalışma zamanından önce kod yolunu (ve bunun olası güvenlik uygulamalarını) tahmin etme yeteneğinizi ve dolayısıyla kod hata ayıklama özelliğini azaltır.

Bir geliştirme veya test sitesi dışında, PHP filtresini etkinleştirmem ya da iletilen PHP kodunu kullanmam eval().

PHP filtresi O artık Drupal 8. kaldırıldı bir üçüncü taraf modülü değil karşılanan güvenlik danışma politikası . Bu muhtemelen üretim sunucularında kullanmamak için daha fazla bir nedendir (önceden verilen nedenler sizi ikna etmediyse).

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

Her zaman bulunan bazı dosyalarda işlevler oluşturun (ne yaptıklarına göre onları dikkatlice adlandırın) - siteye yazdığınız özel bir modülünüz varsa, bu işlevleri koymak için harika bir yer. Girdiğiniz php basitçe şudur: return my_specialfunc($somevar);- $somevarburada potansiyel olarak üzerinde çalışılan düğüm nesnesi veya burada başka hangi değişkenlerin alakalı olduğu.

Hala bazı yerlerde kendi kodumu çağırmanın esnekliğini hala istiyorum. Bu tekniği kullanırken, kodun korunması kolaydır çünkü dosyadaki işlevi değiştirme meselesidir. Fonksiyon arkadan göründüğü için hata bulma kolaydır.

Bununla birlikte, bunun olası güvenlik sorunlarını çözmediğine dikkat edin. Bunlar büyük ölçüde Drupal çekirdeğinin güvenliğine bağlıdır. Genel olarak, veritabanı içeren kod genellikle bir achillees 'güvenlik toplantısıdır - veritabanı içeren kod kullanan işlevler, sömürüye daha yatkın olma eğilimindedir ve çevrelerindeki güvenliğin çok sıkı olması gerekir. Bununla birlikte, Drupal genel olarak bu konular için güvenliği sağlamada oldukça başarılı olmuştur - ortaya çıkmış ve daha sonra yeni sürümlerle hızlı bir şekilde yamalanmış / çözülmüştür.

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

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

Drupal db kimlik bilgilerini kesmek

Gibi bir şey yapmak yerine return functionname($object), belirteçleri / filtreler sistemi mümkün olduğunca kullanmak daha iyi olurdu. İnsanların PHP'yi düğüme veya blok gövdelerine gömmek isteyebilecekleri genel koşullara yardımcı olabilecek Görünüm Görünümü ve Yerleştirme Düğümü gibi modüller vardır.

Verilerinizin taşınabilirliğini önemsemelisiniz. Düğümlerinizi drupal 7'den drupal 8'e geçirirseniz ve bazı düğümlerin gövde metninde <?php whatever_function_that_does_not_exist_anymore(); ?>bunun varsa?

Projenizi 5 ay içerisinde 5 yıl içerisinde düşünmeyin. Güncellemeler, iyi uygulamalar ve taşınabilirlik bence iyi bir BT projesinin önemli yönleri.

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