Bezpiecze�stwo

Bezpiecze�stwo

Bezpiecze�stwo jest powa�nym problemem dla aplikacji internetowych. Nawet du�e organizacje, takie jak Organizacja Narod�w Zjednoczonych, zosta�y zhakowane przy u�yciu bardzo prostych wad bezpiecze�stwa. Uwa�am, �e nie ma czego� takiego jak ca�kowicie bezpieczny system. Moim celem przy zabezpieczaniu aplikacji jest dwojaki. Po pierwsze, staram si�, aby atakuj�cy m�g� uzyska� dost�p tak d�ugo, jak to mo�liwe. Moim nast�pnym celem jest zminimalizowanie warto�ci wszelkich informacji, kt�re mog� odzyska�. Innymi s�owy, nigdy nie zak�adam, �e m�j system jest nieprzenikniony i zawsze u�ywam dog��bnej obrony. Zmniejsza to wykonalno�� w�amania si� do mojej aplikacji dla hakera - zajmie to du�o czasu, a kiedy to zrobi�, b�d� musieli po�wi�ci� znaczny wysi�ek, aby uzyska� wszelkie cenne informacje. Gdy �ciga ci� tygrys, nie musisz biec szybciej ni� tygrys. Musisz tylko biega� szybciej ni� facet obok ciebie.

Uwaga : Jedn� z g��wnych wad bezpiecze�stwa jest in�ynieria spo�eczna. Dyskusja na temat in�ynierii spo�ecznej nie wchodzi w zakres egzaminu Zend, ale zawsze musisz pami�ta�, �e nie tylko kod i serwery s� punktami wej�cia do twoich danych.

Konfiguracja

Najlepszym podej�ciem przy konfigurowaniu PHP jest upewnienie si�, �e jeste� na bie��co z wydaniami i korzystasz z wprowadzonych przez nich ulepsze�. Powiniene� mie� bardzo silny pow�d, je�li nie u�ywasz najnowszej stabilnej wersji PHP na rzecz starszej wersji. Upewnij si�, �e Tw�j system operacyjny jest za�atany. Regularnie stosuj aktualizacje zabezpiecze� i b�d� na bie��co z aktualno�ciami dotycz�cymi bezpiecze�stwa. Powiniene� zastosowa� inne aktualizacje pakietu tylko wtedy, gdy masz szans� upewni� si�, �e nie wp�yn� one negatywnie na tw�j stos lub �rodowiska testowe. Szanse s� takie, �e kuratorzy twojego repozytorium dystrybucyjnego zadbaj� o to, aby nie przerzuca� cz�sto u�ywanych stos�w, ale je�li u�ywasz niezwyk�ego stosu lub zainstalowa�e� oprogramowanie spoza repozytorium, zachowaj ostro�no�� podczas aktualizacji

B��dy i ostrze�enia

Powiniene� skonfigurowa� PHP do ukrywania ostrze�e� i b��d�w podczas produkcji. B��dy i ostrze�enia mog� da� osobie wskaz�wki na temat wewn�trznych dzia�a� twojego kodu, takich jak nazwy katalog�w i jakich bibliotek u�ywasz. Tego rodzaju informacje mog� pom�c im wykorzysta� luki w zabezpieczeniach. Mo�esz ustawi� raportowanie b��d�w w pliku php.ini lub w czasie wykonywania za pomoc� funkcji error_reporting(). Oba przyjmuj� argument liczbowy, zwykle w postaci wyra�enia zbudowanego ze wst�pnie zdefiniowanych sta�ych b��d�w. Oto zalecane ustawienia produkcji oraz domy�lne ustawienia produkcji PHP 7.1:

Ustawienie : Warto�ci

display_errors : Off
log_errors : On
error_reporting : E_ALL & ˜E_DEPRECATED & ˜E_STRICT

S� to r�wnie� ustawienia, kt�re mo�esz za�o�y� w swoim egzaminie Zend, chyba �e pytanie stanowi inaczej. W fazie projektowania ustawienie zg�aszania b��d�w powinno mie� warto�� E_ALL, a kod musi dzia�a� bez ostrze�e� - nie u�ywaj przestarza�ych funkcji.

Jak dzia�aj� flagi

By� mo�e zastanawiasz si�, jak ustawione s� flagi i dlaczego u�ywamy na nich operator�w bitowych. Spr�buj� wyja�ni�, aby u�atwi� zrozumienie ustawie� konfiguracji. Wyobra� liczb� w formacie binarnym jako ci�g 1 i 0. Ka�da pozycja w numerze binarnym jest flag� powi�zan� z opcj�. Je�li liczba w tej pozycji wynosi 1, oznacza to, �e flaga jest w��czona i opcja jest ustawiona. Teraz E_ALL to liczba wybierana tak, aby wszystkie flagi by�y powi�zane. Je�li wykonasz var_ dump (E_ALL), otrzymasz wynik int (32767), czyli 0b111111111111111. Ka�da z opcji jest liczb� wybran� do ustawienia jednego i tylko jednego bitu. Na przyk�ad E_NOTICE ma warto�� 8, kt�ra w systemie binarnym to 0b1000, a E_DEPRECATED to 8192, kt�ra w systemie binarnym to 0b10000000000000. Pami�taj, �e mo�esz wstawi� 8 po lewej z tyloma zerami, ile potrzebujesz, aby uzyska� t� sam� d�ugo��. Bitowy operator ~ odwraca bity w liczbie, wi�c ˜E_NOTICE to 0b0111. Bitowy operator i por�wnuje pozycje bit�w dw�ch liczb. Je�li obie liczby maj� troch� w ustawionej pozycji, wynik jest prawdziwy. Zatem E_ALL & ˜E_NOTICE ma ustawione wszystkie bity, z wyj�tkiem tego, kt�ry m�wi, �e E_NOTICE jest w��czony. W rezultacie ustawisz raportowanie b��d�w na liczb�, kt�ra ma ustawione bity dla opcji, kt�re chcesz w��czy�.

Wy��czanie funkcji i klas

Mo�esz u�y� dyrektyw disable_functions i disable_classes w pliku php.ini, aby zapobiec u�yciu funkcji i klas. Te ustawienia mo�na ustawi� tylko w pliku php.ini i nie mo�na ich zmieni� w �rodowisku uruchomieniowym ani w plikach ini katalogu. Do typowych funkcji wy��czania nale�� te, kt�re pozwalaj� PHP na wykonywanie polece� systemowych: exec, passthru, shell_exec i system. DirectoryIterator i klasy Directory s� r�wnie� cz�sto wy��czone, poniewa� mog� by� u�ywane przez atakuj�cego.

Wskaz�wka : Wy��czenie tych funkcji to podej�cie "czarnej listy". Pomys�owy przeciwnik postrzega to jako przeszkod�, ale nie przeszkod� nie do pokonania.

PHP jako modu� Apache

Je�li PHP dzia�a jako modu� Apache, zostanie uruchomiony przy u�yciu tego samego u�ytkownika co serwer Apache. Oznacza to, �e b�dzie mia� takie same uprawnienia i dost�p jak u�ytkownik Apache. Najlepsz� praktyk� jest konfigurowanie u�ytkownika dla Apache zamiast uruchamiania go jako "nikt". U�ytkownik Apache powinien mie� ograniczony dost�p do systemu plik�w i nie powinien znajdowa� si� na li�cie sudoers. Powiniene� u�y� ustawienia PHP open_basedir, aby ograniczy� dost�p do katalog�w, do kt�rych PHP ma dost�p. Mo�esz to por�wna� z ustawieniem doc_root, kt�re wp�ywa na to, z kt�rych katalog�w PHP b�dzie obs�ugiwa� pliki.

Uwaga : Tryb awaryjny nie ma wp�ywu na ustawienie parametru open_basedir, ale doc_root. Je�li przechowujesz katalog, w kt�rym przechowujesz pliki przes�ane przez u�ytkownik�w spoza tego katalogu, mo�esz znacznie utrudni� atakuj�cemu przes�anie i wykonanie pliku.

