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.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

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

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.

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?

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.