Bezpieczeństwo aplikacji webowej: podstawy i pytania do wykonawcy

Bezpieczeństwo aplikacji webowej nie wymaga od właściciela firmy znajomości programowania. Wystarczy rozumieć kilka podstaw i wiedzieć, o co zapytać wykonawcę. Większość incydentów w małych i średnich projektach wynika z prostych zaniedbań: słabego logowania, źle sprawdzanych uprawnień, braku aktualizacji i kopii zapasowych. Poniżej opisujemy te podstawy bez żargonu i bez straszenia oraz dajemy listę pytań do omówienia przed startem projektu.

Dlaczego to dotyczy także małych aplikacji

Łatwo założyć, że nikt nie będzie atakować niewielkiego panelu dla klientów. W praktyce większość prób włamań jest zautomatyzowana: programy skanują tysiące stron w poszukiwaniu znanych luk, domyślnych haseł i nieaktualnego oprogramowania. Nie wybierają celów, tylko sprawdzają wszystko po kolei.

Dobra wiadomość: podstawowe, dobrze wdrożone zabezpieczenia chronią przed większością takich prób. Nie potrzebujesz budżetu banku. Potrzebujesz wykonawcy, który traktuje bezpieczeństwo jako część codziennej pracy, a nie dodatek na koniec. Do tego kilku prostych nawyków po stronie Twojego zespołu, o których piszemy niżej. Razem dają solidny poziom ochrony bez przesadnych kosztów.

Logowanie i konta użytkowników

Logowanie to najczęstszy cel ataków, bo przez nie prowadzi droga do danych.

• Hasła przechowywane bezpiecznie. Aplikacja nigdy nie powinna znać haseł w czytelnej postaci. Zapisuje się je w formie, której nie da się odwrócić, przy użyciu sprawdzonych algorytmów.
• Ochrona przed zgadywaniem. Ograniczenie liczby prób logowania i opóźnienia po kolejnych błędach.
• Logowanie dwuetapowe, przynajmniej dla administratorów i pracowników z dostępem do wielu danych.
• Logowanie bez hasła jako alternatywa: jednorazowy link lub kod na maila. Klient nie musi pamiętać hasła, a firma go nie przechowuje.
• Bezpieczny reset dostępu, który nie zdradza, czy dany adres e-mail istnieje w systemie.
• Wygasanie sesji po okresie bezczynności, zwłaszcza w panelach z danymi wrażliwymi.

Gotowe, sprawdzone rozwiązania do logowania są zwykle bezpieczniejsze niż mechanizmy pisane od zera. To dobre pytanie do wykonawcy: z czego korzysta i dlaczego.

Uprawnienia: każdy widzi tylko swoje

Jednym z najczęstszych błędów w aplikacjach jest źle sprawdzane prawo dostępu. Klient zmienia w adresie numer zamówienia z 1045 na 1046 i widzi cudze dane. Albo ukryty przycisk znika z interfejsu, ale funkcja nadal działa dla każdego, kto zna adres.

Zasady, których warto wymagać:

• uprawnienia sprawdzane po stronie serwera przy każdym żądaniu, a nie przez samo ukrywanie elementów w interfejsie,
• zasada najmniejszych uprawnień: każda rola ma dostęp tylko do tego, czego potrzebuje do pracy,
• testy automatyczne uprawnień, które przy każdej zmianie w kodzie sprawdzają, czy klient A nie widzi danych klienta B.

To szczególnie ważne w strefie klienta, gdzie w jednym systemie są dokumenty wielu firm i osób. Szerzej o planowaniu takich paneli piszemy w tekście o panelu klienta na stronie.

Dane: szyfrowanie, minimalizacja, kopie zapasowe

• Szyfrowane połączenie (HTTPS) w całej aplikacji. To dziś standard, ale sam w sobie nie wystarcza.
• Zbieraj tylko potrzebne dane. Czego nie przechowujesz, tego nie da się wykraść. Numery kart płatniczych powinien obsługiwać operator płatności, a nie Twoja aplikacja.
• Pliki prywatne naprawdę prywatne. Dokumenty klientów nie mogą być dostępne pod publicznym adresem, który da się odgadnąć.
• Kopie zapasowe wykonywane automatycznie, przechowywane w innym miejscu niż aplikacja i, co najważniejsze, regularnie sprawdzane przez próbne odtworzenie.
• Sekrety poza kodem. Hasła do bazy i klucze do usług zewnętrznych przechowuje się w zabezpieczonej konfiguracji, a nie w repozytorium.

Przy danych osobowych dochodzą obowiązki wynikające z RODO, na przykład umowy powierzenia z dostawcami usług i rejestr czynności przetwarzania. To nie jest porada prawna; w razie wątpliwości warto skonsultować się z prawnikiem.

Kod, aktualizacje i infrastruktura

Każda aplikacja korzysta z dziesiątek gotowych bibliotek. To dobrze, bo nie trzeba wymyślać koła od nowa. Biblioteki mają jednak czasem luki, które są publicznie opisywane, a potem łatane w nowych wersjach.