PHP jako plik binarny CGI

Nie wiem, czy kto� nadal obs�uguje PHP jako plik binarny CGI, ale temat jest nadal w sylabusie Zend. Pr�bowa�em zrozumie�, dlaczego Zend uwa�a�, �e wa�ne jest, aby je zrozumie�. My�l�, �e warto�� zrozumienia tych problem�w w starszej konfiguracji polega na tym, �e we wsp�czesnych konfiguracjach istniej� analogi. Na przyk�ad usterka konfiguracji "Przekazywanie niekontrolowanych ��da� do PHP" wydaje si� bardzo podobna do omijania sprawdzania uprawnie� w CGI (kr�tko opisane). PHP-FPM dzia�a przy u�yciu protoko�u FastCGI, co stanowi ulepszenie CGI. Ta sekcja nie dotyczy PHP-FPM, poniewa� ��dania s� przekazywane do niej przez gniazdo i nie mo�e mie� na ni� wp�ywu adres URL. Do cel�w egzaminacyjnych musisz zna� trzy parametry konfiguracyjne i ich dzia�anie w kontek�cie atak�w CGI. Wymieniam je tutaj, a nast�pnie wyja�niam bardziej szczeg�owo.

Ustawienie : Funkcja

cgi.force_redirect : Zapobiega uruchamianiu PHP, chyba �e serwer WWW go wywo�a. Je�li jest w��czony, PHP nie b�dzie odpowiada� na takie ��dania jak http: //yoursite.com/cgi-bin/php / …
doc_root : Ustawia katalog g��wny dokumentu. Je�li masz w��czony tryb bezpieczny, to PHP nie b�dzie obs�ugiwa� plik�w spoza tego katalogu.
user_dir : Ustawia katalog domowy u�ytkownika sieci

Ustawienia doc_root i user_dir nie s� zwi�zane wy��cznie z bezpiecze�stwem CGI i powinny by� ustawione jako cz�� og�lnych ustawie� bezpiecze�stwa

Z�o�liwe parametry CGI

Zwykle informacje o zapytaniu w adresie URL po przekazaniu znaku zapytania jako argumentu wiersza polecenia do interpretera przez interfejs CGI. Dotyczy to ka�dego pliku binarnego u�ywanego przez serwer WWW jako CGI. Z powodu konwencji adres URL http://my.host/cgi-bin/php?/etc/passwd b�dzie pr�bowa� przekaza� plik / etc / passwd do pliku binarnego PHP. Zwykle interpretery CGI otwieraj� i wykonuj� plik okre�lony jako pierwszy argument w wierszu polece�. Jednak PHP odmawia interpretacji argument�w wiersza polece�, gdy jest wywo�ywany jako plik binarny CGI. Dzi�ki temu jest odporny na ataki polegaj�ce na mo�liwo�ci przekazania parametru do pliku binarnego.

Sprawdzanie uprawnie� do obej�cia

Powszechnie stosuje si� "przyjazne" adresy URL, kt�re wysy�aj� przyjazny dla wyszukiwarki adres URL do skryptu. Na przyk�ad adres URL https://yourhost.com/user/nico.php mo�e odwzorowa� rzeczywiste ��danie na https://yourhost.com/cgi-bin/php/user/belieber.php. Zwykle serwer internetowy sprawdza uprawnienia i sprawdza, czy u�ytkownik musi zrobi� dost�p do katalogu / user /. Je�li go�� jest dozwolony, utworzy przekierowane ��danie. Je�li odwiedzaj�cy uzyska dost�p do celu przekierowania, czyli pe�nego adresu URL, w tym cgi-bin, serwer internetowy sprawdza uprawnienia, kt�re musi uzyska� dost�p do katalogu / cgi-bin /, a nie rzeczywisty katalog, kt�ry b�dzie obs�ugiwany. Oznacza to, �e odwiedzaj�cy mo�e omin�� kontrol� uprawnie�, kt�ra chroni katalog u�ytkownika, po prostu ��daj�c pliku z PHP w cgi-bin. Z�o�liwy go�� mo�e uzyska� dost�p do dowolnego pliku na serwerze internetowym, kt�ry PHP mo�e odczyta�. Dyrektywy cgi.force_redirect, doc_root i user_dir s�u�� do zapobiegania dost�powi do prywatnych dokument�w przez PHP. Ustawienie cgi.force_redirect blokuje mo�liwo�� wywo�ywania PHP bezpo�rednio z adresu URL - zadzia�a tylko wtedy, gdy zostanie wywo�ane na przekierowaniu z serwera WWW, takiego jak Apache. Pracuj�c z PHP jako plikiem binarnym CGI, powiniene� rozwa�y� przeniesienie pliku binarnego PHP poza drzewo dokument�w i oddzielenie wykonywalnych skrypt�w PHP od skrypt�w statycznych.

Uruchamianie PHP-FPM

PHP-FPM pozwala �atwo skonfigurowa� wiele pul, z kt�rych ka�da mo�e by� uruchomiona przez innego u�ytkownika. Je�li hostujesz wielu klient�w, upewnij si�, �e witryna ka�dego klienta dzia�a jako w�asny u�ytkownik. U�ytkownicy klienta nie powinni mie� dost�pu do plik�w poza swoim katalogiem domowym. Oto kilka przyk�adowych ustawie� z pliku puli:

[pool1]
user = site1
group = site1
listen = /var/run/php5-fpm-site1.sock
listen.owner = www-data
listen.group = www-data

Konfigurujemy pul� o nazwie pula1, aby dzia�a�a jako witryna u�ytkownika 1 w witrynie grupy. Ustawiamy w�a�ciciela i grup� nas�uchuj�c� na u�ytkownika serwera WWW, aby Nginx / Apache m�g� czyta� i zapisywa� w gnie�dzie. Po ustawieniu u�ytkownika, kt�ry uruchamia pul�, skonfigurujemy uprawnienia do plik�w, aby ograniczy� dost�p tylko do katalogu, w kt�rym znajduje si� strona internetowa. Uniemo�liwi to klientom korzystanie z funkcji odczytu plik�w do odczytywania zawarto�ci innego klienta informator.

Wskaz�wka : niekt�re pliki, takie jak wp-config.php w witrynie WordPress, maj� przewidywalne nazwy i bardzo wa�ne jest, aby chroni� katalogi u�ytkownik�w przed innymi u�ytkownikami.

Konfigurujemy Nginx, aby przekazywa� takie ��dania PHP:

location ˜\.php$ {
try_files $uri = 404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SERVER_NAME $host;
fastcgi_pass unix:/var/run/php5-fpm-pool1.sock;
}

Ka�da witryna przekazuje ��dania do gniazda powi�zanego z w�asn� pul�. Skrypt PHP dzia�a jako u�ytkownik okre�lony w puli i jest zablokowany w ustawionych dla nich uprawnieniach do plik�w. Uwaga : W naszej konfiguracji Nginx uwzgl�dniamy try_files $ uri = 404; aby zapobiec atakom wymienionym w Podr�czniku Nginx.

Dodatkow� warstw� bezpiecze�stwa mo�na uzyska�, zamykaj�c ka�d� pul� we w�asnym wi�zieniu chroot. Pami�taj, �e musisz upewni� si�, �e pliki, do kt�rych PHP musi uzyska� dost�p (takie jak katalogi dziennika lub pliki binarne, takie jak ImageMagick) s� dost�pne w wi�zieniu.

Bezpiecze�stwo sesji

Dwa obszary, na kt�re nale�y zwr�ci� uwag�, to "przejmowanie sesji" i "utrwalanie sesji". Opr�cz tej cz�ci powiniene� przestudiowa� stron� podr�cznika PHP dotycz�c� bezpiecze�stwa sesji.

Porwanie sesji

HTTP jest protoko�em bezstanowym i mo�na oczekiwa�, �e serwer sieciowy b�dzie obs�ugiwa� wielu r�nych u�ytkownik�w jednocze�nie. Serwer musi by� w stanie odr�ni� klient�w od siebie i robi to poprzez przypisanie ka�demu klientowi identyfikatora sesji. Identyfikator sesji mo�na pobra�, wywo�uj�c session_id(). Jest tworzony po wywo�aniu funkcji session_start (). Gdy klient wysy�a kolejne ��dania do serwera, podaje identyfikator sesji, kt�ry pozwala serwerowi powi�za� ��danie z sesj�. Klienci mog� udost�pni� sesji pliki cookie lub parametr adresu URL. Pliki cookie s� preferowane, ale nie zawsze s� dost�pne. Je�li PHP nie mo�e u�y� pliku cookie, automatycznie i transparentnie u�yje adresu URL, chyba �e ustawisz ustawienie session.use_only_cookies w pliku php.ini. Powinno by� oczywiste, �e je�li jeste� w stanie zaprezentowa� komu� identyfikator sesji na serwerze, mo�esz maskowa� si� jako ten u�ytkownik. Uzyskanie identyfikatora sesji innego u�ytkownika mo�na wykona� na kilka sposob�w.

• Je�li identyfikator sesji jest zgodny z przewidywalnym wzorcem, osoba atakuj�ca mo�e spr�bowa� okre�li�, co b�dzie dla u�ytkownika. PHP u�ywa bardzo losowego sposobu generowania identyfikator�w sesji, wi�c nie musisz si� tym martwi�.
• Sprawdzaj�c ruch sieciowy mi�dzy klientem a serwerem, osoba atakuj�ca mo�e odczyta� identyfikator sesji. Mo�esz ustawi� session.cookie_secure = On, aby sesyjne pliki cookie by�y dost�pne tylko przez HTTPS, aby to z�agodzi�. HTTPS b�dzie r�wnie� szyfrowa� ��dany adres URL, wi�c je�li identyfikator sesji zostanie przekazany jako parametr w ��daniu, zostanie zaszyfrowany.
• Ataki na klienta, takie jak atak XSS lub trojan uruchomiony na ich komputerze, mog� r�wnie� ujawni� identyfikator sesji. Mo�na to cz�ciowo z�agodzi�, ustawiaj�c sesj�. cookie_httponly dyrektywa w sprawie.
Zmuszenie PHP do u�ywania tylko plik�w cookie nie ograniczy wykorzystania tego ataku. Przeciwnik mo�e �atwo ustawi� warto�� cookie.

Utrwalanie sesji

Naprawa sesji wykorzystuje s�abo�� aplikacji internetowej. Niekt�re aplikacje nie generuj� nowego identyfikatora sesji dla u�ytkownika podczas ich uwierzytelniania. Zamiast tego pozwalaj� na u�ycie istniej�cego identyfikatora sesji. Atak ma miejsce, gdy przeciwnik tworzy sesj� na serwerze sieciowym. Znaj� identyfikator sesji dla tej sesji. Nast�pnie nak�aniaj� u�ytkownika do korzystania z tej sesji i uwierzytelniania si�. Osoba atakuj�ca mo�e w�wczas u�y� znanego identyfikatora sesji i ma uprawnienia uwierzytelnionego u�ytkownika. Istnieje kilka sposob�w ustawienia identyfikatora sesji, a faktyczna zastosowana metoda b�dzie zale�e� od tego, jak aplikacja zaakceptuje identyfikator. Najprostszym sposobem jest przekazanie identyfikatora sesji w adresie URL, w ten spos�b

http://example.org/index.php?PHPSESSID=1234.

Najlepszym sposobem na ograniczenie ryzyka utrwalenia sesji jest wywo�anie funkcji session_regenerate_id() za ka�dym razem, gdy zmienia si� poziom uprawnie�, na przyk�ad po zalogowaniu. Mo�esz ustawi� session.use_strict_mode = On w pliku konfiguracyjnym. To ustawienie zmusi PHP do u�ywania tylko identyfikator�w sesji, kt�re sam tworzy. Odrzuci dostarczony przez u�ytkownika identyfikator sesji. To ograniczy pr�by manipulowania plikiem cookie. Ustawienia session.use_cookies = On i session.use_only_cookies = On zapobiegn� zaakceptowaniu przez PHP identyfikatora sesji z adresu URL.

Poprawa bezpiecze�stwa sesji

Nie polegaj na jednej strategii �agodzenia atak�w, a raczej u�ywaj kilku warstw zabezpiecze�. Opr�cz strategii �agodzenia, o kt�rych ju� wspomnia�em, powiniene� r�wnie� wykona� nast�puj�ce czynno�ci:

• Sprawd�, czy adres IP pozostaje taki sam mi�dzy po��czeniami. Nie zawsze jest to mo�liwe w przypadku telefon�w kom�rkowych, kt�re przemieszczaj� si� mi�dzy wie�ami, a wi�c zmieniaj� po��czenia, dlatego zanim to zrobisz, sprawd� przypadki u�ycia.
• U�yj warto�ci limitu czasu kr�tkiej sesji, aby zmniejszy� okno do naprawy.
• Zapewnij u�ytkownikom mo�liwo�� wylogowania si� z wywo�ania session_destroy().

�adne z nich nie jest szczeg�lnie skuteczne samo w sobie, ale ka�de z nich mo�e przyczyni� si� do poprawy og�lnego bezpiecze�stwa.

Cross-Site Scripting

Ataki typu cross-site scripting (XSS) to ataki, w kt�rych szkodliwy kod jest wstrzykiwany na inn�, niegro�n� witryn�. Zwykle z�o�liwy kod przegl�darki, taki jak JavaScript, jest umieszczany na stronie internetowej w celu pobrania i uruchomienia przez klient�w. Atak jest skuteczny, poniewa� klient uwa�a, �e kod pochodzi z zaufanej witryny internetowej. Kod mo�e uzyska� dost�p do identyfikator�w sesji, plik�w cookie, danych do przechowywania HTML i innych informacji zwi�zanych z witryn�. Istnieje kilka szerokich rodzaj�w atak�w XSS: przechowywanych, odbijanych i DOM. W przechowywanym ataku XSS przeciwnik mo�e umie�ci� dane wej�ciowe w zapisanej lokalizacji na serwerze. Przyk�adami mog� by� komentarze u�ytkownik�w wy�wietlane na stronie i przechowywane w bazie danych. Gdy witryna wy�le list� komentarzy u�ytkownika do innego u�ytkownika, otrzyma z�o�liwy kod. W odbijanym ataku XSS przeciwnik mo�e zmusi� stron� internetow� do wys�ania czego� bezpo�rednio. Najcz�stsz� form� tego ataku jest b��d wype�niania formularza, kt�ry wype�nia pola wej�ciowe poprzednio przes�anymi polami lub wy�wietla b��dn� warto�� pola. Wysy�aj�c go�cia pod spreparowany adres URL, kt�ry zawiera z�o�liwy kod jako komunikat b��du (na przyk�ad), osoba atakuj�ca mo�e oszuka� klienta w celu wykonania go w kontek�cie zaufanej strony. Atak DOM to taki, kt�ry spoczywa ca�kowicie na stronie. Szkodliwy kod jest odczytywany z elementu na stronie, a wywo�anie kodu jest wykonywane na samej stronie. Ponadto ataki XSS mo�na zaklasyfikowa� jako ataki po stronie serwera lub po stronie klienta. Atak po stronie serwera to taki, w kt�rym serwer dostarcza z�o�liwy kod. Klient XSS wyst�puje, gdy niezaufane dane dostarczone przez u�ytkownika s� u�ywane do aktualizacji DOM za pomoc� niebezpiecznego wywo�ania JavaScript.

�agodzenie atak�w XSS

