Jakie są wady korzystania z kodu PHP Filter w blokach, węzłach, widokach-argumentach itp.?

96

Wiele razy widziałem ludzi mówiących, aby nie używać niestandardowego filtru PHP / PHP (z interfejsu użytkownika Drupala) w blokach, węzłach, widokach-argumentach, regułach itp. Szukałem trochę i nie znalazłem wiele, wygląda na to, że jest to najlepsza praktyka Drupala, którą wszyscy „po prostu wiedzą”.

Rozumiem, że stanowi to potencjalne zagrożenie bezpieczeństwa, szczególnie w rękach użytkowników końcowych lub osób, które nie znają Drupala lub PHP, ale jako programista / konstruktor witryn, jakie są prawdziwe powody, aby nie używać niestandardowego PHP z interfejsu użytkownika Drupal?

Laxman13
źródło
1
Jak zwykle zależy to od sytuacji! Jeśli potrzebujesz tylko podstawowego bloku $ print na dole strony Widoki w „stopce widoków”, idealnym rozwiązaniem może być po prostu zrobienie tego za pomocą GUI w porównaniu do napisania całego pliku tpl tylko w tym celu. To oczywiście zależy również od roli witryny i innych czynników: napięty termin? Witryna społeczności użytkowników? A może po prostu strona informacyjna? Czy ma to zasadnicze znaczenie dla operacji biznesowych? itp ... zależy.
Patoshi パ ト シ

Odpowiedzi:

129

Niektóre powody:

  • Kod w bazie danych nie może być kontrolowany pod kątem wersji i trudniej go później znaleźć.
  • Kod Eval () jest znacznie wolniejszy niż coś zapisanego na stałe w pliku.
  • Jeśli gdzieś w tym kodzie jest błąd, otrzymasz bardzo nieprzydatny komunikat o błędzie (błąd w kodzie eval () w wierszu 3) i być może nawet musiałeś ręcznie przeszukać bazę danych, aby znaleźć i naprawić błąd. Jeśli znajduje się w bloku wyświetlanym na wszystkich stronach i powoduje na przykład błąd krytyczny.
  • Powyższe dotyczy również aktualizacji z Drupala 6 do 7 i niezależnie od użytego interfejsu API zostały zmienione. Musisz więc przenieść swój kod podczas migracji. Jeśli kod znajduje się w module, możesz go z wyprzedzeniem przenieść, przetestować i wdrożyć tylko w nowej witrynie. Wewnątrz węzła lub bloku będzie działał tylko z Drupalem 6 lub 7.
  • Pisanie i obsługa tego kodu jest również trudniejsza, ponieważ pracujesz na polu tekstowym w przeglądarce. Posiadanie go w module pozwala na użycie edytora / IDE z podświetlaniem składni, autouzupełnianiem i tak dalej.
  • Zawsze istnieje możliwość błędnej konfiguracji, która daje ludziom dostęp do formatu tekstowego / bloku / czegokolwiek z włączonym wykonywaniem php. Jeśli php.module (w D7, D6 nie jest tak rygorystyczny, na przykład dla reguł dostępu do bloków) nawet nie jest włączony, ryzyko to jest już znacznie niższe.
  • Jeśli Twój CMS pozwala na wykonanie PHP, osoba atakująca, która odkryje lukę w zabezpieczeniach XSS lub eskalację uprawnień, może teraz używać Twojego serwera do bardzo złośliwych rzeczy (w ramach DDOS, wysyłania spamu, hostowania złośliwego oprogramowania, włamywania się do innych witryn / baz danych na serwer, włamywanie się do innych serwerów w sieci, które mogą znajdować się za zaporami ogniowymi). Oprócz tego, że drobne luki stają się bardziej bolesne, czyni to stronę bardziej prawdopodobnym celem ataku, jeśli wiadomo, że można jej użyć do wykonania php.

Może być więcej powodów, ale to powinno wystarczyć :)

Berdir
źródło
3
Ładna lista :) mam nadzieję, że będzie źródłem informacji dla innych
Laxman13,
3
@ Laxman13: „innym”… i dla ciebie też! : D @Berdir: +1, bardzo dobre aspekty. Nawiasem mówiąc, nie musisz pisać całego kodu w polu tekstowym, ponieważ możesz tam również dołączyć plik. Np. Możesz wstawić tylko jeden wiersz w polu tekstowym: require_once $_SERVER['DOCUMENT_ROOT'].'/sites/all/themes/myTheme/php/stuff.php';i napisać resztę kodu w swoim edytorze IDE / tekst. Czasami nie jest to łatwe zadanie lub stworzenie własnego modułu zajęłoby bardzo dużo czasu, nawet jako dobry programista PHP. Jeden krótki przykład: akcje warunkowe Ubercart. Ale to prawda, że ​​nie warto trzymać naszego kodu w db.
Sk8erPeter,
Mam na myśli, że np. Moduł UC Conditional Actions ma bardzo świetny GUI, który oszczędza dużo czasu, bez konieczności pisania własnych długich kodów. Możesz stworzyć naprawdę skomplikowaną akcję w kilka minut za pomocą metody „następnego-następnego-końca” w GUI. Ale może chciałbyś rozszerzyć funkcjonalność o niektóre własne kody - w wielu przypadkach po prostu nie warto opracowywać modułu do tego celu.
Sk8erPeter,
1
+1000 - Widziałem tak wiele projektów spalonych przez prawie każdy punkt na tej liście. Był tylko jeden raz w całym moim życiu, że użycie modułu PHP było jedynym sposobem na zrobienie czegoś w rozsądny sposób, i to tylko z powodu problemu z D6, który został naprawiony w D7.
geerlingguy
Dziękuję za szczegóły. Odpowiedz na to pytanie. Podczas pracy w Drupal znalazłem sytuację, że kiedy musimy dodać link w „edytorze tekstu”, musimy użyć kodu php w „filtrze tekstu”, w przeciwnym razie nie będzie działał zgodnie z oczekiwaniami.
Jayendra Kainthola
17

