Nie. Certyfikat SSL szyfruje połączenie między przeglądarką a serwerem, więc nikt po drodze nie podejrzy danych z formularza ani hasła do panelu. Nie chroni natomiast przed luką we wtyczce, przejętym hasłem ani złośliwym kodem dopisanym do plików. Zainfekowana strona z kłódką w pasku adresu jest dalej zainfekowana.

Mimo to SSL jest obowiązkowy. Przeglądarki oznaczają strony bez HTTPS jako niezabezpieczone, a formularz kontaktowy na takiej stronie zniechęca do wysłania danych. Przy wdrożeniu pilnujemy trzech rzeczy: przekierowania 301 z wersji http na https, braku tak zwanej treści mieszanej (obrazków i skryptów ładowanych jeszcze przez http) oraz automatycznego odnawiania certyfikatu. Wygasły certyfikat potrafi z dnia na dzień zamienić stronę w czerwony ekran ostrzeżenia, dlatego w opiece monitorujemy jego termin ważności razem z terminem domeny.

Poprawki bezpieczeństwa najlepiej instalować w ciągu kilku dni od wydania, a pozostałe aktualizacje co najmniej raz w miesiącu. Po ogłoszeniu luki w popularnej wtyczce automaty zaczynają szukać podatnych stron bardzo szybko, więc strona aktualizowana raz na pół roku jest przez większość tego czasu otwarta.

Automatyczne aktualizacje wszystkiego naraz to jednak ryzyko z drugiej strony: nowa wersja wtyczki potrafi rozsypać układ strony albo zablokować koszyk. Dlatego w opiece aktualizujemy po kopii zapasowej, a po zmianie sprawdzamy stronę główną, formularze, a w sklepie dodanie produktu do koszyka i przejście do płatności. Przy większych sklepach najpierw testujemy aktualizacje na kopii strony.

Osobna sprawa to wersja PHP na serwerze. Wersje bez wsparcia nie dostają poprawek bezpieczeństwa, a starsze wtyczki często blokują przejście na nowszą. Przy audycie sprawdzamy, co trzeba poprawić, żeby strona działała na wspieranej wersji PHP.

WAF, czyli firewall aplikacyjny, filtruje ruch przed tym, jak trafi do WordPressa: blokuje typowe próby wykorzystania luk, podejrzane żądania i masowe logowania z jednego adresu. Może działać jako wtyczka, jako moduł na serwerze albo jako usługa przed serwerem. Ta ostatnia opcja odciąża też hosting przy dużym ruchu botów. WAF nie zastępuje aktualizacji, ale daje czas między ogłoszeniem luki a jej załataniem.

2FA, czyli logowanie dwuskładnikowe, wymaga oprócz hasła kodu z aplikacji w telefonie. Nawet jeśli hasło wycieknie z innego serwisu, samo nie wystarczy do wejścia do panelu. Włączamy je co najmniej dla wszystkich kont z rolą administratora i dla kont z dostępem do zamówień w sklepie. To jedna z tańszych i skuteczniejszych zmian, jakie można zrobić.

Panel hostingu i domena też wymagają ochrony

Zabezpieczenie samego WordPressa nie wystarczy, jeśli konto hostingowe albo panel domeny ma słabe hasło bez 2FA. Kto przejmie hosting, ma dostęp do wszystkich plików i kopii, a kto przejmie domenę, może przekierować stronę i pocztę. Przy przeglądzie sprawdzamy więc, kto ma dostęp do hostingu, domeny, poczty i kont Google, i porządkujemy te dostępy razem z klientem.

Sklep internetowy przechowuje dane klientów, adresy i historię zamówień, więc skutki włamania są poważniejsze niż na wizytówce. Jeden z groźniejszych scenariuszy to skrypt dopisany do strony zamówienia, który kopiuje dane wpisywane przez klientów. Dlatego zalecamy, żeby płatność kartą odbywała się po stronie operatora płatności, a nie w formularzu na serwerze sklepu.

Na WooCommerce zasady są te same co dla WordPressa, ale wtyczek jest zwykle więcej, więc tym ważniejsze są aktualizacje testowane przed wdrożeniem i kopie bazy robione częściej. Na PrestaShop podobną rolę pełnią moduły: nieaktualne lub pobrane z nieoficjalnych źródeł są częstą drogą infekcji. W sklepach abonamentowych, na przykład na Shoperze, o serwer i aktualizacje dba platforma, a po stronie właściciela zostają konta pracowników, 2FA, uprawnienia aplikacji i skrypty wklejane do szablonu.

• płatności kartą obsługiwane przez operatora płatności
• 2FA dla kont z dostępem do zamówień i danych klientów
• kopie bazy danych częściej niż kopie plików
• aktualizacje wtyczek i modułów testowane przed wdrożeniem