Najwa�niejsz� zasad�, kt�rej nale�y przestrzega�, jest to, �e nigdy nie zezwala si� na wysy�anie nieskalowanych danych do klienta. Zawsze filtruj dane i usuwaj szkodliwe tagi przed umo�liwieniem ich wys�ania do klienta.

Wskaz�wka : Zapami�taj t� mantr� "Filtruj wej�cie, uciekaj z wyj�ciem".

Trzy przydatne do tego funkcje to htmlspecialchars(), htmlentities() i trip_tags().

Wskaz�wka : Najbezpieczniejszym sposobem na wyj�cie z wyj�cia przed jego wy�wietleniem jest u�ycie filter_var ($ string, FILTER_SANITIZE_STRING).

Ze wzgl�du na du�� r�norodno�� format�w, kt�re mo�na stosowa� w adresach URL i HTML do generowania danych, kody na czarnej li�cie nie s� bezpieczne. Powiniene� raczej doda� do bia�ej listy okre�lone tagi, na kt�re chcesz zezwoli�. Sp�jrz na �ci�g� na temat unikania filtr�w OWASP, aby zobaczy�, ile sposob�w mo�na unikn�� czarnej listy. Musisz tak�e ograniczy� XSS w swoim JavaScript na swojej stronie HTML, ale to nie wchodzi w zakres tego podr�cznika.

Fa�szerstwa ��da� w r�nych witrynach

Ataki CSRF wykorzystuj� zaufanie, jakie strona internetowa ma do klienta. W tych atakach przeciwnik nak�ania klienta do wykonania polecenia na stronie internetowej, kt�ra ufa temu klientowi. Najcz�stsz� form� by�oby wys�anie ��dania POST do formularza wej�ciowego. Wyobra� sobie, �e Alice jest zalogowana na swojej stronie internetowej banku, kt�ra ma formularz, kt�ry pozwala jej przela� pieni�dze na inne konto. Chuck zna punkt ko�cowy tego formularza i jakie ma pola wej�ciowe. Jakim� sposobem uda�o mu si� oszuka� przegl�dark� internetow� Alicji, aby wys�a�a do tego formularza ��danie POST z instrukcjami banku, aby przela� pieni�dze na jego konto. Bank ufa przegl�darce internetowej Alicji, poniewa� ma prawid�ow� sesj� i wykonuje ��danie. Jest wiele sposob�w, w jakie Chuck mo�e oszuka� przegl�dark� internetow� Alice, w tym u�ycie ramek iframe i JavaScript. Aby z�agodzi� te ��dania, nale�y wygenerowa� unikalny i bardzo losowy token przechowywany w sesji Alice. Kiedy wysy�asz formularz, do��czasz ten token, aby Alice przes�a�a formularz, a ona r�wnie� wysy�a token. Przed przetworzeniem formularza sprawdzasz, czy przes�any token jest zgodny z tokenem przechowywanym w jej sesji. Chuck nie ma mo�liwo�ci dowiedzenia si�, jaki token znajduje si� w sesji Alice, wi�c nie b�dzie m�g� go uwzgl�dni� w swoim POST. Tw�j kod odrzuci pro�b�, kt�r� oszuka� Alice poniewa� nie ma prawid�owego tokena. Rzeczywiste banki cz�sto wymagaj� ponownej uwierzytelnienia podczas wykonywania wra�liwej operacji i cz�sto wymagaj� uwierzytelnienia dwusk�adnikowego w ramach tego procesu.

SQL Injection

Wstrzykni�cie SQL jest najcz�stsz� form� ataku w Internecie i jedn� z naj�atwiejszych do obrony. Wstrzykiwanie SQL ma miejsce, gdy osoba atakuj�ca mo�e wstawi� z�o�liwe polecenia do instrukcji SQL w celu wykonania przez baz� danych. Wiele ustawie� bazy danych pozwala na zapisywanie plik�w na dysku. Ta funkcja umo�liwia hakerom utworzenie backdoora przy u�yciu bazy danych do pisania skrypt�w PHP w katalogu, w kt�rym serwer internetowy b�dzie go obs�ugiwa�. Oznacza to, �e efekt wstrzykni�cia SQL nie ogranicza si� do naruszenia bazy danych, ale mo�e spowodowa�, �e osoba atakuj�ca b�dzie mog�a wykona� dowolny kod w bazie danych. U podstaw problemu z iniekcj� SQL jest fakt, �e instrukcja SQL ma mieszank� danych i sk�adni. Umo�liwiaj�c w��czenie danych dostarczonych przez u�ytkownika do sk�adni funkcji, stwarzamy mo�liwo��, �e z�o�liwe dane mog� zak��ca� sk�adni�.

Przygotowane instrukcji

Najbardziej skutecznym sposobem na rozpocz�cie ograniczania wstrzykiwania SQL w j�zyku PHP jest u�ywanie wy��cznie przygotowanych instrukcji do interakcji z baz� danych. Pomo�e to wykluczy� wi�kszo�� atak�w z iniekcj� SQL, ale samo w sobie nie wystarczy, aby by� niezawodnym. Przygotowane instrukcje s� tak wa�ne, �e sterownik PDO b�dzie je emulowa�, je�li podstawowy sterownik ich nie obs�uguje. Przygotowane wyci�gi dzia�aj� w trzech krokach:

1. Skonfiguruj zestawienie z symbolami zast�pczymi danych.
2. Powi�� rzeczywiste dane z wyci�giem.
3. Wykonaj przygotowane polecenie.

Mo�liwe jest powi�zanie nowych danych z instrukcj�, kt�r� ju� wykona�e�, a nast�pnie ponowne uruchomienie z now� instrukcj�. Aparat bazy danych nie musi ponownie analizowa� kodu SQL, co zapewnia popraw� wydajno�ci opr�cz korzy�ci bezpiecze�stwa. Ten kod podaje przyk�ad przygotowania, powi�zania i wykonania instrukcji:

< ?php
$stmt = $dbh->prepare("SELECT * FROM REGISTRY where name = ?");
$stmt->bindParam(':name', $_GET['name'], PDO::PARAM_STR, 12);
$stmt->execute();

Uwaga : Funkcja PDO :: prepar () zwraca obiekt typu PDOStatement.

U�ywamy bezpo�rednio zmiennej GET, wi�c nie musimy jej ucieka�, poniewa� jest ona powi�zana jako zmienna za pomoc� PDOStatement :: bindParam () i nie mo�e zmieni� sk�adni SQL, kt�ry ma zosta� uruchomiony. Inne sterowniki baz danych w PHP r�wnie� obs�uguj� przygotowane instrukcje. Oto przyk�ad z podr�cznika dla MySQL5:

/* Prepared statement, stage 1: prepare */
if (!($stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)"))) {
echo "Prepare failed: (" . $mysqli->errno . ") " . $mysqli->error;
}
/* Prepared statement, stage 2: bind and execute */
$id = 1;
if (!$stmt->bind_param("i", $id)) {
echo "Binding parameters failed: (" . $stmt->errno . ") " . $stmt->error;
}
if (!$stmt->execute()) {
echo "Execute failed: (" . $stmt->errno . ") " . $stmt->error;
}

Ucieczka

Mniej skutecznym sposobem ograniczenia zastrzyku SQL jest ucieczka ze znak�w specjalnych przed wys�aniem ich do bazy danych. Jest to bardziej podatne na b��dy ni� u�ywanie przygotowanych instrukcji. Je�li zamierzasz uciec od znak�w specjalnych, musisz u�y� funkcji specyficznej dla bazy danych (np. Mysqli_real_escape_string ()) lub PDO :: quote (), a nie funkcji og�lnej, takiej jak sumy dodatkowe ().

Og�lne zasady

