it-swarm-vi.com

Nhược điểm của việc sử dụng PHP Mã bộ lọc trong các khối, nút, lượt xem, v.v.?

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ừ Drupal UI) trong các khối, nút, lượt xem, quy tắc, v.v. Tôi đã tìm kiếm xung quanh một chút và chưa tìm thấy nhiều, có vẻ như đây là một Drupal thực hành tốt nhất 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ự của việc không sử dụng tùy chỉnh PHP từ Drupal UI?

95
Laxman13

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.
  • Mã của Eval () là nhiề chậm hơn so với mã được mã hóa cứng trong tệp.
  • 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 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ã trong khi di chuyển. Nếu mã nằm trong mô-đun, bạn có thể chuyển nó trước, kiểm tra nó 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 trình soạn thảo/IDE với tô sáng 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 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ủ, xâm nhập 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 khiến 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à đủ :)

129
Berdir

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,

17
ya.teck

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 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ô-đ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 thêm 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 tùy ý PHP mã sau đó được chạy bởi bộ lọc PHP.

Nói chung, tốt hơn là 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 PHP mã được truyền cho eval() .

Bộ lọc PHP đã bị xóa khỏi Drupal 8. Hiện tại 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à 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).

14
kiamlaluno

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 các thông tin Drupal db

11
lolcode

Như một cách giải quyết 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 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 tính 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 yếu của bảo mật - các chức năng sử dụng mã chứa cơ sở dữ liệu có xu hướng dễ bị ảnh hưởng hơn khai thác và bảo mật xung quanh chúng cần phải cực kỳ chặt chẽ. Tuy nhiên, Drupal nói chung khá tốt trong việc duy trì bảo mật cho các vấn đề này - chúng đã phát sinh và sau đó nhanh chóng vá/giải quyết bằng các bản phát hành mới .

11
James

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

7
Evan Donovan

Bạn nên quan tâm đến tính di động của dữ liệu của bạn. Điều gì xảy ra nếu bạn di chuyển các nút của mình từ drupal 7 đến 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.

0
Stef Van Looveren