Rozszerzenie dla Apache filtrujące wartości wejściowych funkcji


(ra-v) #1

Załóżmy, że chcę zablokować wartość google.com (lub w regexie ^(www.)?google.com$) dla funkcji gethostbyname('google.com'). Chcę, aby przy takim wywołaniu funkcja zwracała cokolwiek innego niż powinna (błąd PHP i przerwanie skryptu, false, null, cokolwiek).

 

Pytanie, czy istnieje rozszerzenie do Apache, które umożliwia blokowanie wg ww. schematu?


(Fizyda) #2

Nie myl apache z php, jeśli coś takiego chcesz szukać to dla php. Apache nie ma nic wspólnego z tym co robi php, on tylko odbiera od niego dane i wysyła dalej.

 

Jeśli chcesz zablokować możliwość łączenia się do zewnętrznych serwerów w celu pobrania jakiś tam danych przez skrypty, może wystarczy dodać do hosts wpis typu google.com 127.0.0.1?


(ra-v) #3

Podałem tylko prosty przykład, chce użyć blokady do innej funkcji na jakieś określone wartości parametru.

Nie chcę używać disable_functions w PHP, bo to zablokuje całą funkcję, a po prostu chciałbym blokować tylko określone przypadki wg własnego widzimisię.


(Fizyda) #4

To raczej się nie da, poza tym nie widzę sensu zastosowania czegoś takiego w innym zastosowaniu niż w podanym wcześniej przykładzie.


(kostek135) #5

Na Apache’u na pewno tego nie zrobisz. Opisz (coś więcej, niż moje widzi mi się) jaki problem próbujesz rozwiązać przy pomocy tak dziwacznego obostrzenia, jak łamanie kontraktu funkcji. Przecież taka sytuacja, że użytkownik nie będzie się spodziewał że funkcja opisana w dokumentacji w sposób A zwraca true, a u ciebie będzie zwracać false, może doprowadzić nawet do jakiś luk bezpieczeństwa w oprogramowaniu. Być może jak podasz opis co próbujesz osiągnąć docelowo, to uda się znaleźć znacznie prostsze rozwiązanie.


(ra-v) #6

Na przykład odblokowanie funkcji exec, ale filtrowanie wartości argumentów przyjmowanych przez funkcje.


(kostek135) #7

Jeśli chodzi konkretnie o exec, to on woła programy w systemie operacyjnym z tego co kojarzę. O wiele lepiej chroot-ować proces w ramach którego działa PHP i dać mu dostęp tylko do określonego wydzielonego środowiska, a to wszystko jeszcze zwirtualizować/konteneryzować (docker ftw) dla dodatkowego bezpieczeństwa w razie, gdyby jakoś napastnik wyłamał się z chroot-a

Z tego co widzę jeszcze w dokumentacji: http://php.net/manual/pl/function.exec.php

jest coś takiego jak tryb bezpieczny i możesz podać katalog z którego można wykonywać polecenia.

Możesz utworzyć dla polecenia wrapper-y w bash-u, które np. regexami przeanalizują argumenty ($1, $2, $3, …) i jeśli są poprawne pchną je do docelowego programu i zwrócą wynik polecenia systemowego.


(ra-v) #8

Tylko jak rozumiem chrootować można proces apache2 (w sensie użytkownika wwwrun), to chroot zadziała dla całego serwera www, czyli przez lukę e serwisie A można coś zrobić w serwisie B.


(Fizyda) #9

Chrootujesz proces php’a a nie apache, por az kolejny Ci mówię że apache nie ma związku z tym co robi php. Każda witryna powinna mieć własnego usera i na jego uprawnieniach działać, czyli pliki witryny powinny być w katalogu home danego użytkownika i z uprawnieniami tego użytkownika powinien zostać uruchomiony interpreter php którego potem ustawiasz w ustawieniach vhosta. Kolejny vhost (witryna) kolejny user i kolejny proces php z innymi uprawnieniami.


(ra-v) #10

Załóżmy że do testów mam /home/srv/www1 i /home/srv/www2, domeny www1.localhost i www2.localhost oraz w systemie 2 użytkowników www1 i www2.

Teraz standardowo skrypty php są uruchamiane przez użytkownika wwwrun i oczywiście wykonując polecenie exec, passthru czy fsockopen można wykonać każde polecenie (np. “ls /home/srv” i odczytać wszystkich użytkowników)…

 

Co musiałbym zmienić w konfiguracji wirtualnych hostów, żeby po wpisaniu http://www1.localhost PHP zadziałało na użytkowniku www1, który nie ma dostępu do www2 również w ww. funkcjach, ale miał dostęp np. do Image Magicka (czyli convert, mogrify)?


(Fizyda) #11

W takiej konfiguracji nie potrzeba exec (czy innych zmyślnych funkcji) żeby posprawdzać pozostałe pliki.


(ra-v) #12

Jeśli stosuje się open_basedir to raczej tak.


(GioWDS) #13

@ra-v poczytaj o suEXEC, php-fpm, chroot-owaniu procesów i innych tego typu rzeczach :wink: