Bezpieczeństwo aplikacji — OWASP Top 10 dla nietechnicznych
OWASP Top 10 to lista dziesięciu klas błędów, które najczęściej prowadzą do włamań do aplikacji webowych. Powstaje na podstawie danych z realnych incydentów i jest w praktyce standardem, do którego odwołują się audyty bezpieczeństwa. Ten tekst tłumaczy ją językiem osoby, która podpisuje umowę z wykonawcą, a nie pisze kod.
Krótka odpowiedź: zdecydowana większość realnych włamań do aplikacji firmowych nie wykorzystuje wyrafinowanych technik. Sprowadza się do trzech rzeczy: brakującej kontroli uprawnień, nieaktualnych bibliotek i błędnej konfiguracji serwera.
Jeśli masz zadać wykonawcy tylko trzy pytania, niech brzmią: czy uprawnienia są sprawdzane po stronie serwera przy każdym żądaniu, jak i jak często aktualizujecie zależności oraz co dokładnie trafia do rejestru zdarzeń i kto go czyta.
Dlaczego to nie jest temat wyłącznie techniczny
Wyciek danych z aplikacji firmowej ma konsekwencje, które rozkładają się na kilka lat i kilka obszarów naraz. Bezpośredni koszt techniczny — usunięcie luki, przywrócenie danych, audyt — jest zwykle najmniejszą pozycją. Poważniejsze są obowiązki zgłoszeniowe wobec organu nadzorczego i osób, których dane dotyczą, ryzyko kary administracyjnej oraz utrata zaufania klientów, którzy dowiadują się o incydencie z komunikatu.
Z perspektywy zamawiającego oznacza to jedno: bezpieczeństwo jest pozycją w budżecie projektu, a nie darmowym dodatkiem, który wykonawca zapewnia „przy okazji". Wycena, w której nie ma godzin na testy bezpieczeństwa i przegląd konfiguracji, jest wyceną niepełną.
Dziesięć klas błędów w praktyce
| Kategoria | Co to znaczy w praktyce | Typowy skutek |
|---|---|---|
| Brak kontroli dostępu | Zmiana numeru w adresie pokazuje cudze dane | Wyciek danych wszystkich klientów |
| Błędy kryptograficzne | Hasła i dane wrażliwe zapisane bez właściwej ochrony | Przejęcie kont po wycieku bazy |
| Wstrzyknięcie kodu | Dane z formularza trafiają wprost do zapytania | Odczyt lub skasowanie całej bazy |
| Niebezpieczny projekt | Proces pozwala obejść krok weryfikacji | Zamówienia bez płatności, obejście limitów |
| Błędna konfiguracja | Domyślne hasła, panel administracyjny dostępny publicznie | Przejęcie serwera |
| Nieaktualne komponenty | Biblioteki ze znanymi lukami | Atak zautomatyzowany, bez udziału człowieka |
| Błędy uwierzytelniania | Brak limitu prób logowania, słabe odzyskiwanie hasła | Masowe przejmowanie kont |
| Brak weryfikacji integralności | Aktualizacje i skrypty pobierane bez sprawdzenia | Wprowadzenie złośliwego kodu do aplikacji |
| Brak rejestrowania zdarzeń | Nie wiadomo, kto i kiedy sięgnął po dane | Incydent wykryty po miesiącach |
| Żądania po stronie serwera | Aplikacja pobiera zasób ze wskazanego adresu | Dostęp do zasobów sieci wewnętrznej |
Trzy najczęstsze — omówione szerzej
Brak kontroli dostępu
Najczęstsza i jednocześnie najprostsza do wykorzystania klasa błędów. Scenariusz wygląda tak: użytkownik otwiera swoją fakturę pod adresem zawierającym jej numer, zmienia numer o jeden i widzi fakturę innej firmy. Nie potrzeba do tego żadnych narzędzi — wystarczy przeglądarka.
Przyczyną jest sprawdzanie uprawnień w interfejsie zamiast na serwerze. Ukrycie przycisku nie jest zabezpieczeniem, ponieważ żądanie można wysłać z pominięciem interfejsu. Poprawnie zbudowana aplikacja przy każdym żądaniu weryfikuje, czy zalogowany użytkownik ma prawo do konkretnego rekordu, a nie tylko do funkcji.
Nieaktualne komponenty
Typowa aplikacja webowa korzysta z kilkuset zewnętrznych bibliotek, licząc zależności pośrednie. Gdy w którejś z nich zostaje ujawniona luka, w ciągu kilkudziesięciu godzin pojawiają się automaty skanujące internet w poszukiwaniu podatnych instalacji. Atak nie jest wymierzony w konkretną firmę — trafia w każdego, kto nie zaktualizował.
Obrona jest procesowa, nie techniczna: ktoś musi regularnie sprawdzać listę zależności i wgrywać poprawki. Aplikacja bez umowy utrzymaniowej staje się podatna sama z siebie, bez żadnej zmiany w kodzie.
Błędna konfiguracja
Do tej kategorii należą rzeczy pozornie trywialne: pozostawione konto testowe z domyślnym hasłem, panel administracyjny bazy danych dostępny z internetu, kopia zapasowa w katalogu publicznym, komunikaty błędów pokazujące ścieżki i wersje oprogramowania, brak nagłówków bezpieczeństwa. Każda z osobna wydaje się drobiazgiem, razem tworzą gotową drogę wejścia.
Klasyczny przypadek. Podczas wdrożenia powstaje kopia bazy w katalogu dostępnym przez przeglądarkę — „na chwilę, do migracji". Zostaje tam na dwa lata. Automat indeksujący znajduje ją w kilka dni, bo skanowanie typowych nazw plików jest standardowym elementem rozpoznania. Kosztem jest wyciek pełnej bazy klientów bez jednej linijki kodu ataku.
Co powinien zapewnić wykonawca
- Kontrola uprawnień po stronie serwera przy każdym żądaniu, z domyślną odmową dostępu.
- Zapytania z parametrami zamiast sklejania tekstu z danymi użytkownika.
- Hasła przechowywane przy użyciu współczesnych funkcji przeznaczonych do tego celu.
- Nagłówki bezpieczeństwa, w tym polityka bezpieczeństwa treści ograniczająca źródła skryptów.
- Wymuszone szyfrowane połączenie na wszystkich podstronach, bez wyjątków.
- Ograniczenie liczby prób logowania, odzyskiwania hasła i wysyłki formularzy.
- Weryfikacja typu i rozmiaru plików przesyłanych przez użytkowników oraz ich przechowywanie poza katalogiem publicznym.
- Rejestr zdarzeń obejmujący logowania, zmiany uprawnień i dostęp do danych wrażliwych.
- Kopie zapasowe z przetestowanym odtworzeniem, przechowywane poza serwerem produkcyjnym.
- Rozdzielone środowiska — testowe bez dostępu do danych produkcyjnych.
Pytania do wykonawcy przed podpisaniem umowy
- Jak sprawdzacie uprawnienia — w interfejsie czy na serwerze przy każdym żądaniu?
- Czy w projekcie jest automatyczne skanowanie zależności pod kątem znanych podatności?
- Kto i jak często wgrywa aktualizacje bezpieczeństwa po zakończeniu wdrożenia?
- Jakie zdarzenia trafiają do rejestru i jak długo są przechowywane?
- Czy dane produkcyjne są używane w środowisku testowym?
- Czy przewidujecie testy bezpieczeństwa przed uruchomieniem i czy są w wycenie?
- Jak wygląda procedura na wypadek wykrycia incydentu i kto kogo powiadamia?
Odpowiedź, która powinna zaniepokoić. „Używamy sprawdzonego frameworka, więc jest bezpiecznie." Framework rozwiązuje część problemów — głównie wstrzyknięcia kodu — ale nie ma wpływu na kontrolę uprawnień, konfigurację serwera, jakość rejestru zdarzeń ani na to, czy ktokolwiek wgrywa aktualizacje po odbiorze projektu.
Bezpieczeństwo po wdrożeniu
Stan zabezpieczeń pogarsza się sam z upływem czasu, nawet gdy w kodzie nic się nie zmienia. Publikowane są nowe podatności w używanych bibliotekach, wygasają certyfikaty, przybywa integracji i kont dostępowych. Dlatego bezpieczeństwo trzeba traktować jako proces o stałym koszcie.
- Miesięczny przegląd aktualizacji bibliotek i systemu operacyjnego serwera.
- Kwartalny przegląd kont i uprawnień — usuwanie dostępów osób, które odeszły z projektu.
- Test odtworzenia kopii zapasowej dwa razy w roku; kopia nieprzetestowana nie jest kopią.
- Monitoring nietypowych zachowań — seria nieudanych logowań, masowe pobieranie danych.
- Testy bezpieczeństwa przy większych zmianach funkcjonalnych i raz w roku dla aplikacji krytycznych.
- Aktualizacja procedury reagowania wraz z listą osób do powiadomienia.
Podsumowanie
OWASP Top 10 opisuje nie egzotyczne ataki, lecz powtarzalne zaniedbania. Trzy pozycje odpowiadają za większość realnych incydentów w aplikacjach firmowych: brak kontroli uprawnień po stronie serwera, nieaktualne biblioteki i błędna konfiguracja środowiska.
Dla zamawiającego praktyczny wniosek jest prosty. Warto zapisać w umowie, że uprawnienia weryfikowane są na serwerze, że projekt obejmuje testy bezpieczeństwa przed uruchomieniem i że po odbiorze ktoś konkretny odpowiada za aktualizacje. Te trzy zapisy usuwają większość ryzyka za ułamek kosztu obsługi incydentu.
Najczęstsze pytania
Większość ataków nie jest wymierzona w konkretną firmę. To automaty, które skanują internet w poszukiwaniu znanych podatności i uderzają we wszystko, co pasuje do wzorca. Wielkość firmy nie chroni — decyduje wyłącznie to, czy aplikacja ma nieaktualne komponenty lub błędną konfigurację.
Podstawowy przegląd wraz z automatycznym skanowaniem i weryfikacją konfiguracji to zwykle 5 000 – 15 000 zł. Pełny test penetracyjny prowadzony przez zewnętrzny zespół, z ręczną analizą logiki biznesowej, zaczyna się od kilkunastu tysięcy i rośnie wraz ze złożonością aplikacji. Dla systemów przetwarzających dane osobowe to koszt nieporównywalnie niższy niż obsługa incydentu.
Nie. Framework ogranicza część klas błędów, przede wszystkim wstrzyknięcia kodu i podstawowe ataki na formularze. Nie ma natomiast wpływu na kontrolę uprawnień do konkretnych rekordów, konfigurację serwera, jakość rejestru zdarzeń ani na to, czy ktoś wgrywa aktualizacje po zakończeniu projektu.
Przeglądu warto dokonywać co miesiąc, a poprawki oznaczone jako krytyczne wgrywać niezwłocznie po ich publikacji. Od ujawnienia luki do pojawienia się automatów ją wykorzystujących mijają zwykle godziny lub dni, więc kwartalny rytm aktualizacji jest w praktyce zbyt wolny.
Zabezpieczyć dowody, czyli kopie rejestrów zdarzeń, zanim cokolwiek zostanie nadpisane. Następnie odciąć dostęp, unieważnić wszystkie sesje i klucze oraz ustalić zakres wycieku. Jeśli obejmuje dane osobowe, uruchamiają się obowiązki zgłoszeniowe z krótkim terminem, więc równolegle należy powiadomić osobę odpowiedzialną za ochronę danych w firmie.
Bezpłatna wycena Twojego projektu
Opisz w kilku zdaniach, co chcesz zbudować — stronę, aplikację czy sklep. Odpowiadamy w ciągu 24 godzin roboczych konkretną propozycją zakresu i harmonogramu. Konsultacja i wycena są bezpłatne, bez zobowiązań.