Jak minimalnie zabezpieczyć stronę internetową?

W poniższym wpisie poruszę temat podstawowych zabezpieczeń serwisu internetowego. W wielu przypadkach firmy hostingowe udostępniają serwery działające w oparciu o system Debian, Centos, Ubuntu i webserver Apache. W środowisku Apache do zabezpieczenia strony internetowej można wykorzystać pliki .htaccess oraz pliki php.ini, .htpasswd. Poniżej rozważania na temat zawartości tych plików.

Obecnie wielu webdeweloperów do budowy stron internetowych wykorzystuje gotowe CMSy: WordPress, Joomla, Drupal, Prestashop, Magento. Te CMSy łączy jedno – język PHP użyty do ich stworzenia. Dlatego warto zadbać aby wersja oprogramowania PHP na serwerze była jak najbardziej aktualna, tzn. miała wsparcie w zakresie poprawek bezpieczeństwa. Warto uwzględnić cykl życia PHP oraz możliwość wyboru różnych wersji PHP (na różne serwisy internetowe) w ramach jednego konta hostingowego. Wersja PHP dla danego serwisu internetowego może być wskazana w pliku .htaccess w głównym katalogu przypisanym w panelu klienta (Cpanel lub DirectAdmin) do danej domeny internetowej. Przykłady:

#Ustawienie wersji PHP w katalogu
<FilesMatch "\.(inc|php|php3|php4|php44|php5|php52|php53|php54|php55|php56|php6|phtml|phps)$">
AddType application/x-lsphp55 .php5 .php4 .php .php3 .php2 .phtml
AddHandler application/x-lsphp70 .php5 .php4 .php .php3 .php2 .phtml
</FilesMatch>
lub inaczej – w zależności od hostingu (sprawdz w swoim hostingu):
#Ustawienie wersji PHP w katalogu
<IfModule mime_module>
AddType application/x-httpd-ea-php71___lsphp .php .php7 .phtml
</IfModule>

Katalogi domeny na serwerze w ostingu
W trakcie budowy serwisu internetowego warto zadbać aby serwis www nie był dostępny dla szerokiej publiki oraz robotów internetowych (m.in. google), tzn. był dostępny jedynie po podaniu nazwy użytkownika i hasła. W tym celu można dodać odpowiedni wpis(y) w pliku .htaccess zawierający nazwę i hasło użytkownika odwołujący się do pliku .htpasswd. Hasło do umieszczenia w pliku .htpasswd możesz wygenerować na stronie: http://www.kxs.net/support/htaccess_pw.html

Wpis w pliku .htaccess może wyglądać jak poniżej (example.com zastąp nazwą swojej domeny):
#Haslo dostepu do strony example.com
AuthName "Podaj haslo"
AuthType Basic
AuthUserFile /home/username/domains/example.com/public.html/.htpasswd
Require valid-user

W ten sposób w katalogu głównym domeny znajdą się 2 pliki: .htaccess i .htpasswd. Do kompletu brakuje pliku php.ini (lub user.ini), który również można skopiować do katalogu głównego (root) domeny i do katalogów administratora (example.com/wp-admin, /administrator, /admin). Przykładowa zawartość pliku php.ini:
expose_php = Off
display_errors = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
register_globals = Off
safe_mode = Off
allow_url_fopen = Off
allow_url_include = Off
upload_max_filesize 3M
post_max_size 10M
disable_functions=show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

W razie potrzeby separacji katalogów dla różnych domen dodaj również do pliku php.ini dyrektywę:
open_basedir=/home/username/domains/example.com/public.html/:/tmp/
Oczywiście, zmień „username” na nazwę swojego użytkownika w hostingu a nazwę domeny example.com zastąp nazwą katalogu na hostingu do którego wgrano pliki strony internetowej.

jak-odczytac-wersje-wordpress W ten sposób mamy 3 pliki które nie powinny być dostępne do odczytu z zewnątrz, przez Internautów: .htaccess, .htpasswd i php.ini. W przypadku aktualizacji CMSa WordPress pojawiają się kolejne pliki:
wp-config.php, wp-config-sample.php, readme.html, license.txt, /wp-admin/install.php
a w przypadku Joomla:
configuration.php, README.txt, LICENSE.txt.

Potencjalny napastnik w ramach rekonesansu – domyślnie ma (miał) możliwość odgadnięcia wersji CMS, wpisując w pasku adresu np.: www.example.com/readme.html czy www.example.com/README.txt

Uniwersalne reguły w pliku .htaccess

W celu zabezpieczenia powyższych plików przed potencjalnymi napastnikami warto dodać do pliku .htaccess wpisy:
#.htaccess file access protection
<Files .htaccess>
order allow,deny
deny from all
</Files>
#.htpasswd file access protection
<files .htpasswd>
order allow,deny
deny from all
</files>
#php.ini file access protection
<files php.ini>
order allow,deny
deny from all
</files>

Dodatkowe wpisy dla CMS WordPress:

