Translate: 
EnglishFrenchGermanItalianPolishPortugueseRussianSpanish

Pilnuj kodu swego…

Black hatWpis ten dotyczy programistów, którzy w nazewnictwie własnych plików wyznają zasadę, że biblioteki PHP powinny nosić rozszerzenie *.php.inc, oraz osób, które z sobie tylko znanych powodów stosują inne warianty rozszerzeń (np. *.inc, *.asp lub *.phtml).

Choć moda na takie nazewnictwo przeminęła wiele lat temu wraz z niektórymi książkami uczącymi języka PHP, okazuje się jednak, że jest to nadal często spotykany proceder w Internecie.

Niestety jest to także jeden z podstawowych i najgroźniejszych błędów bezpieczeństwa.

Jak to działa?

Jako że PHP jest językiem interpretowanym, kody źródłowe skryptów z niestandardowymi rozszerzeniami narażone są na zindeksowanie przez wyszukiwarki internetowe, lub też podgląd ich źródła przy pomocy zwykłej przeglądarki WWW.

Wystarczy wiedzieć, o co zapytać Google, oto przykładowy link z wynikami:
http://www.google.pl/#hl=pl&source=hp&biw=1276&bih=848&q=%2Bfiletype:inc+-furniture+%2Bdb_password&aq=f&aqi=&aql=&oq=&fp=f5c2fe1be1c97f15.

jak widać powyższy link wycelowałem w pliki konfiguracyjne do baz danych, jednak nic nie stoi na przeszkodzie, by skupić się na innego typu wynikach (np.: wylistować kod źródłowy bibliotek PHP użytych na niezabezpieczonej stronie).

Dlaczego jest to niebezpieczne?

Po pierwsze nikt obcy nie powinien znać treści kodów źródłowych używanych „na produkcji”. Jako że nie ma ludzi nieomylnych, nie istnieją też programy bez luk bezpieczeństwa. Potencjalny napastnik po przestudiowaniu kodów może odnaleźć takie błędy, oraz wykorzystać je do przejęcia kontroli nad stroną (np. poprzez SQL injection, atak XSS, czy też obejście logiki biznesowej/walidacji systemu).

Oczywiście ataki tego typu możliwe są do wykonania i bez konieczności poznania kodów źródłowych serwisu. Ujawnienie ich ułatwia jednak pracę napastnikowi, oraz motywuje do przeprowadzenia ataku.

Dodatkowym problemem jest to, że często w plikach z kodem PHP przechowywane są loginy oraz hasła do baz danych, adresy IP serwerów w sieci wewnętrznej serwisu, a nawet zakodowane na sztywno mechanizmy debugujące dane wrażliwe. Dostęp do kodów przez nieupoważnioną osobę oznacza więc często utratę danych klientów, ułatwia także przeprowadzenie ataku na sieć wewnętrzną firmy i pokonanie zabezpieczeń od środka (np. poprzez atak przeprowadzony z maszyny WWW na serwer poczty, nie chroniony przez firewall od strony firmowej sieci LAN).

Jak się przed tym chronić?

Przede wszystkim należy stosować domyślne rozszerzenia plików. Dodatkowo najlepiej jest trzymać wszystkie swoje pliki konfiguracyjne poza katalogiem dostępnym z poziomu przeglądarki WWW.

Umożliwia to zabezpieczenie się przed awarią serwera WWW, w trakcie której wyłączony zostanie parser plików PHP. Przykładem tego typu awarii jest niedawne upublicznienie swoich kodów źródłowych przez portal onet.pl (wyciek żródeł dotyczył na szczęście tylko platformy blogowej).
W normalnych warunkach umożliwiłoby to dostęp do wszystkich kodów PHP, jednak jeśli pliki konfiguracyjne znajdą się w katalogu o poziom wyżej niż główny plik index.php, napastnik nie ma możliwości nawigowania do tego pliku z poziomu swojej przeglądarki.

Wspomniane zabezpieczenia chronią nas też przed innego typu wpadkami, do jakich należą literówki. Bolesnym przykładem okazało się w tym przypadku nadpisanie tagu <?php rozpoczynającego plik konfiguracyjny na serwisie tumblr.

Sporą uwagę należy także poświęcić na to, by zabezpieczyć swoje konfiguracje developerskie przed dostępem ze świata zewnętrznego.
Często podczas programowania skrypty pracują z włączonymi konfiguracjami debugującymi (listującymi np. kod źródłowy w którym powstał wyjątek). Pozwala na łatwe znalezienie błędu nie tylko przez twórcę programu, lecz także potencjalnego napastnika, szczególnue gdy debug pozostał włączony na produkcji.

Tagi:

Dodaj odpowiedź