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

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?

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ć :)

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,

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).

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.

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

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.

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.