#wp-config.php file access protection
<files wp-config.php>
order allow,deny
deny from all
</files>
<files wp-config-sample.php>
order allow,deny
deny from all
</files>
<files readme.html>
order allow,deny
deny from all
</files>
<files license.txt>
order allow,deny
deny from all
</files> <files xmlrpc.php> order deny,allow deny from all </files><files install.php>
order allow,deny
deny from all
</files>
W ten sposób po każdorazowej aktualizacji WordPressa nie muszi kasować w/w plików ponieważ będą zabezpieczone odpowiednimi wpisami przed potencjalnymi napastnikami.

Dodatkowe wpisy dla dla CMS Joomla:

#configuration.php file access protection
<files configuration.php>
order allow,deny
deny from all
</files>
<files README.txt>
order allow,deny
deny from all
</files>
<files LICENSE.txt>
order allow,deny
deny from all
</files>

Reguły podnoszące bezpieczeństwo serwisu internetowego

Kolejne dyrektywy podnoszące bezpieczeństwo serwisu www – wpisz do pliku: .htaccess:
#Disable Directory Browsing #http://httpd.apache.org/docs/1.3/howto/htaccess.html
Options All -Indexes
# No directory listings
IndexIgnore *
##Remove Apache and PHP version signature
<IfModule mod_headers.c>
Header unset X-Powered-By
</IfModule>
#Disable server signature
ServerSignature Off
#Reflected XSS prevention #https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Best_Practices<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>
## Reduce MIME type security risks
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
</IfModule>
## Prevent content transformation #https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#
<IfModule mod_headers.c>
Header merge Cache-Control "no-transform"
</IfModule>
#Protect against clickjacking (zamień example.com na nazwę swojej domeny)
#Hide X-Powered-By and Server headers #https://developer.mozilla.org/fr/docs/HTTP/Headers/X-Frame-Options#
<IfModule mod_headers.c>
Header always append X-Frame-Options SAMEORIGIN
Header set Access-Control-Allow-Origin https://example.com/
# The `X-Frame-Options` response header should be send only for
# HTML documents and not for the other resources.
<FilesMatch "\.(appcache|atom|bbaw|bmp|crx|css|cur|eot|f4[abpv]|flv|geojson|gif|htc|ico|jpe?g|js|json(ld)?|m4[av]|manifest|map|mp4|oex|og[agv]|opus|otf|pdf|png|rdf|rss|safariextz|svgz?|swf|topojson|tt[cf]|txt|vcard|vcf|vtt|webapp|web[mp]|woff2?|xloc|xml|xpi)$">
Header always unset "X-Powered-By"
Header unset "X-Powered-By”
</FilesMatch>
</IfModule> #Implement cookie HTTP header flag with HTTPOnly & Secure to protect website from XSS attacks#https://www.owasp.org/index.php/HttpOnly
<IfModule headers_module>
Header always edit Set-Cookie ^(.*)$ $1;HttpOnly
Header always edit Set-Cookie ^(.*)$ $1;Secure
</IfModule> #Block Libwww-perl#https://www.askapache.com/htaccess/blocking-bad-bots-and-scrapers-with-htaccess/#
#Options +FollowSymLinks – odkomentuj jeśli zadziała na Twoim hostingu
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} libwww [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)=http [NC]
RewriteRule ^(.*)$ - [F,L]

Dodatkowo umieść przekierowanie 301 na wybrany adres domeny (np. bez www).
#301 Redirect from www.example.com on example.com (example.com zastąp nazwą swojej domeny)
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]

Powyższe reguły są uniwersalne dla wielu CMSów, można je zastosować w serwisie internetowym wykorzystującym LAMP. Pamiętaj – robisz to na swoją odpowiedzialność – dlatego wcześniej wykonaj kopię zapasową plików .htaccess, .htpasswd, php.ini używanych do chwili zmiany ich zawartości.

Podsumowanie

Niezależnie od powyższych regułek wpływających na podwyższony poziom bezpieczeństwa strony internetowej – w pliku .htaccess trzeba umieścić domyślne reguły dla danego CMSa. W większości przypadków domyślny plik .htaccess jest umieszczany w czasie instalacji CMSa w głównym katalogu strony internetowej. Niemniej, domyślne wartości wpisów w pliku .htaccess dla różnych CMSów zamieszczam w linkach poniżej:
Wzór .htaccess dla WordPress,
Wzór .htaccess dla Joomla,
Wzór .htaccess dla Drupal,
Wzór .htaccess dla Prestashop,
Wzór .htaccess dla Magento.

Autor niniejszego wpisu nie bierze odpowiedzialności za wszelkie zmiany jakie czytelnik na podstawie tego wpisu bloga zaimplementuje w swoim serwisie internetowym. Autor poleca regularne wykonywanie kopii bezpieczeństwa serwisu internetowego przed wszelkimi zmianami. W przyszłym, kolejnym wpisie opiszę jak można zabezpieczyć stronę internetową przy wykorzystaniu bardziej zaawansowanych reguł w pliku .htaccess.