Poziom bezpieczeństwa stron: co pokazało 884 kontroli Smart Audit

Strona, która się otwiera, nie musi jeszcze być bezpieczna. Właściciel widzi stronę główną, formularz zamówienia i katalog — i uznaje, że wszystko jest w porządku. Ale część tego, co dzieje się ze stroną, widać tylko z zewnątrz, oczami osoby, która ją sprawdza.

Uruchomiliśmy usługę Smart Audit, która patrzy na cudze strony właśnie w ten sposób: pasywnie, wyłącznie na strony publiczne. Niczego nie zmienia, nie odgaduje haseł i nie wchodzi do środka. W chwili przygotowania tego artykułu mieliśmy wyniki 884 unikalnych stron firm — dla każdej brana jest ostatnia udana kontrola. Nie wybieraliśmy stron „udanych” ani „nieudanych”: w próbie są i sklepy internetowe, i strony firmowe, i media, i strony dużych organizacji. Nazw nie podajemy — interesuje nas obraz całości, a nie konkretne adresy.

Poniżej — co zobaczyliśmy, czym to grozi właścicielowi i od czego zacząć poprawki.

Obraz ogólny: 22 punkty na 100

Średnia ocena ogólna dla wszystkich 884 stron to 22 na 100. Osobno według obszarów: bezpieczeństwo — 19, szybkość — 18, widoczność w wyszukiwarkach — 17.

• 480 stron (54%) uzyskało poniżej 20 punktów na 100;
• 286 (32%) — od 20 do 39;
• 96 (11%) — od 40 do 59;
• tylko 22 strony (2,5%) doszły do 60 i więcej.

Jeśli spojrzeć wyłącznie na ocenę bezpieczeństwa, obraz wygląda tak: u 466 stron (53%) jest ona niższa niż 10 punktów, u 652 (74%) — niższa niż 30, a tylko 75 stron (8,5%) uzyskało 60 i więcej.

Od razu zastrzeżenie, żeby liczb nie odczytać błędnie. „22 na 100” nie oznacza, że strona jest zabezpieczona w 22%, a tym bardziej że została zhakowana. To odległość od podstawowego zestawu kontroli: czy strona włącza zabezpieczenia, które od dawna uchodzą za normę. Większość punktów przepada na rzeczach, które poprawia się szybko i tanio. Właśnie dlatego warto się przy tych liczbach zatrzymać.

Pierwsza warstwa: drzwi bez zasuw

Każdej stronie, którą serwer przekazuje przeglądarce, towarzyszą techniczne „instrukcje”: co tej stronie wolno, a czego nie. To tak zwane nagłówki bezpieczeństwa. Nie czynią strony nie do przebicia, ale łagodzą skutki ataku, gdy znajdzie się inna luka. I tutaj braki są niemal totalne:

• Polityki bezpieczeństwa treści (CSP) brakuje na 90% stron. Określa ona, jakie skrypty przeglądarka może wykonywać na stronie. Bez niej każdy podrzucony kod działa na równi z „własnym”. Tak właśnie na stronach finalizacji zamówienia pojawiają się skimery — skrypty, które niepostrzeżenie kopiują dane kart płatniczych. Dla sklepu (a w próbie jest ich 130) to najdroższa brakująca „zasuwa”.
• Polityki uprawnień (Permissions-Policy) nie ma na 93% stron. Ogranicza ona, o co wbudowane na stronie widżety mogą prosić odwiedzającego: o dostęp do kamery, mikrofonu, geolokalizacji.
• Polityki przekazywania adresu (Referrer-Policy) nie ma na 88% stron. Bez niej pełne adresy Państwa stron — razem z wewnętrznymi numerami zamówień czy tokenami w linkach — trafiają do zewnętrznych liczników i usług reklamowych.
• Ochrony przed osadzaniem w cudzych ramkach brakuje na 73% stron. Atakujący może wyświetlić Państwa stronę w przezroczystej ramce na swojej stronie i skłonić człowieka do kliknięcia „przycisku”, który w rzeczywistości znajduje się na Państwa stronie. Ta technika nazywa się clickjacking.
• Zakazu „zgadywania” typu pliku brakuje na 71% stron (nosniff).
• HSTS nie jest włączony na 62% stron. Bez niego pierwsza wizyta użytkownika może odbyć się niezaszyfrowanym kanałem — a w publicznej sieci Wi-Fi to okazja do podmiany strony.

Uczciwie: brak nagłówka to nie zhakowana strona. To brakujący poziom ochrony. Ale poprawia się go kilkoma linijkami w ustawieniach serwera, więc ich brak niemal zawsze świadczy o jednym — do ustawień bezpieczeństwa nikt nie dotarł.