Dlatego liczą się:

• regularne aktualizacje bibliotek i środowiska,
• automatyczne powiadomienia o lukach w używanych zależnościach,
• przegląd kodu przez drugą osobę przed wdrożeniem zmian,
• ochrona przed typowymi atakami: wstrzykiwaniem zapytań do bazy, osadzaniem złośliwego skryptu w treściach dodawanych przez użytkowników, fałszowaniem żądań. Lista najczęstszych zagrożeń publikowana przez organizację OWASP to dobry punkt odniesienia dla wykonawcy.

Aplikacja bez aktualizacji z czasem staje się coraz łatwiejszym celem. To główny powód, dla którego opieka techniczna nie jest opcją, tylko częścią kosztu utrzymania. U nas to orientacyjnie 199–699 zł netto miesięcznie. Pełny obraz kosztów opisujemy w tekście o tym, ile kosztuje aplikacja webowa.

Infrastruktura i monitoring

• Hosting z aktualnym oprogramowaniem i rozdzieleniem środowiska testowego od produkcyjnego.
• Monitoring dostępności i błędów, który powiadamia zespół, zanim zgłoszą je klienci.
• Rejestr ważnych zdarzeń: logowania, zmiany uprawnień, eksporty danych. Pozwala ustalić, co się stało, jeśli coś pójdzie nie tak.
• Plan na incydent: kto jest powiadamiany, jak szybko, jak informuje się klientów.

Wybór hostingu ma tu duże znaczenie. Podstawowe kryteria opisujemy w poradniku o tym, jak wybrać domenę i hosting.

Pytania do wykonawcy: lista kontrolna

Przed podpisaniem umowy zadaj te pytania. Dobry wykonawca odpowie na nie konkretnie i bez irytacji.

• Jak przechowujecie hasła i czy jest logowanie dwuetapowe?
• Gdzie i jak sprawdzane są uprawnienia użytkowników?
• Czy uprawnienia są objęte testami automatycznymi?
• Jakie dane będą przechowywane i czy wszystkie są potrzebne?
• Jak często wykonywane są kopie zapasowe, gdzie są przechowywane i kiedy ostatnio testowaliście odtworzenie?
• Jak śledzicie luki w używanych bibliotekach i jak często aktualizujecie?
• Czy kod przechodzi przegląd przed wdrożeniem?
• Jak wygląda monitoring i kto reaguje na awarię?
• Jaki jest czas reakcji na incydent bezpieczeństwa w ramach opieki?
• Czy repozytorium, hosting i konta usług będą na moją firmę?
• Czy przed startem przewidujecie przegląd bezpieczeństwa albo test penetracyjny?

Bezpieczeństwo od pierwszego etapu

Najtaniej zadbać o bezpieczeństwo na początku, przy projektowaniu ról, uprawnień i przepływu danych. Dokładanie zabezpieczeń do gotowej aplikacji jest droższe i bardziej ryzykowne. Nawet przy wersji na start warto zachować podstawy: bezpieczne logowanie, uprawnienia sprawdzane na serwerze, kopie zapasowe i testy najważniejszych ścieżek. O tym, jak zaplanować pierwszą wersję produktu, piszemy w tekście o aplikacji webowej MVP.

Co możesz zrobić po swojej stronie

Część bezpieczeństwa zależy od firmy, a nie od wykonawcy. Kilka nawyków, które wiele zmieniają:

• Osobne konta dla każdego pracownika zamiast jednego wspólnego loginu. Wiadomo wtedy, kto co zrobił, i łatwo odebrać dostęp jednej osobie.
• Odbieranie dostępów od razu po zakończeniu współpracy z pracownikiem lub podwykonawcą.
• Menedżer haseł w zespole i logowanie dwuetapowe do poczty, bo to przez nią resetuje się dostęp do większości usług.
• Ostrożność wobec podejrzanych maili. Wiadomości podszywające się pod bank, kuriera albo dostawcę usług to wciąż jeden z najczęstszych sposobów przejęcia kont.
• Zgłaszanie dziwnych zachowań aplikacji od razu, a nie po tygodniu. Wczesny sygnał pozwala szybciej zareagować.

Podsumowanie

Bezpieczeństwo aplikacji webowej opiera się na kilku podstawach: bezpiecznym logowaniu, uprawnieniach sprawdzanych po stronie serwera, ostrożnym obchodzeniu się z danymi, sprawdzonych kopiach zapasowych i regularnych aktualizacjach. Nie musisz znać się na technice, żeby o to zadbać. Wystarczy zadać wykonawcy właściwe pytania i zapewnić aplikacji opiekę po starcie.

Bezpieczeństwo planujemy od pierwszego prototypu, razem z rolami i uprawnieniami. Zobacz, jak pracujemy przy aplikacjach webowych, jeśli planujesz system, w którym klienci powierzą Ci swoje dane.