Aspekty bezpieczeństwa trzeba wziąć pod uwagę już podczas projektowania aplikacji. Z Łukaszem Lachem, założycielem serwisu PHP5.pl, który jest jedną z największych polskich baz porad i artykułów dotyczących programowania w PHP, rozmawia Bartłomiej Dymecki.
Łukasz Lach jest certyfikowanym inżynierem firmy Zend. Od kilku lat zajmuje się tworzeniem aplikacji internetowych z wykorzystaniem takich technologii jak PHP, XHTML, JavaScript, XML. Jest autorem licznych publikacji prasowych w czasopismach polskich i zagranicznych, tłumaczonych na kilka języków i poruszających tematy projektowania, tworzenia i wdrażania aplikacji internetowych, jak również zagadnienia bezpiecznego programowania.
Bartłomiej Dymecki: Jakie błędy związane z bezpieczeństwem najczęściej popełniają programiści PHP?
Łukasz Lach: Na szczycie listy znajdują się błędy typu SQL Injection oraz XSS (Cross-Site Scripting). Zarówno te, jak i większość najczęściej popełnianych błędów związanych jest z brakiem lub nieprawidłową walidacją danych, pochodzących z zewnętrznych źródeł, a następnie wykorzystaniem ich w kodzie PHP, zapytaniu SQL lub wyświetleniu.
Pamiętajmy, że PHP ma szereg funkcji pomocnych przy walidacji i filtracji zmiennych, a także, że potencjalnie niebezpieczne dane nie występują wyłącznie w zmiennych {stala}$_POST{/stala}, {stala}$_GET{/stala} czy {stala}$_REQUEST{/stala}, ale również w {stala}$_SERVER{/stala}, gdzie większość danych tworzona jest na podstawie żądania przesłanego w celu pobrania strony. Dotyczy to również zmiennej {stala}$_SERVER[\’PHP_SELF\’]{/stala}, o czym wielu programistów bardzo często zapomina.
BD: Które błędy są najbardziej niebezpieczne?
ŁL: Te, które pozwolą nieuprawnionej osobie dokonywać modyfikacji kodu strony (Code Injection, XSS), zawartości tabel bazy danych (SQL Injection) czy danych sesji (Session fixation, Session poisoning, Session injection), czyli praktycznie większość. Ważne jest jednak, aby nie lekceważyć żadnego ze znanych błędów bezpieczeństwa, a już na pewno nie próbować ich kategoryzować na \”mniej\” i \”bardziej\” niebezpieczne.
BD: Czy takie techniki jak AJAX wpływają na poziom bezpieczeństwa w naszych serwisach?
ŁL: Umiejętnie wykorzystane – nie. W przypadku AJAX-a musimy pamiętać, że żądanie pobrania dokumentu poprzez protokół HTTP nie różni się praktycznie niczym, oprócz tego, że jest wykonywane w tle. Tak więc to, że któryś z naszych skryptów obsługuje jedynie żądania AJAX-a nie znaczy, że nie obowiązują go reguły bezpieczeństwa.
BD: Jakie są źródła informacji traktujące o tematach bezpiecznego programowania w PHP?
ŁL: Podstawowym źródłem informacji jest podręcznik PHP, który zawiera dział opisujący niektóre aspekty bezpieczeństwa instalacji, konfiguracji i programowania w PHP (http://pl.php.net/security). Wartym polecenia serwisem jest również PHP Security Consortium (http://phpsec.org). Jeśli chodzi o polskie źródła informacji, to nie istnieje serwis skupiający wyłącznie informacje o bezpieczeństwie programowania PHP, jednak kilka tego typu artykułów znajduje się w takich serwisach jak http://www.php5.pl czy http://www.webcity.pl. Polecam również lekturę artykułu \”PHP – Bezpieczne programowanie\”, który w krótki, ale rzeczowy, sposób opisuje 11 ważnych luk bezpieczeństwa (http://www.anakin.us/blog/php-bezpieczne-programowanie/).
BD: Czy nowa wersja języka PHP, czyli PHP5, wpływa w znaczący sposób na bezpieczeństwo programów?
ŁL: Sama zmiana wersji PHP na nowszą nie spowoduje nagle, że nasze aplikacje staną się bezpieczniejsze. W PHP5 poprawiono pewne aspekty bezpieczeństwa, wyeliminowano np. możliwość przeprowadzenia ataku typu HTTP Response Splitting poprzez uniemożliwienie przesłania więcej niż jednego nagłówka przez funkcję header, jednak to jedynie kropla w morzu potrzeb. To, co naprawdę wpłynęło na bezpieczeństwo w PHP5, to nowe rozszerzenia. PDO, przykładowo, umożliwia nie tylko korzystanie z wielu systemów baz danych za pomocą jednego interfejsu, ale również chroni przed atakami typu SQL Injection, poprzez wiązanie parametrów (ang. binding parameters).
Nie ma więc znaczenia, z której wersji PHP będziemy korzystać, bo ciągle największa odpowiedzialność spoczywa na programiście.
BD: Na jakim etapie realizacji projektu należy najbardziej zwracać uwagę na bezpieczeństwo? Na etapie planowania, czy może wystarczy na sam koniec załatać wszystkie błędy? Czy można to w ogóle jasno określić?
ŁL: Bezpieczeństwo nie jest jakimś dodatkowym komponentem czy rozszerzeniem naszej aplikacji i nie różni się niczym np. od procesu optymalizacji. Aspekty bezpieczeństwa trzeba wziąć pod uwagę już podczas procesu projektowania aplikacji. Zachowanie standardów programowania i wykorzystanie frameworka pozwoli nam ponadto na łatwe i szybkie załatanie luk bezpieczeństwa wykrytych już po etapie programowania. Idea szukania błędów bezpieczeństwa dopiero po zakończeniu programowania jest o tyle nierozsądna, że przysporzy masę niepotrzebnej pracy, a w skrajnym przypadku może doprowadzić do tego, że konieczne będzie napisanie od nowa części kodu.
BD: W jakim stopniu konfiguracja serwerów wpływa na bezpieczeństwo aplikacji pisanych w PHP?
ŁL: W znacznym stopniu. Związanych z tym jest kilka błędów bezpieczeństwa, które przy odpowiedniej konfiguracji serwera i samego PHP po prostu nie mają prawa wystąpić. Przykładowo, błąd typu Session injection pozwala uzyskać dostęp do wszystkich danych zapisanych na serwerze sesji, również tych stworzonych przez serwisy innych kont, z poziomu kodu PHP lub innego, a w skrajnych przypadkach pozwala na ich tworzenie i modyfikowanie. Prawidłowa konfiguracja serwera i zastosowanie odpowiednich praw dostępu tylko do katalogów eliminuje ten problem.
