Nhược điểm của việc sử dụng mã Bộ lọc PHP trong các khối, nút, khung nhìn, v.v. là gì?

Tôi đã thấy nhiều lần mọi người nói không sử dụng bộ lọc PHP / PHP tùy chỉnh (từ UI Drupal) trong các khối, nút, khung nhìn, quy tắc, v.v. Tôi đã tìm kiếm xung quanh một chút và không tìm thấy nhiều, có vẻ như đây là cách thực hành tốt nhất của Drupal mà tất cả "chỉ biết".

Tôi hiểu rằng nó có nguy cơ bảo mật tiềm ẩn, đặc biệt là trong tay của người dùng cuối hoặc người mới sử dụng Drupal hoặc PHP, nhưng với tư cách là nhà phát triển / người xây dựng trang web, lý do thực sự để không sử dụng PHP tùy chỉnh từ Giao diện người dùng Drupal là gì?

Một số lý do:

• Mã trong cơ sở dữ liệu của bạn không thể được kiểm soát phiên bản và nói chung cũng khó tìm thấy hơn.
• Eval () 'd code đang nhiều chậm hơn so với một cái gì đó hardcoded trong một tập tin.
• Nếu có lỗi ở đâu đó trong mã đó, bạn sẽ nhận được một thông báo lỗi rất không hữu ích (lỗi trong mã eval () 'ở dòng 3) và thậm chí bạn có thể đã đi qua cơ sở dữ liệu của mình để tìm và sửa lỗi. Nếu nó nằm trong một khối được hiển thị trên tất cả các trang và dẫn đến một lỗi nghiêm trọng mọi lúc chẳng hạn.
• Điều trên cũng đúng khi nâng cấp từ Drupal 6 lên 7 và bất kỳ API nào bạn sử dụng đã được thay đổi. Vì vậy, bạn sẽ phải chuyển mã của bạn trong khi di chuyển. Nếu mã nằm trong một mô-đun, bạn có thể chuyển mã trước, kiểm tra mã và chỉ triển khai nó trên trang web mới. Bên trong một nút hoặc khối, nó sẽ chỉ hoạt động với Drupal 6 hoặc 7.
• Viết và duy trì mã đó cũng khó hơn, bởi vì bạn đang làm việc trong một trường văn bản bên trong trình duyệt của bạn. Có nó trong một mô-đun cho phép bạn sử dụng một trình soạn thảo / IDE với đánh dấu cú pháp, tự động hoàn thành, v.v.
• Luôn có khả năng cấu hình sai cho phép mọi người truy cập vào định dạng / khối văn bản / bất cứ điều gì khi thực thi php được kích hoạt. Nếu php.module (trong D7, D6 không quá nghiêm ngặt, ví dụ như đối với quy tắc truy cập khối) thậm chí không được bật, thì rủi ro đó đã thấp hơn nhiều.
• Nếu CMS của bạn cho phép thực thi PHP thì kẻ tấn công tìm thấy lỗ hổng bảo mật của XSS hoặc leo thang đặc quyền giờ đây có thể sử dụng máy chủ của bạn cho những thứ cực kỳ độc hại (như một phần của DDOS, gửi spam, lưu trữ phần mềm độc hại, hack vào các trang web / cơ sở dữ liệu khác trên máy chủ, hack vào các máy chủ khác trên mạng có thể đứng sau tường lửa). Ngoài việc làm cho các lỗ hổng nhỏ trở nên đau đớn hơn, điều này làm cho trang web trở thành mục tiêu tấn công nhiều hơn nếu biết rằng nó có thể được sử dụng để thực thi php.

Có thể có nhiều lý do hơn, nhưng thế là đủ :)

Mã này khó gỡ lỗi và bảo trì. Tôi không biết cách nào để sử dụng kiểm soát phiên bản cho loại mã php đó.

Và nó thực sự là một rủi ro bảo mật tiềm ẩn cho những người mới sử dụng Drupal hoặc PHP,

Xem xét trường hợp bộ lọc PHP được sử dụng trong một nút, lý do không sử dụng nó là bạn giới hạn người dùng có thể chỉnh sửa nút đó, nếu bạn không muốn cho phép tất cả người dùng sử dụng bộ lọc PHP.
Thay vì sử dụng bộ lọc PHP, tốt hơn là sử dụng một mô-đun tùy chỉnh thay thế văn bản cụ thể trong nội dung nút bằng kết quả của mã mà nó thực thi (không sử dụng eval()) hoặc gắn văn bản của chính nó vào nội dung chính của các nút. Trong trường hợp này, bất kỳ người dùng nào cũng có thể chỉnh sửa nút mà không có quyền thêm mã PHP tùy ý, sau đó được bộ lọc PHP chạy.

