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

Strona, która się otwiera, wcale nie musi być zabezpieczona. Właściciel widzi stronę główną, formularz zamówienia i katalog — i wnioskuje, ż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 właśnie tak patrzy na cudze strony: 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 „udanych” ani „nieudanych”: w próbie są i sklepy internetowe, i strony korporacyjne, 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ąć naprawę.

Obraz ogólny: 22 punkty na 100

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

• 480 stron (54%) uzyskało mniej niż 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 chodzi o samą ocenę bezpieczeństwa, obraz jest taki: 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 włamana. To odległość od podstawowego zestawu kontroli: czy strona włącza zabezpieczenia, które od dawna uchodzą za normę. Większość punktów ginie na rzeczach, które naprawia 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 wysyła przeglądarce, towarzyszą służbowe „instrukcje”: co tej stronie wolno, a czego nie. To tak zwane nagłówki zabezpieczające. Nie czynią strony nie do sforsowania, ale łagodzą skutki ataku, gdy znajdzie się inna luka. I tutaj braki są niemal powszechne:

• 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”. Właśnie tak 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 u 93%. Ogranicza ona, o co osadzone na stronie widżety mogą prosić odwiedzającego: kamerę, mikrofon, geolokalizację.
• Polityki przekazywania adresu (Referrer-Policy) nie ma u 88%. 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 nie ma u 73%. Napastnik 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ę clickjackingiem.
• Zakazu „zgadywania” typu pliku nie ma u 71% (nosniff).
• HSTS nie jest włączony u 62%. Bez niego pierwsza wizyta może przebiec niezaszyfrowanym kanałem — a w publicznej sieci Wi-Fi to szansa na podmianę strony.

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

Druga warstwa: to, co leży na widoku

Ta część jest poważniejsza. U 172 stron z 884 (19%) — niemal co piątej — z zewnątrz dostępne są adresy serwisowe, które nigdy nie powinny być publiczne. Niektóre strony mają po 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 napastnika jest wykonana: login jest znany, zostaje dobrać hasło.
• Katalog serwisowy Git — 45 stron (5%). Można z niego odtworzyć kod źródłowy strony, a w historii zmian bywają 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 aktualnie otwierają odwiedzający i z jakich 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 chwilkę”: klienci, zamówienia, telefony, adresy.

Ważne, by rozumieć, że nic tu nie trzeba włamywać. 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 zapisywana. 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 jest na WordPress — 222 (25%), dalej OpenCart — 88 (10%). Dla reszty 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 połączenie ze starą wersją. Spośród tych, które ujawniły wersję WordPress, 22 strony działają na gałęziach 4 i 5, wydanych wiele lat temu. W przypadku takich wersji nie warto liczyć, że ktoś zamknie nowe podatności.

Osobna kwestia — 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 znaną dla niej metodę. Jak to istotne, widać na przykładzie krytycznych podatności PHP: tam jedyną ochroną jest 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, którędy 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 ich zbudowania ma największe znaczenie. Co znaleziono:

• 489 stron (55%) — formularze bez ochrony przed podrobieniem żądania (CSRF). To sytuacja, w której cudza strona może zmusić przeglądarkę Państwa odwiedzającego lub administratora do wysłania formularza w jego imieniu, bez pytania go o zdanie.
• 543 (61%) — formularze, które zbierają 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 z „zgłoszeń”.
• 76 stron (9%) — formularze przekazują dane osobowe w adresie strony (metoda GET). Telefon i imię zostają w historii przeglądarki, w dziennikach serwera i razem z adresem trafiają do usług zewnętrznych.
• 321 (36%) — pliki cookie bez znaczników zabezpieczających. Łatwiej je przechwycić lub odczytać skryptem.

I kilka podstaw, 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 ładuje się niezabezpieczonym kanałem — przez to 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. Dalej — straty wizerunkowe i odpowiedzialność za ochronę danych osobowych.
2. Cudzy kod na Państwa stronie. Aktualizacje, których nie zdążono zainstalować, plus brak CSP — i na stronach pojawia się reklama kasyn, przekierowania na obce strony albo skimer na stronie płatności. Mogą Państwo dowiedzieć się o tym od klienta, a nie z własnych źródeł.
3. Oznaczenie „niebezpieczna strona” i spadek w wyszukiwarce. Przeglądarki i wyszukiwarki nie ryzykują odwiedzającymi. Włamana strona może spaść w wynikach na całe tygodnie, a powrót zajmie więcej czasu, niż trwała jej utrata.
4. Przestój i koszt odtworzenia. Odtworzenie po włamaniu zwykle kosztuje wielokrotnie więcej, niż potrzeba by na profilaktykę. A dopóki strona leży — nie ma zamówień.
5. Utrata zaufania partnerów. Coraz częściej więksi klienci i przetargi proszą o pokazanie, jak wygląda u Państwa bezpieczeństwo. Odpowiedź „nie wiemy” nie dodaje punktów.

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

1. Zamknąć otwarte pliki serwisowe. To najdroższe luki, a naprawia 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 ślepo na produkcyjnej.
3. Dodać nagłówki ochronne. 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 niezabezpieczonych treści.
5. Sprawdzić formularze: token przeciw fałszowaniu żądań, ochrona przed botami, przesyłanie wyłącznie metodą POST, czytelna zgoda na przetwarzanie danych.
6. Skonfigurować kopie poza serwerem strony i monitoring. Kopia leżąca obok strony przy włamaniu znika razem z nią. A dostępności strony nie powinien sprawdzać klient.

Jak pomagamy

Smart Audit odpowiada na pytanie „co dokładnie jest nie tak” językiem priorytetów: raport dzieli ustalenia na te widoczne od razu i te wpisane w samą platformę strony. Pierwsze zamykamy na Państwa obecnej stronie. Drugie — stare wersje, ograniczenia systemu, brak możliwości prawidłowej konfiguracji ochrony — zwykle rozwiązuje przeprowadzka na nasz system Smart CMS, w którego fundamencie są już wbudowane nagłówki ochronne, zabezpieczenie 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 zdecydują się Państwo zacząć, 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, żebyśmy spojrzeli na wynik razem z Państwem i powiedzieli wprost, co poprawiać w pierwszej kolejności — proszę napisać do nas.