Przy sklepie bezpieczeństwo łączy się ze sprzedażą także przez Google. Ostrzeżenie w przeglądarce oznacza dla sklepu dni bez zamówień. Jeśli prowadzimy też SEO sklepu, zobacz pozycjonowanie WooCommerce i pozycjonowanie PrestaShop.

Usuwanie wirusów ze strony to nie tylko skasowanie złośliwego pliku. Czyszczenie obejmuje znalezienie wszystkich miejsc, w których atakujący zostawił kod, zamknięcie luki, przez którą wszedł, i sprawdzenie, czy nie zostawił sobie tylnego wejścia. Jeśli pominie się którykolwiek z tych kroków, infekcja zwykle wraca.

Pracę zaczynamy od kopii obecnego stanu i przeglądu logów. Potem porównujemy pliki rdzenia WordPressa, motywu i wtyczek z oryginalnymi wersjami, a zmienione lub obce pliki usuwamy albo wymieniamy na czyste. Osobno przeglądamy bazę danych, bo złośliwy kod i spam SEO często siedzą w treściach wpisów, opcjach i ustawieniach widżetów, a nie w plikach. Sprawdzamy też pliki konfiguracji serwera, zadania uruchamiane automatycznie i katalog na przesyłane pliki.

Na koniec zamykamy przyczynę: aktualizujemy lub usuwamy dziurawy dodatek, usuwamy obce konta, zmieniamy hasła i klucze w konfiguracji, włączamy 2FA i WAF. Jeśli istnieje czysta kopia sprzed infekcji, czasem szybciej jest odtworzyć z niej stronę i dograć tylko nowsze treści. Decyzję podejmujemy po diagnozie, bo zależy od tego, kiedy zaczęła się infekcja.

• kopia zainfekowanego stanu i analiza logów
• porównanie plików z oryginałami i usunięcie obcego kodu
• przegląd bazy danych pod kątem spamu i skryptów
• zamknięcie luki, nowe hasła, 2FA i WAF
• sprzątanie skutków w Google i wniosek o weryfikację

Bezpieczeństwo strony internetowej najprościej sprawdzić w trzech miejscach: w Search Console (raport problemów z bezpieczeństwem i ręcznych działań), w raporcie przejrzystości Google, który pokazuje status bezpiecznego przeglądania dla domeny, oraz w panelu WordPressa, gdzie widać wersje, aktualizacje i listę użytkowników. To zajmuje kilkanaście minut i wyłapuje najbardziej oczywiste problemy.

Darmowe skanery online sprawdzają to, co widać z zewnątrz: czy strona jest na listach niebezpiecznych witryn, czy ładuje podejrzane skrypty i czy ma aktualny certyfikat. Nie zajrzą jednak do plików na serwerze ani do bazy danych, więc czysty wynik skanera nie oznacza czystej strony. Pełny obraz daje dopiero przegląd od środka.

Co obejmuje audyt bezpieczeństwa strony?

Audyt bezpieczeństwa strony w Backlink24 to przegląd od środka i z zewnątrz, z listą poprawek ułożonych według pilności. Kosztuje od 1 229 zł brutto, a cena zależy od wielkości strony i liczby dodatków. Sprawdzamy w nim między innymi:

• wersje WordPressa, PHP, motywu i wtyczek oraz dodatki porzucone przez autorów
• konta użytkowników, role, 2FA i dostępy do hostingu i domeny
• kopie zapasowe: gdzie są, jak często powstają i czy da się z nich odtworzyć stronę
• HTTPS, certyfikat, przekierowania i nagłówki bezpieczeństwa
• stan strony w Google: problemy z bezpieczeństwem, spam w indeksie, ręczne działania

Audyt robimy wyłącznie na zlecenie właściciela strony i na podstawie dostępów, które od niego dostajemy. Nie testujemy cudzych stron bez zgody. Jeśli przy okazji chcesz sprawdzić stronę pod kątem SEO, zobacz audyt SEO, a sklepy obejmuje audyt SEO sklepu.

Jeśli po włamaniu mogły wyciec dane osobowe klientów, na przykład z formularzy, kont w sklepie albo listy zamówień, administrator danych ma obowiązek zgłosić naruszenie do Prezesa UODO w ciągu 72 godzin od jego stwierdzenia, chyba że jest mało prawdopodobne, by powodowało ono ryzyko dla osób, których dane dotyczą. Przy wysokim ryzyku trzeba też zawiadomić same osoby.

Nie jesteśmy kancelarią i nie udzielamy porad prawnych, ale przy czyszczeniu strony ustalamy fakty, które są do takiej oceny potrzebne: kiedy zaczęło się włamanie, czy atakujący miał dostęp do bazy danych i jakie dane w niej były. Opis przekazujemy klientowi, a decyzję o zgłoszeniu podejmuje on sam lub jego prawnik. Najprostsza ochrona to nie trzymać na stronie danych, których nie potrzebujesz, i regularnie czyścić stare zgłoszenia z formularzy.