W kwestii bezpieczeństwa PHP, są dwie strony raportowania błędów. Z jednej strony jest to przydatne, aby zwiększyć bezpieczeństwo, a z drugiej może być szkodliwe. Standardowa taktyka ataku zakłada profilowanie systemu dostarczając mu niepoprawnych danych i sprawdzanie rodzaju i kontekstu zwracanych błędów. To pozwala atakującemu na sprawdzenie informacji o serwerze i określenie potencjalnych słabości systemu. Na przykład, jeśli atakujący pozyskał informacje o stronie na podstawie wcześniej wysłanego formularza, to może spróbować nadpisać zmienne lub je zmodyfikować: ]]> Zwracane błędy PHP zazwyczaj mogą być całkiem przydatne dla programisty, który próbuje znaleźć błąd w skrypcie, wskazując na rzeczy jak funkcja lub plik, który zawiódł, w którym pliku PHP nastąpił błąd, numer linii z błędem. Te wszystkie informacje mogą zostać wykorzystane. Zdarza się, że programiści PHP wykorzystują funkcje show_source, highlight_string lub highlight_file jako narzędzia znajdowania błędów, ale w przypadku działającej już strony, mogą one ujawnić ukryte zmienne, niesprawdzoną składnię i inne niebezpieczne sytuacje. Szczególnie niebezpieczne jest uruchamianie kodu z nieznanych źródeł z użyciem wbudowanych narzędzi debugujących lub używając powszechnych technik debugowania. Jeśli atakujący może określić jakiej techniki używasz, mogą spróbować zastosować atak brute-force na stronę, wysyłając powszechnie znane ciągi znaków związane z debugowaniem: ]]> Niezależnie od metody obsługi błędów, możliwość sprawdzenia systemu pod kątem błędów prowadzi do uzbrojenia atakującego w więcej informacji. Na przykład sam styl ogólnego błędu w PHP daje informacje, że system używa PHP. Jeśli atakujący patrzył na stronę .html i chciał sprawdzić jej backend (szukając znanych luk w systemie), wysyłając złe dane mogą być w stanie odkryć, że system został zbudowany przy użyciu PHP. Błąd funkcji może oznaczać, że system używa konkretnego silnika baz danych lub dać poszlaki odnośnie tego jak strona została zaprogramowana lub zaprojektowana. To pozwala na głębsze zbadanie otwartych portów bazy danych lub sprawdzenie konkretnych błędów i podatności na stronie. Dostarczając różne próbki błędnych danych atakujący może na przykład określić kolejność autoryzacji w skrypcie (w oparciu o numer linii w błędach) lub szukać podatności, które mogą byc wykorzystane w różnych miejscach skryptu. Błąd systemu plików lub ogólny błąd PHP mogą dać informacje jakie uprawnienia ma serwer WWW oraz o strukturze i organizacji plików na serwerze. Kod obsługi błędów napisany przez programistę może pogorszyć ten problem, prowadząc do prostego wykorzystania wcześniej "ukrytych" informacji. Istnieją trzy główne rozwiązania tego problemu. Pierwsze to sprawdzenie wszystkich funkcji i próba zapobieżenia większości błędów. Drugie to całkowite wyłączenie raportowania błędów dla działającego już kodu. Trzecie to wykorzystanie własnych funkcji obsługi błędów w PHP. Zależnie od Twojej polityki bezpieczeństwa, możesz uznać, że wszystkie trzy metody mają zastosowanie w Twojej sytuacji. Jednym ze sposobów wyłapania tej sytuacji przed czasem jest wykorzystanie dyrektywy error_reporting w PHP, aby pomóc sobie w zabezpieczeniu kodu i odkryciu użycia zmiennych, które może być niebezpieczne. Testując swój kod przed wdrożeniem używając poziomu E_ALL możesz szybko znaleźć obszary, w których zmienne są podatne na zatrucie lub ich modyfikację w inny sposób. Gdy jesteś gotowy na wdrożenie, powinieneś albo zupełnie wyłączyć raportowanie błędów, ustawiając error_reporting na 0, albo wyłączyć pokazywanie błędów używając opcji display_errors w &php.ini;, aby zabezpieczyć swój kod przed sprawdzaniem go przed atakującego. Jeśli zdecydowałeś się na drugą opcję, powinieneś też określić ścieżkę do swojego pliku logów używając dyrektywy error_log i włączyć opcję log_errors. ]]>