Nale�y r�wnie� zawsze ��czy� si� z baz� danych z u�ytkownikiem, kt�ry ma najmniejsz� liczb� uprawnie� wymaganych do dzia�ania aplikacji. Nigdy nie zezwalaj aplikacji internetowej na ��czenie si� z baz� danych jako u�ytkownik root. Je�li hostujesz wiele baz danych na serwerze, u�yj innego u�ytkownika dla ka�dej bazy danych na serwerze i upewnij si�, �e ich has�a s� unikalne. Pomo�e to zapobiec atakowi iniekcji SQL na jedn� witryn�, kt�ra wp�ynie na bazy danych innych witryn. Upewnij si�, �e korzystasz z aktualnej wersji MySQL i wymuszaj u�ycie zestawu znak�w w DSN klienta. Istnieje bardzo subtelny spos�b u�ycia niedopasowanych zestaw�w znak�w w niekt�rych wra�liwych schematach kodowania w celu wdro�enia wstrzykni�cia SQL; zobacz drug� odpowied� (nie zaakceptowan�) w tym artykule StackOverflow, aby uzyska� ekspozycj�.

Zdalne wstrzykiwanie kodu

Zdalne wstrzykiwanie kodu to atak, w kt�rym przeciwnik mo�e zmusi� serwer do w��czenia i wykonania swojego kodu.

Funkcje, kt�re oceniaj� ci�gi jako kod

Niekt�re funkcje, takie jak eval(), exec() i system() s� podatne na exploity zdalnego wstrzykiwania kodu. Je�li wykonujesz zmienn� zawieraj�c� dane wprowadzone przez u�ytkownika, b�d� oni mogli wstrzykiwa� polecenia za pomoc� znak�w zmiany znaczenia. Mo�esz temu zaradzi�, u�ywaj�c escapeshellargs(), aby unikn�� argument�w przekazywanych do polecenia pow�oki. Funkcja escapeshellcmd() spowoduje unikni�cie samego polecenia pow�oki.

Wskaz�wka : Je�li nie u�ywasz wyra�nie tych funkcji, powiniene� je wy��czy� w swoim php. ini. Nie jest niezawodny, ale mo�e pom�c.

Funkcja assert() s�u�y do upewnienia si�, �e okre�lony warunek jest spe�niony i podj�cia pewnych dzia�a�, je�li tak nie jest. Jest przydatny do debugowania, ale nale�y go wy��czy� na czas produkcji. Mo�esz u�y� funkcji assert_options(), aby skonfigurowa� zachowanie asert i j� wy��czy�. Je�li przeka�esz warto�� ci�gu do assert(), PHP oceni �a�cuch tak, jakby to by� kod PHP. Pozwoli�oby to atakuj�cemu wykona� kod na twoim serwerze, gdyby m�g� kontrolowa�, jaki argument przekazujesz do assert().

< ?php
function rce(string $a) {
assert($a);
}
rce('print("hello")'); // hello
W PHP 7.2 przekazywanie ci�gu do potwierdzenia jest przestarza�e, a ten kod generuje ostrze�enie, ale nadal analizuje parametr

Zar�wno inlude() i require() pozwalaj� na do��czanie plik�w okre�lonych przez URL, je�li w��czone jest ustawienie konfiguracyjne PHP enable_url_include. Najcz�ciej wyst�puje to, gdy ludzie u�ywaj� zmiennej GET w adresie URL, aby okre�li� zawarto�� dynamiczn�, kt�r� nale�y uwzgl�dni�. To bardzo amatorski b��d. Na przyk�ad witryna mo�e mie� adres URL taki jak http://example.com/index.php? sidebar = welcome, a nast�pnie dynamicznie do��cz plik welcome.php do paska bocznego. Przeciwnik mo�e poda� adres URL zamiast ci�gu "welcome" i wykona� sw�j kod na serwerze z takim samym poziomem uprawnie�, jak u�ytkownik serwera WWW. Aby przeciwdzia�a� tego rodzaju problemowi, mo�esz ustawi� parametr allow_url_fopen na WY�., U�yj funkcji basename () w stosunku do zmiennej, kt�r� do��czasz, aby usun�� cie�ki, i uwzgl�dniaj tylko w przypadku bia�ej listy.

< ?php
$page = $_GET['page'];
$allowedPages = array('adverts','contacts','information');
if ( in_array($page, $allowedPages) ) {
include basename($page . '.html');
}

Zastrzyk e-mailem

U�ytkownicy mog� podawa� szesnastkowe znaki steruj�ce, kt�re pozwalaj� im zmienia� tre�� wiadomo�ci lub list� adresat�w. Na przyk�ad je�li formularz umo�liwia osobie wpisanie adresu e-mail jako pola "od" wiadomo�ci e-mail, nast�puj�cy ci�g spowoduje, �e dodatkowi odbiorcy zostan� uwzgl�dnieni jako odbiorcy DW i ukrytej kopii wiadomo�ci: nadawca @ example.com% 0ACc: target@email.com%0ABcc: anotherperson @ emailexample. com, stranger @ shouldhavefiltered.com Atakuj�cy mo�e r�wnie� poda� w�asne cia�o, a nawet zmieni� typ MIME wysy�anej wiadomo�ci. Oznacza to, �e Tw�j formularz mo�e by� wykorzystywany przez spamer�w do wysy�ania poczty. Mo�esz si� przed tym zabezpieczy� na kilka sposob�w. Upewnij si�, �e odpowiednio filtrujesz dane wej�ciowe u�ywane podczas wysy�ania wiadomo�ci e-mail. Funkcja filter_var () zapewnia szereg flag, kt�rych mo�esz u�y�, aby upewni� si�, �e Twoje dane wej�ciowe s� zgodne z po��danym wzorcem.

< ?php
$from = $_POST["sender"];
$from = filter_var($from, FILTER_SANITIZE_EMAIL);
// wy�lij wiadomo�� e-mail

Mo�esz tak�e zainstalowa� rozszerzenie Suhosin PHP i korzysta� z niego. Zapewnia dyrektyw� suhosin. mail.protect, kt�ra b�dzie temu zapobiega�. Mo�esz wdro�y� tarpit, aby spowolni� boty lub uwi�zi� je w niesko�czono��. Sp�jrz na msigley / PHP-HTTP-Tarpit na GitHub8 jako przyk�ad tarpit. Podczas konfigurowania serwera pocztowego nale�y upewni� si�, �e nie jest skonfigurowany jako otwarty przeka�nik, kt�ry pozwala ka�demu w Internecie u�ywa� go do wysy�ania poczty. Nale�y r�wnie� rozwa�y� zamkni�cie portu 25 (SMTP) w zaporze, aby hosty zewn�trzne nie mog�y uzyska� dost�pu do serwera.

Filtrowanie wej�cia

Zbli�aj�c si� do bezpiecze�stwa, najlepiej zaplanowa� najgorszy scenariusz i za�o�y�, �e wszystkie dane wej�ciowe s� ska�one, a wszystkie zachowania u�ytkownik�w s� z�o�liwe. Nale�y u�ywa� wy��cznie danych wej�ciowych, kt�re zosta�y r�cznie potwierdzone jako bezpieczne. Dane wej�ciowe mog� mie� format, kt�ry zostanie zignorowany przez filtr, a nast�pnie przeanalizowany przez przegl�dark�. Arkusz �ci�gaj�cy unikanie XSS, o kt�rym wspomnia�em wcze�niej, zawiera wiele przyk�ad�w u�ycia znak�w specjalnych do unikania wykrywania. Istnieje mo�liwo�� wprowadzenia niestandardowego zestawu znak�w, kt�ry mo�e nie by� poprawnie zrozumiany przez funkcje filtrowania. Podczas pracy z filtrowaniem SQL nale�y u�ywa� rodzimych funkcji filtrowania bazy danych. PHP ma bardzo solidn� funkcj� filtrowania, filter_var(), kt�rej mo�na u�ywa� do wykonywania wielu r�nych operacji filtrowania i odka�ania. Mo�esz znale�� list� filtr�w w Podr�czniku PHP. Istnieje r�wnie� kilka funkcji, za pomoc� kt�rych mo�na sprawdzi� poszczeg�lne typy ci�g�w. S� �wiadomi ustawie� regionalnych, dlatego uwzgl�dniaj� znaki j�zykowe. Funkcje zwr�c� warto�� true, je�li ci�g zawiera tylko znaki w filtrze, w przeciwnym razie warto�� false.