Druga warstwa: to, co leży na widoku

Ta część jest poważniejsza. Na 172 stronach z 884 (19%) — czyli prawie co piątej — z zewnątrz dostępne są adresy serwisowe, które nigdy nie powinny być publiczne. Niektóre strony mają kilka takich miejsc jednocześnie. Podział według typów:

• Lista kont użytkowników WordPress — 103 strony (12%). Standardowy adres zwraca loginy użytkowników, w tym administratorów. Połowa pracy atakującego jest już wykonana: login jest znany, zostaje tylko odgadnąć hasło.
• Katalog serwisowy Git — 45 stron (5%). Można z niego odtworzyć kod źródłowy strony, a w historii zmian zdarzają się hasła i klucze, które kiedyś „tymczasowo” wpisano w kod.
• Strona phpinfo — 43 strony (5%). Pokazuje wersje PHP, moduły, ścieżki na serwerze, zmienne środowiskowe. Dla atakującego to gotowa mapa terenu.
• Serwisowa strona stanu serwera — 34 strony (4%). Widać, jakie adresy otwierają w danej chwili odwiedzający i z jakich adresów IP.
• Plik ustawień .env — 33 strony (4%). W takim pliku zwykle leżą hasła do bazy danych, klucze do poczty i usług płatniczych.
• Kopia bazy danych — 28 stron (3%). Plik, który ktoś zostawił w katalogu głównym strony „na chwilę”: klienci, zamówienia, telefony, adresy.

Ważne, by rozumieć, że nie trzeba tu niczego łamać. Wystarczy otworzyć adres w przeglądarce. Smart Audit nie zagląda do zawartości tych plików: jedynie odnotowuje, że pod danym adresem coś odpowiada, a zawartość nie jest ani odczytywana, ani przechowywana. Ale to, czego nie robimy my, może zrobić każdy inny — a automatyczne skanery przeglądają takie adresy całą dobę w całym internecie.

Trzecia warstwa: przestarzałe oprogramowanie

Wśród sprawdzonych stron najwięcej działa na WordPress — 222 (25%), dalej na OpenCart — 88 (10%). Dla pozostałych platforma nie została rozpoznana albo strona jest napisana „na zamówienie”.

154 strony (17%) same ujawniają, jaką mają wersję systemu. Widać to w znacznikach serwisowych na stronie. Same w sobie nie szkodzą — szkodzi ich połączenie ze starą wersją. Wśród stron, które ujawniły wersję WordPress, 22 działają na gałęziach 4 i 5, wydanych wiele lat temu. W przypadku takich wersji nie warto liczyć na to, że ktoś załata nowe podatności.

Osobny temat to wersja samego serwera. U 247 stron (28%) nagłówki odpowiedzi podają dokładne wersje oprogramowania serwerowego. Atakujący nie musi zgadywać: widzi wersję i od razu sięga po znany dla niej sposób ataku. Jak bardzo jest to istotne, widać na przykładzie krytycznych podatności PHP: jedyną ochroną jest tam terminowa aktualizacja. A o drugiej stronie medalu — co się dzieje, gdy aktualizacja odbywa się bez przygotowania — pisaliśmy w analizie automatycznej aktualizacji wtyczki.

Czwarta warstwa: formularze i połączenia — miejsce, przez które do strony trafiają dane klientów

To właśnie przez formularze człowiek przekazuje Państwu imię, telefon, adres, czasem płatność. Dlatego sposób, w jaki są zbudowane, ma największe znaczenie. Co znaleźliśmy:

• 489 stron (55%) — formularze bez ochrony przed podrobieniem żądania (CSRF). Chodzi o sytuację, w której obca strona może zmusić przeglądarkę Państwa odwiedzającego albo administratora do wysłania formularza w jego imieniu, bez pytania go o zgodę.
• 543 (61%) — formularze zbierające dane osobowe bez zgody na ich przetwarzanie. To nie tylko kwestia bezpieczeństwa: to także kwestia przestrzegania przepisów o danych osobowych.
• 532 (60%) — formularze bez ochrony przed botami. Skutek znany każdemu, kto widział skrzynkę zapchaną spamem w postaci „zgłoszeń”.
• 76 stron (9%) — formularze przekazują dane osobowe w adresie strony (metoda GET). Telefon i imię zostają w historii przeglądarki, w logach serwera i razem z adresem trafiają do usług zewnętrznych.
• 321 (36%) — pliki cookie bez znaczników ochronnych. Łatwiej je przechwycić lub odczytać skryptem.

