Jak bezpieczne są natywne funkcje php w przypadku niefiltrowanych danych wejściowych?

Question

Być może jestem nieco paranoikiem, ale kiedy piszę ponownie moduł kontaktu, przychodzi mi do głowy następujące pytanie:

Czy mogę używać niefiltrowanych danych wejściowych w natywnych funkcjach php?

Jest łatwy do dezynfekcji rzeczy umieścić w bazie danych, wyjście na ekranie, itd, ale zastanawiałem się, czy na przykład poniższa instrukcja może być niebezpieczne:

if (file_exists($_POST['brochure'])) { 
     // do some stuff 
    } 

Jeśli ktoś jakoś odpowiedzieć do tej strony, czy powyższy kod może być wykorzystany?

Powyższy kod jest tylko przykładem, mogę myśleć o innych funkcjach używanych podczas przetwarzania formularza.

Edit: Dzięki wszystkim, że file_exists w przykładzie jest faktycznie częścią funkcji sanitarnych ale podczas czyszczenia, funkcje php są wykorzystywane tak szybko staje się jajka i kury historia: Aby korzystać z funkcji, mam oczyścić, ale żeby posprzątać, muszę użyć funkcji.

W każdym razie, mam teraz kilka świeżych pomysłów.

Answer 1

Tak. Wystarczy, że opublikuję "/ etc/passwd" lub "include/dbconnection.php" (lub cokolwiek) na twojej stronie, a w zależności od tego, czym w rzeczywistości jest //do some stuff, mogę ewentualnie usunąć, zmodyfikować lub odczytać poufne informacje . Funkcja file_exists nie zrobi niczego, czego byś się nie spodziewał, ale możesz spodziewać się, że złośliwi użytkownicy będą wykorzystywać Twoją logikę.

Zawsze odkaż dane wejściowe użytkownika. Zawsze. Jeśli spodziewasz się tylko chwycić pliki z jednego konkretnego folderu, nie pozwalają .. lub/na wejściu

Answer 2

mógłby 'broszura' =”../../../../.htaccess'

to ciekawe pytanie.

Apache na moim komputerze jest ustawiony na odmowę wpisywania lub przeglądania plików .ht * oraz .ini i .php.inc, ale martwi mnie to teraz.

Answer 3

builtins PHP nie zrobi „nieoczekiwane” rzeczy na złe wejścia (np file_exists("foo; rm -r /") powie "nie, plik" foo; rm -r/"nie istnieje") ... A jeśli tak, to jest błąd, który możesz zgłosić przeciwko Zendowi.

Oczywiście, to nie ludzie przestają z eksploatacji kod (np file_exists("../hidden/shell.php")), więc powinien nadal (w rzeczywistości, należy zawsze) należy zachować ostrożność podczas przechodzenia wejście użytkownika dostarczony dookoła.

Answer 4

Sam w sobie wygląda to dość bezpiecznie, ale można go wykorzystać do ujawnienia informacji. Może umożliwić atakowi sprawdzenie obecności (lub nieobecności) poszczególnych plików (np. /etc/passwd, /proc/* itd.).

Tak więc w tym przykładzie należy upewnić się, że $_POST['brochure'] jest najpierw oczyszczony, aby akceptować tylko dane wejściowe pasujące do potencjalnie poprawnych nazw plików. Upuść dowolne wejście, które zawiera .. lub rozpoczyna się od /.

Inne funkcje może mieć potencjalnie znacznie gorsze skutki uboczne ...

Answer 5

Trzeba naprawdę być w zwyczaju filtrując cały wkład, ale może chcesz sprawdzić http://www.hardened-php.net/ który dystrybuuje łatę hartowania i „Suhosin”, który jest domyślnie w wielu dystrybucjach binarnych (OpenSUSE, Mandriva i Debian/Ubuntu)

Answer 6

Fakt, że musisz zapytać, jest twoją odpowiedzią. To nie jest bezpieczne.

file_exists() nie jest tak źle, jak inne, ale jeśli nie widzisz kodu źródłowego funkcji, do której przekazujesz dane, i wiesz, jak obsługuje ona dane wprowadzane przez użytkownika, wtedy ryzykujesz.

Nie jest dobrym pomysłem przekazanie niefiltrowanych danych użytkownika do dowolnej komendy systemu plików php. Kluczem bezpieczeństwa jest to, że nigdy nie zezwalaj na wprowadzanie do przełącznika kontekstu. W takim przypadku minimalne odkażanie powinno polegać na usunięciu znaków ścieżki.

Zawsze zakładaj wrogiego użytkownika i najgorsze, co mogliby zrobić, gdyby zobaczyli twój kod źródłowy.

Answer 7

Od lat znaleziono usterki w samym źródle PHP, tak, że funkcje były odporne na ataki w stylu bufferoverflow. Suhosin to/był projekt, który poprawił PHP, aby usunąć część ryzyka.

Answer 8

Co dzieje się z ciągiem bazy danych jest to, że można go pobrać i używać w miejscu, które ma lukę. Aby uzyskać odpowiedź na pytanie, pomyśl o usunięciu kroku, w którym zapisujesz ciąg, a następnie go odzyskujesz. Używasz go od razu i masz takie samo ryzyko.

Answer 9

Nie ufałbym tym funkcjom w ogóle.

Może to zdecydowanie zabrzmieć uderzająco, ale gdy uważnie przyglądam się ludziom i ich jakości kodu C w commits, rewersach, itp. W ciągu ostatnich ośmiu lat, jestem po prostu w ciągłym strachu.