Bezpieczeństwo PHP
Na podstawie materiału z konferencji PHP 2003 (http://download.4programmers.net/tmp/php_bezpieczenstwo.pdf) dochodzę do wniosku, że jest sporo rzeczy, o które należy zadbać, aby aplikacja była bezpieczna!
W poprzednim artykule pisałem o dyrektywie „include”, dzięki której programista nie musi wielokrotnie wpisywać w programach tego samego bloku kodu. Zastosowanie tego mechanizmu ułatwia również pielęgnację aplikacji, ponieważ kod wykorzystywany na wielu stronach wystarczy raz zmodyfikować.
Używanie dla włączanego kodu nazw plików, które nie są przetwarzane przez PHP, ale bezpośrednio zwracane przez serwer WWW może spowodować poważne zagrożenia. Jednym z nich jest fakt, że użytkownicy mogą znaleźć słabe punkty w kodzie i je wykorzystać. Może również zdarzyć się, że zostaną w ten sposób ujawnione hasła zapisane w tych dołączanych plikach.
Tak więc należy pamiętać, aby dla plików dołączanych zawsze stosować rozszerzenie *.php, a nie często stosowane *.inc, ponieważ pliki *.inc przy próbie przeglądania nie są przetwarzane przez interpreter PHP.
Należy generalnie zadbać o to co dostajemy od użytkowników. Należy zadbać o prawidłową walidację formularzy. Dane pochodzące od użytkowników (z formularzy) należy zweryfikować i ewentualnie w razie potrzeby unieszkodliwić wprowadzone w nich znaki specjalne. W danych przeznaczonych do wyświetlania w przeglądarce, trzeba sprawdzić, czy przypadkiem nie zawierają kodu HTML, który mógłby być wykorzystany do przeprowadzenia ataków przy użyciu skryptów krzyżowych. W tym przypadku stosuje się funkcję „htmlentities” lub „htmlspecialchars”, która ma za zadanie zamieniać wybrane znaki w wyrażeniu, na odpowiadające im zamienniki (tzw. encje), dzięki czemu te nie będą interpretowane przez przeglądarkę jako znacznik HTML i zostaną prawidłowo wyświetlone.
Należy zadbać również o wyłączenie opcji register_globals = off, co spowoduje wyeliminowanie wielu popularnych ataków na aplikacje PHP.
Czasami warto również zadbać o to aby w razie kłopotów programu, na przykład z dostępem do bazy danych nie wyświetlać domyślnych komunikatów z błędami. Zmniejszenie ilości informacji dostępnych dla złośliwych użytkowników znacznie może im utrudnić ich działania, przez co nasza aplikacja staje się bezpieczniejsza ;-)
Ponieważ zmienne sesji również mogą zawierać istotne informacje, tutaj również należy zadbać o bezpieczeństwo. Użytkownik, który podsłucha ruch sieciowy może przechwycić identyfikator sesji i wykorzystać go w celu podania się za kogoś innego!
Uważasz, że artykuł był ciekawy i chcesz otrzymywać powiadomienia o moich kolejnych wpisach lub projektach?
Wpisz swoje imię oraz adres e-mail a następnie kliknij "ZAPISZ MNIE"
Podobne wpisy
By accepting you will be accessing a service provided by a third-party external to https://www.slawop.net/