Do aplikacji webowych każdego dnia logują się miliony osób, pozostawiając w nich dane osobowe, czy inne, cenne informacje. Aplikacje stanowią jednak atrakcyjny cel dla cyberprzestępców, a ich nieupoważnione naruszenie i wyciek danych pociągają za sobą przykre konsekwencje.
Jakie rozwiązania wdrożyć, aby szybko i skutecznie poprawić ich bezpieczeństwo? Jakie są najczęstsze ataki i dlaczego mają miejsce? Na te pytania znajdziesz odpowiedzi w niniejszym artykule!
Table of Contents
Aplikacje webowe – czym są i jaka jest ich specyfika?
Aplikacja webowa (inaczej aplikacja internetowa) to oprogramowanie użytkowe, które w przeciwieństwie do programów komputerowych uruchamianych lokalnie w systemie operacyjnym (OS) urządzenia, działa na serwerze internetowym. Dysponując aktywnym połączeniem sieciowym, użytkownik uzyskuje dostęp do aplikacji poprzez przeglądarkę internetową, a instalacja nie jest wymagana.
O tym, że mamy do czynienia z aplikacją webową może wskazywać panel logowania. Niewątpliwą zaletą jest ich elastyczność, responsywność oraz uniwersalność względem systemu operacyjnego (Windows, MacOS, itd.). Dzięki nim kształtowane są nowoczesne strony internetowe, a komunikacja firm z odbiorcami jest znacznie ułatwiona. Znajdziemy je w postaci poczty internetowej, bankowości online, systemów logistycznych i zamówień, sklepów internetowych, serwisów ogłoszeniowych i społecznościowych, porównywarek cen czy forach internetowych.
Tutaj właśnie wyłania się najważniejsza kwestia w kontekście prezentowanego artykułu – to, że aplikacje internetowe pozwalają na pozyskiwanie, przetwarzanie, przechowywanie i przekazywanie wrażliwych danych użytkowników, np. numerów kart kredytowych, danych osobowych, informacji o ubezpieczeniach zdrowotnych, społecznych, itp.
Dlaczego aplikacje internetowe są celem ataków?
Dzięki swojej powszechności i ogólnodostępności aplikacje internetowe pozwalają atakującym dotrzeć do dużych grup odbiorców. Włamując się, mogą oni uzyskać dostęp zarówno do zasobów firmy, jak i danych tysięcy czy nawet milionów użytkowników. Jeśli luka w zabezpieczeniach aplikacji zostanie wykorzystana, dostęp do danych będzie możliwy bez względu na wprowadzone zabezpieczenia.
Ponadto aplikacje te są zwykle łatwiej dostępne niż inne cele hakerów i nie wymagają specjalnych narzędzi, połączeń czy zasobów państwowych. Wystarczy dowolny komputer z przeglądarką i połączeniem internetowym. Wykorzystanie znalezionej luki będzie wówczas dziecinnie proste. Co więcej, raz naruszone witryny mogą być początkiem innych ataków, eskalacji uprawnień czy uzyskania dostępu do serwerów plików, baz danych oraz innych krytycznych zasobów.
Kolejną kwestią są osoby piszące kod aplikacji webowych oraz ich doświadczenie. Niestety można spotkać wielu programistów, którzy nie posiadają dostatecznej wiedzy oraz umiejętności w zakresie bezpiecznego kodowania. Ponadto można obecnie zauważyć trend opierania aplikacji webowych na kodzie źródłowym innych firm. Dlatego przyczyną, dla której mogą być celem ataków, jest także brak aktualizacji zasobów stron trzecich (a często ich właściciele nawet nie mają pojęcia, że takowe są wykorzystywane właśnie w ich przypadku). Jeszcze innym problemem jest świadome ignorowanie instalacji łatek, wydawanych dla błędów i luk.
Rodzaje ataków na aplikacje webowe
Pomimo stale ewoluującej taktyki cyberprzestępców, można zauważyć pewną prawidłowość, jeśli chodzi o najczęstsze rodzaje ataków na aplikacje internetowe:
- SQL Injection (SQLI) – mamy z nim do czynienia, gdy atakujący wprowadzi złośliwy kod do formularza, a systemy po stronie ofiary niedostatecznie filtrują/oczyszczają te informacje, które z kolei mogą być wykorzystywane do wykonywania zapytań do bazy danych.
- Cross-site scripting (XSS) – cyberprzestępca zamieszcza na stronie internetowej fragment złośliwego kodu, wyświetlanego użytkownikom. Ma to na celu nakłonienie do wykonania pożądanych przez atakujących działań – kradzieży danych, i innych).
- Ataki typu DDoS (Distributed Denial of Service) – mamy z nimi do czynienia, gdy atakujący zasypuje serwer żądaniami, paraliżując go i uniemożliwiając użytkownikom uzyskanie dostępu do usług. Często wykorzystywane w tym celu są boty czy sieci skompromitowanych komputerów.
- Path traversal – na skutek tego ataku aplikacja umożliwia niekontrolowany dostęp do katalogów i plików, przechowywanych w systemie plików (np. krytycznych plików systemowych, kody źródłowego czy konfiguracji). Znany jest również pod nazwą „directory traversal” czy „dot-dot-slash”.
Warto mieć na uwadze, że przytoczone ataki często służą złamaniu pierwszej linii obrony, czyniąc ofiarę bardziej podatną na inne, bardziej wyrafinowane działania przestępcze.
Aplikacje webowe – jak podnieść poziom ich bezpieczeństwa?
1. Budowanie bezpiecznych aplikacji webowych
Zwiększanie poziomu bezpieczeństwa aplikacji najlepiej rozpocząć od samego początku, czyli od momentu, kiedy takowa powstaje (podczas projektowania, implementacji, wdrażania), ale też w trakcie jej życia. Uznanym przez programistów na całym świecie jest standard OWASP Top 10 (Open Web Application Security Project), który zawiera wytyczne dotyczące tworzenia bezpiecznego oprogramowania. Korzystanie z tego dokumentu jest pierwszym krokiem (i prawdopodobnie najbardziej efektywnym) w kierunku bezpieczniejszego kodowania i zminimalizowania ryzyka ataków.
Istnieją rozwiązania, które w praktyczny sposób rozwiązują ten problem, np. dedykowane treningi na cyberpoligonie (ang. cyber range), w oparciu o symulację. Dzięki uczestnictwu w szkoleniu uczestnik zapoznaje się z popularnymi metodami ataków na aplikacje webowe, uczy się je wykrywać oraz konfigurować bezpieczeństwo serwera i samych aplikacji. Ponadto trenujący może nabyć umiejętność identyfikacji i oceny infrastruktury IT pod kątem metod ochrony przed cyberatakami oraz zarządzania bezpieczeństwem rzeczywistej aplikacji webowej w warunkach codziennej pracy.
Więcej o naszych treningach cyber security
2. HTTP Strict-Transport-Security
HSTS jest mechanizmem znacząco podnoszącym bezpieczeństwo połączenia z webaplikacją. Mechanizm ten wymusza połączenie przeglądarki do serwera tylko za pomocą bezpiecznego połączenia HTTPS. Próba nawiązania połączenia niezabezpieczonym protokołem HTTP zakończy się niepowodzeniem. Dzięki takiemu rozwiązaniu zabezpieczamy naszą aplikację przed atakami typu man-in-the-middle.
Definicja nagłówka:
Strict-Transport-Security: max-age=31536000
Parametr max-age określa przez ile sekund od ostatniego wejścia użytkownika nagłówek HSTS ma obowiązywać. 31536000 sekund = 1 rok.
Gdy webaplikacja wymusza nagłówek HSTS, przeglądarka użytkownika zachowa się w następujący sposób:
- wszystkie próby nawiązania połączenia z użyciem protokołu http zostaną zmienione na protokół https np. http://example.com -> https://example.com
- jeżeli bezpieczeństwo połączenia nie jest zapewnione ponieważ wygasł certyfikat SSL lub jest nieprawidłowy, użytkownik otrzyma komunikat o błędzie którego nie może pominąć.
3. Nagłówek X-Frame-Options
Nagłówek X-Frame-Options – ma za zadanie maksymalnie ograniczyć możliwość przeprowadzenia ataków typu Clickjacking. Nagłówek ten ogranicza lub blokuje całkowicie zewnętrzne domeny, które mogą umieszczać naszą webaplikację w tagach <object>, <frame> oraz <iframe> .
Nagłówek może przyjąć różne parametry:
- X-Frame-Optoins: Allow-From http://example.com – strona może być umieszczana w ramce tylko na wskazanej domenie;
- X-Frame-Options: SameOrigin – strona może być umieszczana w ramce tylko w obrębie tej samej domeny;
- X-Frame-Options: Deny – strona nie może być umieszczana w ramce.
4. Pliki Cookies
Bezpieczeństwo plików cookies możemy podnieść dodając do nich dwie dodatkowe flagi HttpOnly oraz Secure.
Flaga HttpOnly pozwala uchronić nasze pliki cookies przed skutkami ataków XSS. Plik z flagą HttpOnly jest dostępny tylko dla żądań http, nie jest możliwe odczytanie go np. za pomocą javascriptu.
Najczęściej przy próbie ataku XSS atakujący próbuje pobrać wartość document.cookie dla cieasteczka sesyjnego. Przy włączonej fladze HttpOnly zmienna document.cookie nie zwróci żadnej wartości.
Flaga Secure zabezpiecza pliki cookies przed wysłaniem ich z użyciem protokołu http. Po włączeniu tej flagi pliki cookies są przesyłane tylko z użyciem bezpiecznego protokołu https.
Przykładowe ciasteczko sesyjne z ustawionymi flagami HttpOnly oraz Secure.
Set-Cookie: token=1znpr7zx3m29w4n5zf2d1; HttpOnly; Secure
5. Nagłówek X-Content-Type-Options
Nagłówek X-Content-Type-Options wyłącza zgadywanie przez przeglądarkę typu MIME dokumentu,a jednocześnie pozwala ochronić webaplikację przed atakami polegającymi na dołączaniu plików w innym kontekście niż wskazuje na to ich Content-Type.
Przykład: Webaplikacja pozwala na upload obrazków przez użytkowników. Jednocześnie w wyniku innej podatności (np. XSS) użytkownik może manipulować zawartością webaplikacji. Atakujący może wgrać np. plik jpeg, który w rzeczywistości będzie plikiem js.
Webaplikacja z wyłączonym nagłówkiem X-Content-Type-Options dołączy taki plik i wykona złośliwy kod.
<script src=”http://example.com/uploads/image.jpeg”></script>
Jeżeli użyjemy nagłówka X-Content-Type-Options, takie wykonanie skryptu nie powiedzie się, ponieważ Content-type odpowiedzi będzie równy np. image/png. Przeglądarka pominie załadowanie pliku.
X-Content-Type-Options: nosniff
6. Subresource Integrity (SRI)
SRI to funkcja bezpieczeństwa umożliwiająca przeglądarkom weryfikowanie, czy zasoby, które przechwytują (np. pliki js,css) docierają do nich bez nieporządanych zmian. Działanie takie jest możliwe dzięki używaniu hasha kryptograficznego, z którym przechwycony zasób musi być zgodny.
Potencjalny atakujący chcąc dostać się do naszej dobrze zabezpieczonej webaplikacji może zaatakować serwer dostawcy komponentu z którego korzystamy np. biblioteka jquery.
<script src=”https://code.jquery.com/jquery.js”> </script>
W przypadku udanego ataku na serwer jquery i podmianie pliku jquery.js na inny niebezpieczny plik atakujący może wywołać dowolny kod w kontekście naszej webaplikacji.
Wdrażając zabezpieczenie w postaci hasha, przeglądarka wykryje rozbieżność hasha kryptograficznego pliku z hashem kryptograficznym zdeklarowanym w kodzie i pominie ładowanie pliku.
Przykład prawidłowo dołączonego pliku z zewnętrznego serwera.
<script src=”https://code.jquery.com/jquery-3.5.1.js” integrity=”sha256-QWo7LDvxbWT2tbbQ97B53yJnYU3WhH/C8ycbRAkjPDc=”></script>
„Subresource Integrity” pozwala na ograniczenie ryzyka ataków tego typu poprzez zapewnienie, że pliki które dana aplikacja, bądź dokument WWW przechwytują z zewnętrznego serwera zostały dostarczone bez udziału trzeciej strony, która „wzbogaciła” nasze dane o dodatkową treść.
Jak podnieść poziom bezpieczeństwa aplikacji webowych: podsumowanie
Aplikacje internetowe są obecnie powszechnie stosowane. Dzięki różnym funkcjom, przynoszą one szereg korzyści, które z kolei przekładają się na usprawnienie działalności biznesowej, poprawę produktywności i redukcję kosztów. Natomiast wzrost złożoności aplikacji webowych oraz ich powszechność, stwarzają wyzwania w zakresie zabezpieczenia ich przed zagrożeniami. W efekcie są niestety częstym celem ataków.
Istnieje jednak kilka prostych i skutecznych sposobów, pozwalających poprawić bezpieczeństwo aplikacji internetowych, a tym samym zminimalizowania ryzyka, że Ty, Twoja firma oraz klienci, staniecie się kolejnymi ofiarami cyberprzestępców. Użytkownicy ufają, że ich wrażliwe dane osobowe, które ujawniają na Twojej stronie internetowej, będą przechowywane z należytą dbałością o poufność. Nie zawiedź ich zaufania!
