Print

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.com
    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

Odkomentować (lub dodać) w pliku web.config następujący wpis, ale tylko w sytuacji, gdy mamy SSL:

<httpCookies requireSSL="true" />

Ukrycie wyświetlania szczegółów błędów

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:

<customErrors mode="Off" defaultRedirect="error.aspx" />

to należy zmienić go na następujący:

<customErrors mode="RemoteOnly" defaultRedirect="error.aspx" />

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.

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:

<configuration>
  <system.webServer>
   <directoryBrowse enabled="false" />
   <httpErrors errorMode="Custom">
      <remove statusCode="404" />
      <error statusCode="404" path="/fizyczna_ścieżka_do_strony_błędu/404.html" responseMode="Redirect" />
      <error statusCode="403"path="/fizyczna_ścieżka_do_strony_błędu/404.html" responseMode="Redirect" />
   </httpErrors>
  </system.webServer>
</configuration>

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.

Czy artykuł był pomocny?
0 na 5 gwiazdek
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
5
How can we improve this article?
How Can We Improve This Article?