I kilka podstawowych rzeczy, które, zdawałoby się, od dawna powinny być wszędzie: 35 stron (4%) otwiera się w ogóle bez szyfrowania (przeglądarka pokazuje na nich ostrzeżenie „Niezabezpieczona”), u 43 certyfikat wkrótce wygasa, a na 36 stronach część zawartości zabezpieczonej strony jest doładowywana niezabezpieczonym kanałem — przez co szyfrowanie nie działa w pełni.

Czym to grozi właścicielowi

Jeśli odrzucić żargon, ryzyk dla biznesu jest tylko kilka.

1. Wyciek danych klientów. Otwarta kopia bazy czy plik ustawień to nie „techniczny drobiazg”, lecz możliwość zabrania listy Państwa klientów bez niczego włamywania się. Dalej — straty wizerunkowe i odpowiedzialność za ochronę danych osobowych.
2. Obcy kod na Państwa stronie. Aktualizacje, których nie zdążono zainstalować, plus brak CSP — i na stronach pojawia się reklama kasyn, przekierowania na zewnętrzne strony albo skimer na stronie płatności. O tym można dowiedzieć się od klienta, a nie od siebie.
3. Oznaczenie „niebezpieczna strona” i spadek w wynikach wyszukiwania. Przeglądarki i wyszukiwarki nie ryzykują bezpieczeństwa odwiedzających. Zhakowana strona może spaść w wynikach na całe tygodnie, a powrót zajmie dłużej, niż zajęła utrata pozycji.
4. Przestój i koszt odtworzenia. Odtworzenie po włamaniu zwykle kosztuje wielokrotnie więcej, niż kosztowałaby profilaktyka. A dopóki strona nie działa — nie ma zamówień.
5. Utrata zaufania partnerów. Coraz częściej więksi klienci i przetargi proszą o wykazanie, jak wygląda sprawa bezpieczeństwa. Odpowiedź „nie wiemy” punktów nie dodaje.

Od czego zacząć: kolejność, która działa

1. Zamknąć otwarte pliki serwisowe. To najdroższe luki, a poprawia się je najszybciej: zwykle wystarcza godzina pracy. Pliki z hasłami — usunąć z dostępu, a same hasła po tym zmienić, bo nie wolno zakładać, że nie wyciekły.
2. Zaktualizować system i wtyczki oraz usunąć z odpowiedzi serwera dokładne wersje. Aktualizować — na kopii strony, a nie na oślep na działającej.
3. Dodać nagłówki bezpieczeństwa. Zacząć od HSTS, ochrony przed osadzaniem, nosniff i Referrer-Policy — prawie nigdy niczego nie psują. CSP wprowadzać stopniowo, najpierw w trybie obserwacji.
4. Uporządkować HTTPS: automatyczne odnawianie certyfikatu, przekierowanie z http, brak niezabezpieczonej zawartości.
5. Sprawdzić formularze: token chroniący przed podrobieniem żądania, ochrona przed botami, przesyłanie wyłącznie metodą POST, zrozumiała zgoda na przetwarzanie danych.
6. Skonfigurować kopie zapasowe poza stroną i monitoring. Kopia, która leży obok strony, w razie włamania znika razem z nią. A dostępność strony powinien sprawdzać nie klient.

Jak pomagamy

Smart Audit odpowiada na pytanie „co dokładnie jest nie tak” językiem priorytetów: raport dzieli ustalenia na te, które widać od razu, i te, które wynikają z samej platformy strony. Pierwsze zamykamy na Państwa obecnej stronie. Drugie — stare wersje, ograniczenia systemu, niemożność normalnego skonfigurowania ochrony — zwykle rozwiązuje się przeprowadzką na nasz system Smart CMS, w którego fundamencie są już wbudowane nagłówki bezpieczeństwa, ochrona formularzy i aktualizacje. Przeprowadzkę wykonujemy sami: przenosimy strony i adresy, zachowujemy ustawienia widoczności w wyszukiwarkach i pomagamy na każdym etapie, żeby nie stracili Państwo ani ruchu, ani zamówień.

Od czegokolwiek Państwo zaczną, najpierw warto zobaczyć własny obraz sytuacji.

---

Swoją stronę można sprawdzić bezpłatnie, bez rejestracji, w trzy minuty — na audit.sgt.com.ua. A jeśli chcą Państwo, byśmy obejrzeli wynik razem z Państwem i powiedzieli wprost, co poprawić w pierwszej kolejności — prosimy o kontakt.