Ten kod jest trudny do debugowania i obsługi. Nie znam żadnego sposobu użycia kontroli wersji dla takiego rodzaju kodu php.

I to naprawdę potencjalne zagrożenie bezpieczeństwa dla osób, które nie znają Drupala lub PHP,

ya.teck
źródło
1
Cóż, jeśli konfiguracja bloku została wyeksportowana do kodu z modułami funkcji, nie jest problemem poddanie fragmentów php kontroli wersji.
ya.teck
14

Biorąc pod uwagę przypadek użycia filtru PHP w węźle, powodem jego nieużywania jest ograniczenie użytkowników, którzy mogą edytować ten węzeł, jeśli nie chcesz zezwalać wszystkim użytkownikom na używanie filtru PHP.
Zamiast używać filtru PHP, lepiej jest użyć niestandardowego modułu, który zamienia określony tekst w treści węzła wynikiem kodu, który wykonuje (bez użycia eval()), lub dołącza własny tekst do treści treści węzłów. W takim przypadku każdy użytkownik może edytować węzeł bez uprawnień do dodawania dowolnego kodu PHP, który jest następnie uruchamiany przez filtr PHP.

Zasadniczo lepiej jest go unikać, eval()ponieważ zmniejsza on czytelność kodu, zdolność do przewidywania ścieżki kodu (i możliwe implikacje związane z bezpieczeństwem) przed uruchomieniem, a tym samym możliwość debugowania kodu.

Poza witryną programistyczną lub testową nie włączałbym filtra PHP ani nie używałbym przekazywanego kodu PHP eval().

Filtr PHP został usunięty z Drupala 8. Jest to teraz moduł innej firmy , nie objęty polityką bezpieczeństwa . Jest to prawdopodobnie powód, dla którego nie należy go używać na serwerach produkcyjnych (jeśli podane już powody cię nie przekonały).

kiamlaluno
źródło
11

Aby obejść różne problemy opisane powyżej - trudność w utrzymywaniu kodu, kontroli wersji, wyszukiwaniu błędów, masz tę nieco „klugey” możliwość:

Twórz funkcje (nazywaj je ostrożnie, zgodnie z tym, co robią) w pliku, który zawsze jest dołączany - jeśli masz niestandardowy moduł, który piszesz dla witryny, to świetne miejsce na umieszczenie tych funkcji. Php, który wpisujesz, to po prostu: return my_specialfunc($somevar);- $somevartutaj potencjalnie jest to obiekt węzła, nad którym pracujesz , lub jakiekolwiek inne zmienne, które są tutaj istotne.

Uważam, że nadal zazwyczaj chcę elastyczności w niektórych miejscach, aby wywoływać własny kod. Przy użyciu tej techniki utrzymanie kodu jest łatwe, ponieważ jest to po prostu kwestia modyfikacji funkcji w pliku. Wykrywanie błędów jest łatwe, ponieważ funkcja pojawi się w śladzie wstecznym.

Zauważ jednak, że to nie rozwiązuje potencjalnych problemów bezpieczeństwa. Są one w dużej mierze zależne od bezpieczeństwa rdzenia Drupala. Zasadniczo kod zawarty w bazie danych jest często piętą achillesową bezpieczeństwa - funkcje korzystające z kodu zawartego w bazie danych są zwykle bardziej podatne na wykorzystanie, a bezpieczeństwo wokół nich musi być bardzo ścisłe. Jednak Drupal ogólnie był całkiem dobry w utrzymywaniu bezpieczeństwa dla tych problemów - powstały, a następnie szybko załatały / rozwiązały nowe wydania.

James
źródło
11

Oto powód luki w zabezpieczeniach, aby uniknąć udzielania tego uprawnienia użytkownikom, jeśli nie chcesz, aby użytkownicy niebędący administratorami bezpośrednio modyfikowali bazę danych.

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

Włamanie poświadczeń db Drupal

lolcode
źródło
7

Zamiast robić coś podobnego return functionname($object), lepiej, o ile to możliwe, używać systemu tokenów / filtrów. Istnieją moduły takie jak Wstaw widok i Osadź węzeł, które mogą pomóc w typowych okolicznościach, w których ludzie chcieliby osadzić PHP w ciałach węzłów lub bloków.

Evan Donovan
źródło
0

Powinieneś dbać o przenośność swoich danych. Co się stanie, jeśli migrujesz swoje węzły z drupal 7 do drupal 8, a treść niektórych węzłów zawiera <?php whatever_function_that_does_not_exist_anymore(); ?>w sobie?

Nie myśl o swoim projekcie w ciągu 5 miesięcy, ale w ciągu 5 lat. Aktualizacje, dobre praktyki i przenośność są moim zdaniem ważnymi aspektami każdego dobrego projektu informatycznego.

Jednym z aspektów tego jest również korzystanie z jak najmniejszej liczby modułów.

Stef Van Looveren
źródło