Funkcyja : Filtry

ctype_alnum() : Tylko znaki alfanumeryczne
ctype_alpha() : Tylko znaki alfabetyczne
ctype_cntrl() : String to tylko znaki kontrolne
ctype_digit() : Ci�g jest tylko cyframi
ctype_graph() : Tylko znaki i spacja do wydruku
ctype_lower() : Tylko ma�e litery
ctype_print() : Znaki do wydruku
ctype_punct() : Dowolne do wydruku, kt�re nie jest spacj� ani alfanumerycznie
ctype_space() : Sprawd�, czy wyst�puj� spacje
ctype_upper() : Tylko wielkie litery
ctype_xdigit() : Cyfry szesnastkowe

Filtrowanie po stronie klienta jest typowe, na przyk�ad przy u�yciu JavaScript w przegl�darce. Nie jest to wystarczaj�ce i nale�y r�wnie� filtrowa� i sprawdza� poprawno�� po stronie serwera.

Unikanie wyj�cia

Jedn� z g��wnych zasad pisania bezpiecznego kodu PHP jest filtrowanie danych wej�ciowych i unikanie danych wyj�ciowych. Zanim wy�lesz dane, musisz upewni� si�, �e s� one bezpieczne dla klienta. Przypomnij sobie, jak dzia�aj� ataki XSS, jako przyk�ad, dlaczego musisz upewni� si�, �e to, co wysy�asz do klienta, jest odpowiednio odka�one. Je�li dane, kt�re wysy�asz do klienta, zawieraj� instrukcje wykonania kodu, zrobi to na �lepo. Musisz upewni� si�, �e wysy�asz tylko kod, kt�ry ma zosta� wykonany przez klienta, a nie kod wprowadzony przez atakuj�cego. Podobnie jak w przypadku filtrowania danych wej�ciowych, nie mo�na polega� na kliencie, kt�ry filtruje wysy�ane do niego dane wyj�ciowe. Nie wszyscy klienci maj� w��czon� obs�ug� JavaScript i haker mo�e omin�� filtrowanie klient�w. Najbezpieczniejszym sposobem filtrowania danych wyj�ciowych jest u�ycie filter_var() z flag� FILTER_SANITIZE_STRING. Mog� wyst�pi� przypadki u�ycia, w kt�rych jest to dla ciebie zbyt restrykcyjne, w kt�rym to przypadku b�dziesz musia� spojrze� na funkcje takie jak htmlspecialchars(), strip_tags() i htmlentities().Funkcje htmlspecialchars() i htmlentities() maj� podobne efekty i upewnij si�, �e rozumiesz r�nic�. R�nica polega na tym, �e htmlentities() koduje wszystko, co ma reprezentacj� encji HTML, natomiast htmlspecialchars() koduje tylko znaki, kt�re maj� specjalne znaczenie w HTML . Ta tabela pokazuje znaki, kt�re zostan� przekonwertowane przez htmlspecialchars ()

& (Ampersand) : &
" (Podw�jny cudzys��w) : "
' (Pojedynczy cudys��w) : '
< (Mniejsze ni�) : <
> (Wi�ksze ni�) : >

Obie funkcje przyjmuj� flag� jako drugi parametr. Powiniene� upewni� si�, �e znasz przynajmniej te trzy flagi, poniewa� s� one wa�ne dla unikni�cia kodu JavaScript, kt�ry wysy�asz:

Flaga : Opis

ENT_COMPAT : Konwertuje podw�jne cudzys�owy, a nie pojedyncze cudzys�owy
ENT_QUOTES : Konwertuje podw�jne cudzys�owy i pojedyncze cudzys�owy
ENT_NOQUOTES : Nie konwertuje �adnych cytat�w
Podczas ucieczki ci�gu JavaScript nale�y u�y� flagi ENT_QUOTES. Kodowanie ci�gu mo�na okre�li� w trzecim parametrze. W PHP 7.1 domy�lnym kodowaniem obu funkcji jest UTF-8.

Unikaj zatrucia dziennik�w

Je�li rejestrujesz komunikaty o b��dach, komunikaty informacyjne itp., Musisz zachowa� ostro�no�� przy logowaniu. Oczywi�cie nie wolno rejestrowa� poufnych informacji, takich jak has�a u�ytkownika lub karty kredytowe. Je�li przekazujesz to do funkcji logowania, upewnij si�, �e j� zaciemni�e�. Tak wi�c numer karty kredytowej by�by sekwencj� gwiazdek w pliku dziennika, a nie rzeczywist� liczb�. Upewnij si�, �e odfiltrowa�e� kod wykonywalny i dane osobowe przed zalogowaniem. Powiniene� tak�e wiedzie�, jak dzia�a atak zatrucia log�w. Luka polega na niew�a�ciwym kodzie, w tym na plikach lokalnych. Je�li pozwolisz, aby dane wej�ciowe u�ytkownika okre�li�y, kt�ry plik jest do��czony, osoba atakuj�ca mo�e manipulowa� tym plikiem wej�ciowym, aby do��czy� plik dziennika. Je�li plik dziennika zawiera z�o�liwy kod, zostanie zinterpretowany i uruchomiony. Atakuj�cy musi jedynie pobra� sw�j kod do pliku dziennika, co mo�e by� bardzo �atwe. Na przyk�ad mog� zatru� dziennik serwera WWW, tworz�c zapytanie, kt�re wstrzykuje ci�g zawieraj�cy polecenia, kt�re chc� uruchomi� w dzienniku. Innym przyk�adem atakuj�cego mo�e by� SSH na serwerze i u�ycie z�o�liwego kodu jako nazwy u�ytkownika, aby zatru� plik dziennika uwierzytelnienia. Aby pom�c Ci zrozumie� wp�yw, przejrzyjmy przyk�ad exploita. Za��my, �e Tw�j kod dzia�a na twoim ho�cie lokalnym i jest podatny na do��czanie plik�w lokalnych i akceptuje nazw� obrazu, kt�ry musi zosta� wy�wietlony. Najpierw u�ywamy polecenia nc localhost 80, aby po��czy� si� z serwerem WWW. Nast�pnie wysy�amy nast�puj�ce ��danie do serwera:

GET / HTTP/1.1
Host: localhost
Apache zapisze wiersz w pliku dziennika, kt�ry wygl�da mniej wi�cej tak:
127.0.0.1 - - [08/Apr/2016:13:57:38 +0000]
"GET /
HTTP/1.1" 400 226
""
""

Podziel� m�j wpis dziennika na wiele wierszy, ale oczywi�cie w twoim pliku dziennika wszystko b�dzie w tej samej linii. Nast�pnym krokiem exploita jest wys�anie do witryny ��dania zawieraj�cego plik dziennika (wymaga to wyst�pienia takiej luki w zabezpieczeniach witryny).

http: // localhost /? plik = / var / log / apache2 / access.log & cmd = ls -la

Musisz by� bardzo podatny na bycie podatnym na to:

• U�ytkownik serwera WWW potrzebuje dost�pu do odczytu do docelowego pliku dziennika
• Tw�j kod musi umo�liwia� atakuj�cemu do��czenie pliku docelowego
• Nie mo�esz wy��czy� exec, passthru i systemu w swojej konfiguracji

Algorytmy szyfrowania i mieszania

