A A A

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"

Twoje imię:


Adres email:


GSM - bezpieczeństwo rozmów
PHP - dyrektywa include

Podobne wpisy

 

Komentarze

Umieść swój komentarz jako pierwszy!
Gość
sobota, 25 maj 2019

Zdjęcie captcha

Najnowsze komentarze

Gość - Andy SSL i Joomla! w Smarthost
03 styczeń 2019
Dzięki, jak zwykle dobra robota! Warto dodać, że instalacja certyfikatu SSL nie zapewnia bezpieczeństwa transmisji danych. To jest możliwe po wdrożeniu polityki bezpieczeństwa w firmie. Co do SSL - to...
Gość - Henryk Jak utworzyć menu poziome w szablonie protostar?
02 styczeń 2019
Robię punkt po punkcie i nie wyświetla się poziome menu Nie wiem gdzie tkwi błąd i co robię źle?Jeśli to możliwe to proszę o pomocps. posiadam książkę "Joomla! 3x" i tu również niema pomocy Pozdrawiam...
Gość - Joanna Jak utworzyć własny szablon dla Joomla! nie dotykając kodu? EF4 cz.2
09 grudzień 2018
Czy jest jakaś możliwość, żeby zmienić układ top-bar i tej linii, w której jest logo? Tam niby są flexibloki ale nie można zmienić ich szerokości, a tego potrzebuję bardzo. Jak tego dokonać???
Gość - Informatyk Tworzenie bazy danych w CPanelu na Smarthost - instalacja Joomla!
19 listopad 2018
Dziękuje za ten wpis joomla zawsze była dla mnie problematyczna
Gość - Sławomir DJ Image Slider
04 listopad 2018
co robić? Zdjęcia wyświetlają się pionowo, jedno pod drugim. Żadna zmiana w opcjach, nic nie daje??? Pomożecie?