Nói chung, tốt hơn là nên tránh eval()vì nó làm giảm khả năng đọc mã, khả năng bạn dự đoán đường dẫn mã (và có thể có ý nghĩa bảo mật của điều đó) trước thời gian chạy và do đó khả năng gỡ lỗi mã.

Ngoài một trang web phát triển hoặc thử nghiệm, tôi sẽ không kích hoạt bộ lọc PHP hoặc sử dụng mã PHP được truyền vào eval().

Bộ lọc PHP đã bị xóa khỏi Drupal 8. Hiện tại nó là mô-đun của bên thứ ba , không nằm trong chính sách tư vấn bảo mật . Đây có lẽ là một lý do nhiều hơn cho việc không sử dụng nó trong các máy chủ sản xuất (nếu những lý do đã được đưa ra không thuyết phục bạn).

Là giải pháp cho các vấn đề khác nhau được chỉ định ở trên - khó khăn trong việc bảo trì mã, kiểm soát phiên bản, tìm lỗi, bạn có khả năng hơi "klugey" này:

Tạo các hàm (đặt tên cho chúng một cách cẩn thận, theo những gì chúng làm) trong một số tệp luôn được bao gồm - nếu bạn có một mô-đun tùy chỉnh bạn đang viết cho trang web, đó là một nơi tuyệt vời để đặt các hàm này. Php mà bạn nhập sau đó chỉ đơn giản là: return my_specialfunc($somevar);- $somevarở đây có khả năng là đối tượng nút làm việc hoặc bất kỳ biến nào khác có liên quan ở đây.

Tôi thấy rằng tôi vẫn thường muốn sự linh hoạt, ở một số nơi, gọi mã của riêng tôi. Khi sử dụng kỹ thuật này, việc duy trì mã rất dễ dàng vì nó đơn giản chỉ là vấn đề sửa đổi chức năng trong tệp. Phát hiện lỗi là dễ dàng vì chức năng sẽ hiển thị trong một backtrace.

Tuy nhiên, lưu ý rằng điều này không giải quyết được các vấn đề bảo mật tiềm ẩn. Chúng chủ yếu phụ thuộc vào sự bảo mật của lõi Drupal. Nói chung, mã chứa cơ sở dữ liệu thường là điểm bảo mật của achillees - các chức năng sử dụng mã chứa cơ sở dữ liệu có xu hướng dễ bị khai thác hơn và bảo mật xung quanh chúng cần phải được bảo mật chặt chẽ hơn. Tuy nhiên, nói chung, Drupal khá giỏi trong việc duy trì bảo mật cho những vấn đề này - chúng đã phát sinh và sau đó nhanh chóng được vá / giải quyết với các bản phát hành mới.

Dưới đây là lý do lỗ hổng bảo mật để tránh cấp quyền này cho người dùng của bạn nếu bạn không muốn người dùng không phải quản trị viên của mình sửa đổi trực tiếp db.

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

Hack thông tin đăng nhập db Drupal

Thay vì làm một cái gì đó như return functionname($object), sẽ tốt hơn là sử dụng mã thông báo / bộ lọc trong hệ thống càng tốt. Có các mô-đun như Chèn Chế độ xem và Nút nhúng có thể trợ giúp trong các trường hợp phổ biến trong đó mọi người muốn nhúng PHP vào các nút hoặc khối thân.

Bạn nên quan tâm đến tính di động của dữ liệu của bạn. Điều gì sẽ xảy ra nếu bạn di chuyển các nút của mình từ drupal 7 sang drupal 8 và một số văn bản cơ thể của nút có <?php whatever_function_that_does_not_exist_anymore(); ?>trong đó?

Đừng nghĩ về dự án của bạn trong vòng 5 tháng nhưng trong vòng 5 năm. Theo tôi, cập nhật, thực hành tốt và tính di động là các khía cạnh quan trọng của bất kỳ dự án CNTT tốt nào theo quan điểm của tôi.

Sử dụng các mô-đun càng ít đóng góp càng tốt cũng là một khía cạnh của điều này.