Szyfrowanie i mieszanie to r�ne poj�cia i powiniene� upewni� si�, �e rozumiesz r�nic�. Szyfrowanie jest operacj� dwukierunkow�; mo�esz szyfrowa� i deszyfrowa�. Hashowanie jest operacj� jednokierunkow� i z za�o�enia trudno jest lub czasoch�onnie pobra� hasz i odwr�ci� go do pierwotnego ci�gu. Has�a nale�y przechowywa� w bazie danych jako skr�ty. W ten spos�b, je�li osoby atakuj�ce otrzymaj� kopi� bazy danych, nadal nie b�d� mog�y uzyska� hase� u�ytkownik�w, chyba �e b�d� w stanie odwr�ci� skr�t. Zwykle cofni�cie skr�tu zajmuje du�o czasu i mam nadziej�, �e b�dziesz mia� wystarczaj�co du�o czasu, aby zauwa�y� naruszenie bezpiecze�stwa i ostrzec u�ytkownik�w, �e musz� zmieni� swoje has�a. Czas potrzebny na obliczenie skr�tu okre�li, ile czasu haker b�dzie odgad� has�a przy u�yciu brutalnej si�y.

Szyfrowanie w PHP

Szyfrowanie w PHP zapewnia modu� mcrypt, kt�ry nale�y zainstalowa� i w��czy� osobno. Modu� mcrypt udost�pnia szeroki zakres funkcji i sta�ych szyfrowania. Dost�pne algorytmy zale�� od systemu operacyjnego, na kt�rym zainstalowany jest PHP. Nie nale�y pr�bowa� pisa� w�asnej implementacji algorytmu szyfrowania. Egzamin certyfikacyjny Zend nie k�adzie du�ego nacisku na szyfrowanie.

Funkcje skr�tu

Starsze skr�ty, takie jak MD5 i SHA1, s� bardzo szybkie do obliczenia, wi�c nie wolno ich u�ywa� w �adnym miejscu, w kt�rym wyst�puje bezpiecze�stwo. Nadal s� bardzo przydatne w innych obszarach programowania, ale nie w �adnym miejscu, w kt�rym polegasz na tym, �e s� operacj� jednokierunkow�. PHP 5.5.0 wprowadza funkcj� password_hash(), kt�ra zapewnia wygodny spos�b generowania bezpiecznych skr�t�w. W przypadku starszych wersji PHP nale�y u�y� funkcji crypt (). Domy�lnie funkcja password_hash () u�ywa algorytmu bcrypt do mieszania has�a. Algorytm bcrypt ma parametr okre�laj�cy, ile razy powinien uruchom has�o przed zwr�ceniem wyniku mieszania. Jest to okre�lane jako "koszt" algorytmu. Zwi�kszaj�c liczb� uruchomie� algorytmu, mo�na wyd�u�y� czas potrzebny do obliczenia warto�ci skr�tu. Oznacza to, �e wraz z komputerami szybciej, mo�esz zwi�kszy� liczb� iteracji w algorytmie bcrypt, aby zabezpieczy� has�a przed atakami si�owymi. Za pomoc� funkcji password_info() mo�na uzyska� informacje na temat sposobu obliczania warto�ci skr�tu. Ta funkcja powie Ci nazw� algorytmu, koszt i s�l. Funkcja password_needs_rehash() por�wna skr�t z opcjami okre�lonymi przez u�ytkownika, aby sprawdzi�, czy trzeba go ponownie przebudowa�. Umo�liwi to zmian� algorytmu u�ywanego do mieszania has�a, na przyk�ad zwi�kszaj�c koszty w czasie.

Zabezpiecz losowe ci�gi i liczby ca�kowite

PHP ma dwie funkcje, kt�re pozwalaj� wygodnie generowa� kryptograficznie bezpieczne liczby ca�kowite i �a�cuchy. Te funkcje b�d� dzia�a� na dowolnej platformie, na kt�rej dzia�a PHP.

Funkcja : Parametry : Warto�� zwracana : Opis

random_bytes : Int $ length : Ci�g bajt�w Generuje losowy ci�g znak�w o d�ugo�ci $length bajt�w

random_int : Int $ min, int $ max : Losowa liczba ca�kowita : Generuje losow� liczb� ca�kowit� w zakresie okre�lone przez $min i $maks

Oto przyk�ad u�ycia random_bytes:

< ?php
// pobierz ci�g zawieraj�cy 8 losowych bajt�w
$randomBytes = random_bytes(8);
$printableVersion = bin2hex($randomBytes);
echo $printableVersion; // d7e263202be1b99b

Ci�g, kt�ry generuje PHP, niekoniecznie b�dzie mo�na go wydrukowa�, wi�c u�ywam funkcji bin2hex (), aby przekonwertowa� go na ci�g szesnastkowy. Heksadecymalny wymaga dw�ch znak�w do wy�wietlenia bajtu, wi�c ci�g, kt�ry wyprowadzamy na ko�cu, ma d�ugo�� 16 znak�w (dwa razy tyle, ile wygenerowali�my losowych bajt�w).

Solenie hase�

Ci�g solny to dodatkowy ci�g dodawany do has�a. Powinien by� generowany losowo dla ka�dego has�a. S�u�y do utrudniania atak�w s�ownikowych i wst�pnie obliczonych atak�w t�czy. Mo�esz poda� s�l dla funkcji password_hash(), ale je�li j� pominiesz, PHP j� utworzy. Podr�cznik PHP zauwa�a, �e zamierzonym trybem dzia�ania jest umo�liwienie ci stworzenia losowej soli dla has�a. Funkcja crypt() przyjmuje �a�cuch soli jako drugi parametr, ale nie wygeneruje automatycznie soli, je�li nie podasz w�asnego. PHP 5.6.0+ wyda powiadomienie, je�li nie podasz soli.

Sprawdzanie has�a

Je�li atakuj�cy mo�e dok�adnie zmierzy� czas potrzebny do uruchomienia procedury sprawdzania has�a, b�dzie on w stanie zebra� informacje, kt�re pomog� mu z�ama� has�o. Ataki te s� okre�lane jako ataki na czas. Funkcja password_verify() PHP 5.5.0 jest bezpiecznym sposobem por�wnania w czasie skr�ty utworzone przez password_hash(). Je�li nie mo�esz u�y� tej funkcji, musisz obliczy� skr�t dla has�a podanego przez u�ytkownika, a nast�pnie por�wna� skr�t z zapami�tanym. Por�wnywanie skr�t�w jest podatne na ataki czasowe. PHP 5.6.0 wprowadzi�o funkcj� hash_equals(), kt�ra jest bezpiecznym dla czasu sposobem por�wnywania napis�w. Powiniene� u�y� tej funkcji do por�wnywania skr�t�w generowanych przez crypt().

Szybka uwaga na temat komunikat�w o b��dach

Nigdy nie nale�y potwierdza� osobie, �e wprowadzi�a niepoprawn� nazw� u�ytkownika. Komunikat o b��dzie powinien wskazywa�, �e wpisali nieprawid�ow� nazw� u�ytkownika lub has�o. Im mniej informacji podasz atakuj�cemu, tym d�u�ej zajmie im uzyskanie dost�pu do twojego systemu

Przesy�anie plik�w

