Dodatkowe zabezpieczenia aplikacji webowej AMODIT
Wstęp
W tym artykule przedstawiamy kilka wskazówek zwiększających bezpieczeństwo aplikacji webowej AMODIT przed różnymi podatnościami na potencjalne ataki z zewnątrz. Wskazówki powstały na bazie wykonanych testów penetracyjnych.
Wykonanie większości wskazanych poniżej czynności nie wymaga reinstalacji systemu AMODIT. Zmiany wprowadza się w pliku web.config aplikacji webowej AMODIT lub rejestrze serwera Windows, gdzie wspomniana aplikacja jest zainstalowana. Z tego też powodu osoba wprowadzająca wskazane zabezpieczenia musi posiadać uprawnienia administracyjne na serwerze Windows.
Zmiany w pliku web.config
W pliku web.config jest zakomentowanych kilka wpisów, które polepszają bezpieczeństwo aplikacji, ale nie zawsze mogą być użyte.
Aktywacja dodatkowych nagłówków
W sekcji „customHeaders” pliku web.config zaleca się odkomentowanie (lub dodanie) następujących wpisów:
<customHeaders>
<add name="Content-Security-Policy" value="script-src 'unsafe-inline' 'unsafe-eval' 'self';
object-src 'self'; img-src 'self' data: blob:; frame-src 'self' blob:; child-src 'self' ; base-uri 'self';
form-action 'self'; frame-ancestors 'self'; worker-src 'self' blob: ;
connect-src 'self' https://amodit.pl ; upgrade-insecure-requests"/>
<add name="X-Content-Type-Options" value="nosniff" />
<add name="X-XSS-Protection" value="1; mode=block" />
<add name="X-Frame-Options" value="sameorigin" />
<add name="Strict-Transport-Security" value="max-age=31536000"/>
<add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders>Objaśnienia (opisy w języku angielskim na bazie raportu firmy Sisoft) i dodatkowe uwagi:
- Content-Security-Policy: is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
UWAGA! Dodatkowo jeżeli mamy włączone pobieranie skryptów z Google Tag Manager, to w Content-Security-Policy trzeba w script-src dodać adresy wszystkich podłączonych serwisów zaczynając od https://www.googletagmanager.com, w postaci:
script-src 'unsafe-inline' 'unsafe-eval' 'self' https://www.googletagmanager.comA jeżeli w systemie korzystamy z OCR faktur przez usługę Skanuj.to, to w 'frame-src’ należy dopisać adres serwisu ’https://app.skanuj.to/’ w postaci:frame-src 'self' https://app.skanuj.to/ - X-Content-Type-Options: is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a way to say that the webmasters knew what they were doing.
- X-XSS-Protection: Disables XSS filtering. 1 Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts). 1; mode=block Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
- X-Frame-Options: can be used to indicate whether or not a browser should be allowed to render a page in a
<frame>, <iframe>, <embed> or <object>Sites can use this to avoid clickjacking attacks by ensuring that their content is not embedded into other sites. - Strict-Transport-Security: let a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP. The header is configured however, max-age parameter (in seconds) is too short (Strict-Transport-Security: max-age=15724800;). It should be valid for 1 year (= 31536000). UWAGA! Strict-Transport-Security można włączyć tylko jeżeli mamy SSL.
- Referrer-Policy: is a new header that allows a site to control how much information the browser includes navigations away from a document and should be set by all sites.
Zabezpieczenie plików cookie
Pliki cookie używane w AMODIT powinny być odpowiednio zabezpieczone, a więc powinny mieć włączony atrybut „secure”. W tym celu należy odkomentować (lub dodać) w pliku web.config w sekcji
Można jeszcze dodatkowo w węźle
requireSSL="true" slidingExpiration="false">
Dodatkowe informacje odnośnie plików cookie w systemie AMODIT
Ze względów technicznych niektóre pliki cookie, np. AMODWebAppAuthCookieTime, nie mogą mieć ustawionego atrybutu „HTTPOnly”. Potrzebne to jest m.in. do prawidłowego działania plików JavaScript. Jednocześnie informujemy, że wspomniane ciasteczko AMODWebAppAuthCookieTime nie pozwala na przejęcie sesji użytkownika nawet wtedy, gdyby został wykonany jakiś atak na aplikację AMODIT, którego celem byłoby przejęcie sesji użytkownika.
Zgoda na użycie cookies przez użytkownika
Zgoda na użycie cookies nie dotyczy aplikacji webowych do użytku własnego wewnątrz firmy. W systemie AMODIT cookies wspierają utrzymanie sesji użytkownika lub obsługę interfejsu, a nie śledzą jego aktywność w sensie takim, że to, co robi w systemie, jest gdzieś wysyłane na zewnątrz do użycia np. w celach marketingowych.
Jeżeli z jakichś powodów biznesowych jednak będzie potrzeba wyświetlenia informacji o wykorzystaniu cookies, to może wystarczy, aby ustawić komunikat o użyciu ciasteczek na stronie logowania. Chodzi o te ustawienia …
… a efekt będzie taki:
Zmiana nazwy cookie przechowującego identyfikator sesji
Ze względów bezpieczeństwa, aby nie ujawniać technologii aplikacji, zaleca się zmienić nazwę cookie sesyjnego. W tym celu w pliku web.config należy wprowadzić poniższy wpis w sekcji system.web:
Ukrycie wyświetlania szczegółów błędów …
… poprzez zmianę konfiguracji w pliku web.config
W przypadku błędu aplikacji webowej, aby uniknąć wyświetlania użytkownikowi szczegółów powstałego błędu, należy zmienić tryb wyświetlania błędów z wartości „Off” na „RemoteOnly”. Szczegóły błędów będą wtedy widoczne tylko w przeglądarce lokalnie na serwerze.
Jeśli w pliku web.config jest taki zapis:
to należy zmienić go na następujący:
Dodatkowo warto stworzyć własną stronę HTML, informującą użytkownika w sposób „przyjazny” o wystąpieniu błędu, i że np. powinien skontaktować się z administratorem. Adres URL takiej strony należy podać w atrybucie „defaultRedirect” w powyższych ustawieniach.
… poprzez zmiany konfiguracji w IIS
W usłudze MS Internet Information Services (IIS) można ustawić dedykowane komunikaty dla np. następujących kodów błędów: 401, 403, 404, 405, 406, 412, 500, 501, 502. Aby to zrobić, należy wykonać następujące kroki:
- Wejść do ustawień witryny AMODIT w IIS, a następnie wybrać opcję „Error Pages”.
- Dodać obsługę nowego kodu na przykład przez kliknięcie prawym przyciskiem myszki w tabeli i wybranie opcji „Add” z menu kontekstowego.
- W oknie dialogowym „Add Custom Error Page” w parametrze „Status Code” wpisać kod błędu, dla jakiego ma się wyświetlić wybrana strona. Następnie w „Response Action” wskazać plik html (trzeba go wcześniej przygotować i umieścić w strukturze witryny AMODIT) z własną informacją o błędzie lub przekierowanie na wybrany inny adres.
Przekierowanie komunikatu błędu HTTP 403 Forbidden na HTTP 404 Not Found
W celu zabezpieczenia się przed tzw. enumeracją zasobów (katalogów) na serwerze można ustawić na stałe przekierowanie komunikatu błędu HTTP 403 Frobidden na HTTP 404 Not Found. Można tego dokonać z poziomu ustawień serwera IIS, ale też można taką konfigurację wprowadzić w pliku web.config aplikacji webowej. To drugie podejście prezentujemy w tym rozdziale.
Przed przystąpieniem do zmian w pliku web.config może być wymagane zainstalowanie modułu „http errors” w IIS. Dodatkowo warto stworzyć własną stronę HTML dla komunikatu błędu HTTP 404 Not Found.
Zmiany w pliku web.config prezentuje poniższy kod:
W podanym przykładzie zakłada się, że plik HTML z komunikatem błędu znajduje się w pliku 404.html. W argumencie path podaje się ścieżkę do wspomnianego pliku 404.html względem lokalizacji pliku web.config.
Wyłączenie nieaktualnych protokołów TLS i SSL (zmiany w rejestrze systemu Windows)
W celu wyłączenia nieaktualnych protokołów TLS i SSL zaleca się wykonanie czynności opisanych w tym artykule:
https://improveandrepeat.com/2020/03/how-to-disable-tls-1-0-1-1-and-ssl-on-your-windows-server
Dodatkowa informacja jest taka, że dla systemów Windows 10/Server 2019 należy włączyć TLS w wersji 1.2, która wciąż jest uważana za bezpieczną (stan wiedzy na dzień 2024-07-09). Natomiast w przypadku posiadania systemów Windows 11/Server 2022 (lub nowszych) zaleca się korzystanie z protokołu TLS w wersji 1.3.
UWAGA! Po wprowadzeniu poniższych zmian w rejestrze wymagane jest zrestartowanie serwera Windows.
Dołączamy również skrypt dodający odpowiednie wpisy do rejestru skopiowany z powyższej strony:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000
Usunięcie niepotrzebnych nagłówków HTTP
Ze względów bezpieczeństwa warto rozważyć usunięcie niektórych nagłówków w odpowiedzi (ang. response) HTTP. Najczęściej są to te trzy nagłówki:
- Server Header – zawiera typ i numer wersji serwera WWW;
- X-Powered-By – wskazuje technologię w jakiej utworzona jest aplikacja webowa, w przypadku aplikacji AMODIT będzie to „powered by ASP.NET”;
- X-AspNet-Version – specyfikuje wersję ASP.NET.
Usunięcie wskazanych nagłówków nie jest obligatoryjne i należy to skonsultować z administratorami bezpieczeństwa lub IT.
Szczegółowy opis krok-po-kroku usuwania wspomnianych nagłówków znajduje się w tym artykule: Remove Unwanted HTTP Response Headers.
Ukrycie dokumentacji AMODIT SOAP API
Ze względów bezpieczeństwa zaleca się ukrycie dokumentacji do starego webservice’u SOAP. Aby wyłączyć generowanie wsdl z .asmx, należy dodać wpis w web.config zgodnie z instrukcją na stronie https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/aspnet/iisadmin-service-process/disable-documentation-protocol, czyli:
Generowanie unikalnego „machine key”
Ze względu na wypłynięcie domyślnego „machine key” (używanego przez Microsoft w aplikacjach webowych ASP .NET) ze wzorcowego pliku web.config zalecane jest wygenerowanie na każdym środowisku nowego, unikalnego klucza.
UWAGI:
- Przed wygenerowaniem nowego klucza należy wykonać kopię bezpieczeństwa pliku web.config z witryny. Należy go przekopiować poza folder witryny (nie do podfolderu).
- Operację należy przeprowadzić poza godzinami pracy i na czas operacji zatrzymać witrynę. Operacja spowoduje wylogowanie użytkowników.
Kroki potrzebne do wygenerowania nowego „machine key” są następujące:
- W IIS Managerze należy wybrać witrynę AMODIT, a następnie kliknąć opcję „Machine key” w sekcji „ASP .NET”.
- Nacisnąć „Generate keys”, a następnie „Apply”, jak będzie aktywne.
- Sprawdzić w pliku web.config, czy zostały zapisane nowe klucze.
- Jeżeli w środowisku mamy kilka witryn albo kilka serwerów podłączonych do jednej bazy danych, to dla każdej witryny w jej pliku web.config należy wpisać te wygenerowane klucze. Klucze można wkleić bezpośrednio w web.config albo z poziomu IIS Managera.
I jeszcze jedna uwaga: w nowej wersji w pliku web.config.txt (wchodzącego w skład aplikacji webowej w paczce instalacyjnej AMODIT) nie będzie już domyślnych wartości dla tych kluczy – przy każdej nowej instalacji trzeba je będzie wygenerować.
Zabezpieczenie antywirusowe
Zabezpieczenie systemu AMODIT przed załączaniem plików potencjalnie zawierających wirusy nie jest krokiem samym w sobie związanym ze zmianami w pliku web.config aplikacji webowej. Natomiast warto tą czynność wykonać, korzystając z opisu w tym artykule: Skanowanie antywirusowe wgrywanych dokumentów.