Przesy�anie plik�w stanowi powa�ne ryzyko dla aplikacji internetowej i musi by� zabezpieczone na kilka sposob�w. Przypomnij sobie, �e superglobal $ _FILES [] zawiera informacje o plikach przes�anych przez klienta. Powiniene� traktowa� wszystko w tej tablicy jako podejrzane i upewni� si�, �e r�cznie potwierdzasz ka�d� informacj�. Spos�b, w jaki PHP obs�uguje przesy�anie plik�w, polega na zapisaniu ich w katalogu tymczasowym. Mo�esz na nich operowa�, a nast�pnie przenie�� je do miejsca, w kt�rym chcesz. Powiniene� sprawdzi�, czy plik, z kt�rym pracujesz, jest prawid�owym przes�anym plikiem oraz czy klient pr�bowa� sfa�szowa� swoj� nazw� pliku i lokalizacj� w folderze tymczasowym. U�yj funkcji is_uploaded_file(), aby upewni� si�, �e plik, do kt�rego si� odwo�ujesz, zosta� rzeczywi�cie przes�any. U�yj metody move_uploaded_file () zamiast innych metod, aby przenie�� go z katalogu tymczasowego do ostatecznej lokalizacji. Odnosz�c si� do pliku, u�yj funkcji basename(), aby usun�� cie�ki, aby uniemo�liwi� osobie fa�szowanie nazwy pliku. Nie ufaj typowi MIME okre�lonemu przez u�ytkownika. Zignoruj typ MIME dostarczony przez u�ytkownika i u�yj finfo_file(), aby okre�li� typ MIME, je�li go potrzebujesz. Je�li zezwalasz u�ytkownikowi na przesy�anie obrazu, powiniene� u�y� na nim funkcji GD, takiej jak getimagesize(), aby potwierdzi�, �e jest to prawid�owy obraz. Je�li ta funkcja zawiedzie, plik nie jest prawid�owym obrazem. Wygeneruj w�asn� nazw� pliku, aby zapisa� plik jako i nie u�ywaj tej dostarczonej przez u�ytkownika. Zdecydowanie zalecane jest u�ycie losowego skr�tu dla nazwy pliku i r�czne ustawienie rozszerzenia poprzez sprawdzenie typu MIME. Upewnij si�, �e folder, w kt�rym przechowujesz pliki, umo�liwia dost�p tylko do u�ytkownika serwera WWW. Je�li nie musisz podawa� przes�anych plik�w, trzymaj folder przesy�ania poza katalogiem g��wnym dokumentu.

Przechowywanie bazy danych

Opr�cz unikania wstrzykiwania SQL nale�y stosowa� pewne zasady bezpiecze�stwa podczas interakcji z baz� danych. Nale�y oddzieli� serwery bazy danych dla r�nych �rodowisk kodu. Twoje serwery kontroli jako�ci, testowania, programowania i produkcji powinny u�ywa� r�nych serwer�w baz danych i nie powinny mie� mo�liwo�ci wzajemnego dost�pu do baz danych. Musisz uniemo�liwi� Internetowi dost�p do serwera bazy danych. Mo�na to osi�gn�� za pomoc� zapory ogniowej do zamkni�cia portu z ruchu zewn�trznego, przy u�yciu prywatnej podsieci, kt�ra nie ma trasy do Internetu, lub skonfigurowania serwera bazy danych, aby nas�uchiwa� tylko okre�lonych host�w. Nie wystarczy zmieni� port, na kt�rym nas�uchuje baza danych. Chcia�bym powiedzie�, �e nie warto si� tym przejmowa�, poniewa� nie jest to nawet wzrost pr�dko�ci atakuj�cego i po prostu utrudnia korzystanie z �rodowiska serwerowego dla wsp�pracownik�w. Je�li uruchamiasz kilka aplikacji na jednym serwerze bazy danych, upewnij si�, �e ka�da z nich ma w�asn� nazw� u�ytkownika i has�o na serwerze. Ka�dy u�ytkownik aplikacji powinien mie� tylko najmniejsz� liczb� wymaganych uprawnie� i nigdy nie powinien by� w stanie czyta� baz danych innych aplikacji. Unikaj u�ywania przewidywalnych nazw u�ytkownik�w i upewnij si�, �e korzystasz z bezpiecznych hase�. Na przyk�ad zwykle u�ywam losowo generowanego UUID wersji 4 jako has�a. Szyfruj poufne dane za pomoc� mcrypt () i mhash () przed umieszczeniem ich w bazie danych. Od czasu do czasu nale�y sprawdza� dzienniki bazy danych. B�dziesz m�g� dostrzec pr�by atak�w iniekcyjnych i innych wzor�w, kt�re pozwol� ci zidentyfikowa� naruszenia lub zaostrzy� obszary kodu.

Unikaj publikowania swojego has�a online

Dobr� rad� jest unikanie publikowania po�wiadcze� bazy danych lub interfejsu API w Internecie, gdzie ludzie mog� je odczyta�. Okej, jestem �artobliwy, ale na powa�nie, kiedy prawdopodobnie opublikowa�by� wszystkie swoje dane dost�powe dla �wiata i jego psa do przeczytania? Mo�na to zrobi� tylko raz, zatwierdzaj�c repozytorium Git i przekazuj�c je do us�ug takich jak GitHub lub Bitbucket. Upewnij si�, �e wszystkie pliki konfiguracyjne s� ignorowane przez system kontroli wersji i nigdy nie s� zatwierdzane ani przekazywane do repozytori�w nadrz�dnych. S� roboty, kt�re zbieraj� GitHub w celu uzyskania po�wiadcze�, kt�re b�d� kara� ci� za te b��dy. Tak na marginesie, jak ten link, nie powiniene� kodowa� po�wiadcze� Amazon w aplikacji. Zamiast tego ustaw rol� IAM, kt�ra zezwala na dost�p do us�ugi, z kt�rej chcesz korzysta�, i zastosuj rol� na maszynie wirtualnej.

QUIZ

P1: Zalecane ustawienie produkcyjne dla ustawienia konfiguracji display_error to W��czone.

---------------------------
Prawdziwe
Fa�szywe

P2: U�ywanie protoko�u HTTPS do szyfrowania strony logowania pomo�e zapobiec przej�ciu sesji i naprawianiu sesji.

---------------------------
Prawdziwe
Fa�szywe *

P3: Mo�esz wymusi� umieszczanie sesji wy��cznie w plikach cookie, u�ywaj�c ustawienia konfiguracji _____________.

---------------------------
session.cookie_secure
session.use_cookies
session.use_trans_sid
�adne z powy�szych

P4: CSRF polega na tym, �e osoba atakuj�ca oszukuje przegl�dark� lub urz�dzenie u�ytkownika w celu z�o�enia ��dania bez ich wiedzy. Wykorzystuje zaufanie serwera do przegl�darki. Mo�esz tego unikn��, do��czaj�c do formularza token CSRF, kt�ry zwi�ksza si� o jeden za ka�dym razem, gdy odwiedzaj�cy �aduje stron�.

---------------------------
Prawdziwe
Fa�szywe

P5: Zar�wno funkcje crypt (), jak i password_hash () pozwalaj� ci okre�li� s�l, ale je�li nie, wygenerujesz odpowiednio losow� s�l.

---------------------------
Prawdziwe
Fa�szywe

P6: Przegl�darka okre�la typ pliku, wykonuj�c wywo�anie systemu operacyjnego i wysy�a te informacje wraz z ��daniem. Mo�esz zaufa� temu, aby okre�li� rozszerzenie, kt�re b�dzie u�ywane podczas przechowywania pliku.

---------------------------
Prawdziwe
Fa�szywe

P7: Poniewa� PHP usuwa plik tymczasowy po zako�czeniu dzia�ania, powiniene� najpierw upewni� si�, �e u�ywasz funkcji copy(), aby umie�ci� plik tymczasowy w sta�ej lokalizacji.

---------------------------
Prawdziwe
Fa�szywe

P8: Domy�lnie PHP jest skonfigurowane tak, aby mog�o zawiera� kod �r�d�owy przechowywany w adresie URL.

---------------------------
Prawdziwe
Fa�szywe

P9: Odpowiednim �rodkiem zaradczym, aby zapobiec XSS, jest u�ycie funkcji strip_tags () przed tre�ci�.

---------------------------
Prawdziwe
Fa�szywe
P10: Ustawienie konfiguracji open_basedir nie ma �adnego efektu, chyba �e w��czony jest tryb bezpieczny PHP. Ogranicza katalogi, do kt�rych PHP ma dost�p.

---------------------------
Prawdziwe
Fa�szywe

ODPOWIEDZI

• Fa�szywe

• Fa�szywe

• �adne z powy�szych

• Fa�szywe

• Fa�szywe

• Fa�szywe

• Fa�szywe

• Prawdziwe

• Fa�szywe

• Fa�szywe

Certyfikat ZendPHP

Bezpiecze�stwo

QUIZ

ODPOWIEDZI