| Nazwa wtyczki | WP Store Locator |
|---|---|
| Rodzaj podatności | XSS |
| Numer CVE | CVE-2026-3361 |
| Pilność | Niski |
| Data publikacji CVE | 2026-04-23 |
| Adres URL źródła | CVE-2026-3361 |
WP Store Locator (<= 2.2.261) Przechowywane XSS — Co właściciele stron WordPress powinni wiedzieć i jak WP‑Firewall Cię chroni
Opublikowany: 23 kwietnia 2026
CVE: CVE-2026-3361
Powaga: Niski (Patchstack CVSS 6.5)
Dotyczy wersji: WP Store Locator ≤ 2.2.261
Poprawione w: 2.3.0
Jako zespół ds. bezpieczeństwa WordPress wspierający tysiące stron, widzimy ten sam wzór w kółko: pozornie mały błąd wtyczki, w połączeniu z standardowymi rolami i przepływami pracy WordPress, otwiera okno dla atakującego, aby wstrzyknąć złośliwą treść, która później może wpłynąć na administratorów lub użytkowników z wysokimi uprawnieniami. Niedawno ujawniona podatność na przechowywane Cross-Site Scripting (XSS) w wtyczce WP Store Locator (CVE-2026-3361) jest przykładem wartym omówienia, ponieważ podkreśla dwie praktyczne rzeczywistości:
- Wtyczki, które akceptują i przechowują meta dane postów, mogą wprowadzać przechowywane XSS, jeśli nie walidują i nie filtrują poprawnie danych wejściowych użytkownika.
- Nawet role nie-administracyjne, takie jak Współautor, mogą być wykorzystywane w środowiskach wieloużytkownikowych do wprowadzania ładunków, które później wykonują się, gdy administrator lub zaufany użytkownik przegląda określone strony.
Ten artykuł analizuje ryzyko, wyjaśnia, jak działa podatność na wysokim poziomie (bez udostępniania kodu eksploatacyjnego) i przedstawia priorytetowy, praktyczny plan naprawy i łagodzenia — w tym natychmiastowe kroki WAF i wirtualnego łatania, na których klienci WP‑Firewall mogą polegać już dziś.
Streszczenie wykonawcze (krótkie)
- Co się stało: Wtyczka WP Store Locator akceptowała i przechowywała treści HTML/skryptów w
wpsl_addressmeta danych postów bez odpowiedniej sanitizacji/filtracji. Użytkownik na poziomie współautora mógł dodać złośliwą treść, która zostaje przechowana i później wykonuje się w kontekście użytkownika z uprawnieniami, który przegląda przechowane dane. - Uderzenie: Przechowywane XSS może prowadzić do kradzieży sesji, przejęcia konta, działań wykonywanych w kontekście administratora lub dostarczania dalszych ładunków (złośliwe oprogramowanie, przekierowania). W tym przypadku Patchstack ocenił to jako priorytet “niski”, ponieważ wykorzystanie wymaga interakcji użytkownika z uprawnieniami z treścią, ale ryzyko istnieje w środowiskach wieloużytkownikowych, redakcyjnych.
- Natychmiastowe działanie: Zaktualizuj WP Store Locator do wersji 2.3.0 lub nowszej. Jeśli aktualizacja nie jest możliwa od razu, zastosuj zasady WAF / wirtualne łatanie opisane poniżej i przeprowadź kontrole bazy danych w poszukiwaniu podejrzanych
wpsl_addresswartości meta. - Długoterminowo: Wzmocnij role/uprawnienia użytkowników, ogranicz, kto może przesyłać dane sklepu, przeprowadzaj regularne skany, utrzymuj model minimalnych uprawnień i stosuj wirtualne łatanie dla ochrony przed zero-day.
Zrozumienie podatności na bezpiecznym poziomie
Przechowywane XSS występuje, gdy aplikacja przechowuje treści dostarczone przez użytkownika i później renderuje je na stronie internetowej bez odpowiedniego filtrowania lub uciekania w kontekście, w którym się pojawiają (treść HTML, atrybut, kontekst JavaScript itp.). Podatność WP Store Locator dotyczy wpsl_address meta danych postów — pola używanego do przechowywania treści adresowych dla lokalizacji.
Mechanika na wysokim poziomie (bezpieczne, nieeksploatowalne wyjaśnienie):
- Użytkownik z uprawnieniami Współtwórcy może tworzyć lub edytować wpis lokalizacji i ustawiać
wpsl_addresswartość meta. - Wtyczka przechowuje podaną wartość w bazie danych bez wystarczającego oczyszczenia, a następnie renderuje tę wartość na stronach przeglądanych przez użytkowników z wyższymi uprawnieniami (np. autorów, redaktorów, administratorów) lub na niektórych ekranach administracyjnych.
- Gdy użytkownik z uprawnieniami przegląda tę stronę, przeglądarka wykonuje wszelkie wstrzyknięte skrypty w kontekście tej witryny, dając ładunkowi dostęp do ciasteczek, tokenów lub możliwości wykonywania działań, do których ten użytkownik jest uprawniony.
Dlaczego to jest ważne:
- Współtwórcy często występują na stronach redakcyjnych, sieciach franczyzowych lub lokalnych sieciach biznesowych, blogach wieloautorskich lub stronach klientów, gdzie zewnętrzne strony dodają dane lokalizacyjne.
- Wrażliwość wymaga konta współtwórcy do wprowadzenia ładunku, ale następnie polega na użytkowniku z uprawnieniami, aby go wykonać. Na wielu rzeczywistych stronach administratorzy przeglądają treści przesyłane przez współtwórców w interfejsie administracyjnym lub na stronach podglądu — to wystarczy do eksploatacji.
Realistyczne scenariusze eksploatacji
Aby pomóc Ci w priorytetyzacji, oto realistyczne scenariusze, które mógłby próbować atakujący:
- Scenariusz 1 — Kradzież sesji administratora: Złośliwy współtwórca wstrzykuje skrypt, który wysyła ciasteczka/tokeny do atakującego, gdy administrator otwiera stronę edycji tej lokalizacji.
- Scenariusz 2 — Dodanie działań na poziomie administratora: Ładunek wywołuje żądanie z danymi uwierzytelniającymi administratora do utworzenia nowego użytkownika administratora, zmiany ustawień lub zainstalowania wtyczki z tylnym wejściem.
- Scenariusz 3 — Phishing/przekierowania: Przechowywany skrypt przekierowuje administratorów na stronę zbierającą dane uwierzytelniające lub wyświetla przekonujący komunikat o ponowne wprowadzenie danych uwierzytelniających lub kodów MFA.
- Scenariusz 4 — Wpływ na łańcuch dostaw: Atakujący wykorzystuje przechowywane XSS jako przyczółek, a następnie wprowadza trwałe złośliwe oprogramowanie, które wpływa na odwiedzających lub integruje się z innymi wtyczkami/motywami.
Ponieważ eksploatacja wymaga, aby użytkownik z uprawnieniami uruchomił przechowywany ładunek, praktyczny wpływ w dużej mierze zależy od przepływów pracy na stronie. Na stronach z jednym użytkownikiem, gdzie tylko właściciel jest administratorem, a współtwórcy nie są obecni, ryzyko jest mniejsze. Na stronach wieloautorskich, agencjach, stronach franczyzowych lub stronach, które pozwalają na zewnętrzne zgłoszenia lokalizacji, ryzyko staje się znaczące.
Natychmiastowe kroki dla właścicieli stron i administratorów
- Zaktualizuj wtyczkę teraz:
- Zaktualizuj WP Store Locator do wersji 2.3.0 lub nowszej przez pulpit WordPressa lub za pomocą normalnego procesu wdrażania wtyczek. To jest najważniejsza akcja.
- Jeśli nie możesz zaktualizować natychmiast, zastosuj tymczasowe środki zaradcze (poniżej) — w tym zasady WAF / wirtualne poprawki i inspekcja bazy danych.
- Audytuj ostatnie zmiany:
- Szukaj nowych lub zmodyfikowanych lokalizacji i postów z
wpsl_addresswartości meta. - Sprawdź dzienniki aktywności administratorów: kto dodał/edytował wpisy w sklepie i kiedy.
- Zweryfikuj, czy nie ma nieoczekiwanych administratorów lub wtyczek.
- Szukaj nowych lub zmodyfikowanych lokalizacji i postów z
- Zmień dane uwierzytelniające:
- Jeśli podejrzewasz jakąkolwiek podejrzaną treść lub nieoczekiwane zachowanie, zmień hasła administratorów i unieważnij aktywne sesje (poprzez “Wyloguj się wszędzie” lub resetując sól).
- Skanuj swoją stronę:
- Użyj zaufanego skanera złośliwego oprogramowania i narzędzia do sprawdzania integralności plików, aby wyszukać webshells lub zmodyfikowane pliki. (Klienci WP‑Firewall mogą korzystać z naszego skanera złośliwego oprogramowania i funkcji łagodzenia.)
- Wzmocnij uprawnienia współpracowników:
- Ogranicz, którzy użytkownicy mają dostęp współpracownika, lub tymczasowo zmień uprawnienia, jeśli spodziewasz się nadchodzącej treści od nieufnych użytkowników.
Jak bezpiecznie wyszukiwać podejrzane wartości meta
Jeśli masz dostęp do bazy danych lub WP‑CLI, możesz wyszukiwać podejrzane wpisy bez ich wykonywania. Poniższe zapytanie SQL (przykład) szuka skryptów w wpsl_address wartościach meta:
Notatka: Zawsze najpierw wykonuj zapytania do bazy danych w bezpieczny, tylko do odczytu sposób. Wykonaj kopię zapasową bazy danych przed wprowadzeniem zmian.
SQL (sprawdzenie tylko do odczytu):
SELECT post_id, meta_id, meta_value;
Przykład WP‑CLI (bezpieczny wynik):
# Lista identyfikatorów postów z podejrzanymi wartościami meta"
Jeśli te zapytania zwracają wyniki, zbadaj powiązane identyfikatory postów i autorów. Nie otwieraj tych stron w przeglądarce w sesji administratora; zamiast tego sprawdź wartości za pomocą CLI lub przeglądarki bazy danych.
Aby bezpiecznie usunąć podejrzaną treść:
- Zastąp tagi lub usuń podejrzany HTML w polu meta_value za pomocą aktualizacji SQL lub poleceń WP‑CLI po wykonaniu kopii zapasowej.
Przykład (najpierw wykonaj pełną kopię zapasową bazy danych):
UPDATE wp_postmeta;
(Używaj aktualizacji celowanych tylko wtedy, gdy w pełni rozumiesz konsekwencje — kopie zapasowe bazy danych są obowiązkowe.)
Natychmiastowe zalecenia dotyczące WAF / wirtualnych poprawek (co robi WP‑Firewall)
Jeśli korzystasz z zarządzanego WAF, takiego jak WP‑Firewall, zyskujesz czas i ochronę podczas aktualizacji wtyczki. Nasz zalecany zestaw reguł dla tej podatności (dotyczy wielu przypadków przechowywanego XSS w metadanych postów) obejmuje:
- Blokuj lub sanitizuj przychodzące żądania POST, które zawierają
wpsl_addresstypowe wzorce XSS, takie jak<script,onerror=,JavaScript:, lub atrybuty obsługi zdarzeń. - Blokuj żądania z nowych/anonimowych adresów IP próbujących tworzyć posty lokalizacyjne w szybkim tempie.
- Ogranicz rolę współtwórcy w tworzeniu postów związanych z lokalizacją.
- Wprowadź regułę kontroli żądań wychodzących, aby zablokować nieoczekiwane żądania wychodzące na poziomie administratora wywoływane przez interfejsy tylko dla administratorów (chroni przed automatycznym wykradaniem danych).
- Dodaj wirtualną poprawkę: jeśli
wpsl_addresszawiera<znaki są śledzone przez niedozwolony podzbiór tagów, reguła albo usuwa, albo odrzuca żądanie przed dotarciem do PHP.
Przykład bezpiecznego wzorca WAF (ilustracyjny, nie do kopiowania i wklejania dla wszystkich systemów):
- Jeśli POST[meta][wpsl_address] pasuje do regex
(?i)<\s*skrypt\b|on\w+\s*=wtedy zablokuj lub oczyść. - Jeśli POST zawiera
JavaScript:Lubdata:text/htmlbloki, traktuj jako wysokie ryzyko.
Dlaczego wirtualne łatanie ma znaczenie:
- Chroni użytkowników, gdy aktualizacja wtyczki jest zaplanowana lub jeśli zarządzasz wieloma stronami i nie możesz zaktualizować natychmiast.
- Wirtualne poprawki nie są zamiennikiem aktualizacji; kupują krytyczny czas.
WP‑Firewall zawiera zarządzane reguły, które można wdrożyć na Twojej stronie lub w sieci, a nasz silnik wirtualnych poprawek może automatycznie chronić dane wejściowe znane jako podatne w popularnych wtyczkach, takich jak ta. Dla stron na naszym darmowym planie, podstawowe zabezpieczenia WAF natychmiast obejmują wiele powszechnych wzorców wstrzykiwania.
Zalecane kroki w zakresie zabezpieczeń serwera i WordPressa
- Zastosuj zasadę minimalnych uprawnień:
- Przydzielaj uprawnienia Współpracownika tylko wtedy, gdy jest to konieczne.
- Ogranicz możliwości publikacji i edytowania metadanych dla ról niższego poziomu.
- Włącz uwierzytelnianie dwuskładnikowe na wszystkich kontach administratorów.
- Używaj zarządzania sesjami dla użytkowników i wylogowuj nieaktywnych/starych sesji.
- Ogranicz dostęp do wrażliwych stron administracyjnych według IP lub 2FA, gdzie to możliwe.
- Utrzymuj wszystkie wtyczki, motywy i rdzeń WordPressa w najnowszej wersji.
- Ogranicz uprawnienia do plików na serwerze i wyłącz wykonywanie PHP w katalogu przesyłania.
- Oddziel środowiska stagingowe i produkcyjne; najpierw testuj aktualizacje wtyczek w środowisku stagingowym.
Najlepsze praktyki dewelopera (dla autorów wtyczek i deweloperów stron)
Jeśli tworzysz motywy/wtyczki lub współpracujesz z autorami wtyczek, upewnij się, że następujące praktyki kodowania są przestrzegane, aby zapobiec przechowywanemu XSS:
- Zawsze oczyszczaj dane wejściowe podczas zapisywania do bazy danych, używając odpowiednich funkcji oczyszczania WordPress:
- Używać
dezynfekuj_pole_tekstowe(),wp_kses_post(), lub odpowiedniego oczyszczacza kontekstowego.
- Używać
- Użyj odpowiedniego kontekstu podczas renderowania danych:
- Używać
esc_html(),esc_attr(),wp_kses()z dozwolonymi tagami, lubwp_kses_post()dla treści postu.
- Używać
- Zarejestruj metadane postu za pomocą
register_post_meta()i dostarczsanitize_callbackjeśli dostępne. - Zweryfikuj uprawnienia użytkownika przed zapisaniem lub renderowaniem metadanych za pomocą
bieżący_użytkownik_może(). - Używaj nonce'ów i sprawdzania uprawnień w formularzach administracyjnych.
- Gdzie oczekiwana jest bogata treść, lepiej jest zezwolić na dozwolone tagi, zamiast blokować niebezpieczne ciągi.
W przypadku pól adresowych najprostszym bezpiecznym podejściem jest całkowite usunięcie tagów lub ograniczenie do bardzo małego zestawu dozwolonych tagów (np., <br>, <strong>), i zawsze stosować escapowanie przed wyjściem.
Wykrywanie i monitorowanie — na co zwracać uwagę
- Nietypowe ładowania stron administracyjnych inicjowane przez nieznane adresy IP lub w dziwnych porach.
- Nowe lub zmodyfikowane posty/lokalizacje z
wpsl_addresszaktualizowanymi metadanymi poza ustalonymi procesami. - Niespodziewane połączenia wychodzące z serwera (wskazuje na próby exfiltracji).
- Podejrzani nowi użytkownicy administracyjni lub prośby o resetowanie haseł.
- Powiadomienia od skanerów złośliwego oprogramowania o zmodyfikowanych plikach rdzeniowych lub nowych plikach w
wp-content/przesyłaniektóre zawierają kod PHP.
Przydatne polecenia WP‑CLI do szybkich kontroli:
# Lista użytkowników z rolą Administrator
Zintegruj te kontrole z centralnym logowaniem lub SIEM, jeśli zarządzasz wieloma stronami.
Jeśli Twoja strona została skompromitowana — lista kontrolna do odzyskiwania
- Wyłącz stronę (tryb konserwacji), aż zakończysz triage i czyszczenie.
- Zmień wszystkie hasła administratora i FTP/SFTP. Cofnij klucze API.
- Zmień sól WordPress w
wp-config.php. - Przywróć z czystej kopii zapasowej sprzed podejrzanych zmian, jeśli jest dostępna.
- Jeśli nie ma czystej kopii zapasowej, bezpiecznie usuń wstrzyknięte ładunki z bazy danych i sprawdź motywy/wtyczki pod kątem tylnych drzwi i zmodyfikowanych plików.
- Ponownie przeskanuj stronę za pomocą renomowanego skanera złośliwego oprogramowania (włączamy skanowanie w WP‑Firewall).
- Ponownie zainstaluj wtyczki/motywy z zaufanych źródeł i natychmiast je zaktualizuj.
- Przejrzyj zaplanowane zadania (WP-Cron) i usuń wszelkie nieautoryzowane zadania.
- Monitoruj logi pod kątem powtarzających się wzorców dostępu atakujących i blokuj ofensywne adresy IP na poziomie zapory.
- Rozważ profesjonalną reakcję na incydenty, jeśli podejrzewasz wyciek danych lub trwałe tylne drzwi.
Krytyczne jest założenie kompromitacji, jeśli wykryjesz dowody — pełne usunięcie, a nie tylko łatanie, może być konieczne.
Dlaczego konfiguracja ról ma znaczenie — współtwórcy nie są nieszkodliwi
Współtwórcy są często traktowani jako “niski ryzyko”, ponieważ nie mogą publikować treści bezpośrednio. Ale wiele wtyczek i przepływów pracy pozwala współtwórcom dostarczać metadane, sugestie lub szczegóły lokalizacji, które są później przeglądane przez redaktorów i administratorów. Ryzyko XSS wynika z tego, że złośliwe dane wejściowe są przechowywane i wykonywane później przez użytkownika z wyższymi uprawnieniami.
Zalecenia:
- Ogranicz edytowanie metadanych dla współtwórców: zapobiegaj ich modyfikacji metadanych postów bezpośrednio lub wdrażaj formularze treści, które oczyszczają dane wejściowe przy przesyłaniu.
- Przeglądaj i zatwierdzaj wszystkie dane przesłane przez współtwórców w środowisku stagingowym lub podglądowym, które nie uruchamia skryptów administracyjnych z uprawnieniami.
- Używaj przepływów pracy moderacyjnej i kroków przeglądu treści.
Jak WP‑Firewall uzupełnia aktualizacje wtyczek
Aktualizacja podatnej wtyczki (2.3.0+) jest ostatecznym rozwiązaniem. Jednak aktualizacje mogą być opóźnione w przypadku przepływów roboczych stagingowych, testowania zgodności lub dużych sieci multisite. To tam warstwowa ochrona ma znaczenie:
- WAF i wirtualne łatanie: Możemy wdrożyć zasady, które zatrzymują znane wzorce eksploatacji tej podatności na poziomie HTTP, zanim ładunek dotrze do Twojej aplikacji PHP.
- Zarządzane skanowanie i automatyczne czyszczenie złośliwego oprogramowania (dostępne w płatnych planach): skanuj pliki i bazę danych w poszukiwaniu pozostałych wstrzykniętych treści i usuń znane wskaźniki kompromitacji.
- Ograniczenie szybkości i zasady behawioralne: zapobiegaj masowemu przesyłaniu nowych wpisów lokalizacji lub podejrzanych wzorców ruchu POST.
- Powiadomienia i logowanie: natychmiast powiadomimy Cię, gdy zablokowana próba będzie odpowiadać przechowywanym wzorcom XSS.
To warstwowe podejście zyskuje czas i zmniejsza ryzyko dla witryn, które nie mogą natychmiast zaktualizować.
Lista kontrolna zapobiegawcza (priorytetowa)
- Zaktualizuj WP Store Locator do 2.3.0 lub nowszej — zrób to najpierw.
- Zrób kopię zapasową witryny i bazy danych.
- Uruchom skanowanie bazy danych dla
wpsl_addressmeta zawierające tagi HTML/skryptów. - Zastosuj zasady WAF lub włącz wirtualne łatanie, aby zablokować
wpsl_addresszgłoszenia z<scriptlub niebezpiecznymi atrybutami. - Przejrzyj role użytkowników i ogranicz możliwości edytowania metadanych przez współpracowników.
- Zmień hasła administratorów i sól WordPress, jeśli znajdziesz podejrzane treści.
- Skanuj pliki witryny i katalog przesyłania w poszukiwaniu webshelli.
- Monitoruj logi pod kątem nietypowej aktywności administratorów i powtarzających się zablokowanych prób.
- Edukuj swój zespół treści, aby unikał wklejania HTML lub skryptów do pól adresowych.
- Testuj aktualizacje wtyczek w środowisku testowym przed wdrożeniem na produkcję.
Dla dostawców hostingu i agencji
Jeśli zarządzasz witrynami dla klientów, traktuj to jako zadanie operacyjne o wysokim priorytecie:
- Zaplanuj masowe aktualizacje wtyczek dla swoich klientów korzystających z WP Store Locator; skoordynuj okna testowe.
- Natychmiast wdroż zasady WAF w całej swojej infrastrukturze serwerowej, aby zablokować znane wzorce.
- Powiadom klientów z przepływami pracy współpracowników, aby przejrzeli ostatnie zgłoszenia.
- Zapewnij usługę naprawczą, która obejmuje audyty bazy danych i czyszczenie.
- Rozważ automatyczne skanowanie podatności, które wykrywa witryny działające na podatnych wersjach wtyczek.
Zabezpiecz notatki deweloperskie dla autorów WP Store Locator (i autorów wtyczek ogólnie)
Autorzy: rejestruj i sanitizuj metadane postów za pomocą interfejsów API WordPress. Jeśli oczekujesz HTML w polu metadanych, użyj białej listy (np., wp_kses() z rygorystycznym zestawem dozwolonych tagów) i zawsze escape'uj przy wyjściu. Waliduj kontrole uprawnień na wszelkich punktach końcowych administratora i odrzucaj żądania bez poprawnych nonce'ów.
Zabezpiecz swoją witrynę teraz — wypróbuj WP‑Firewall Free
Szybko zabezpiecz swoją stronę WordPress za pomocą WP‑Firewall Free
Jeśli chcesz natychmiastowej podstawowej ochrony podczas planowania aktualizacji i przeprowadzania kontroli, wypróbuj WP‑Firewall Free. Plan Podstawowy (Darmowy) obejmuje zarządzany zaporę, nielimitowaną przepustowość, zaporę aplikacji internetowej (WAF), skaner złośliwego oprogramowania oraz łagodzenie ryzyk OWASP Top 10 — wszystko, czego potrzebujesz, aby zredukować ryzyko podczas stosowania trwałego rozwiązania.
Zarejestruj się w darmowym planie i aktywuj podstawową ochronę w ciągu kilku minut:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Jeśli potrzebujesz automatycznego usuwania złośliwego oprogramowania, ściślejszego blokowania IP lub wirtualnego łatania na wielu stronach, nasze plany Standard i Pro dodają automatyczne usuwanie, kontrolę czarnej/białej listy, miesięczne raporty bezpieczeństwa, wirtualne łatanie i usługi zarządzane.)
Uwagi końcowe — najpierw aktualizuj, potem wzmacniaj
CVE-2026-3361 przypomina, że przechowywane-XSS pozostaje powszechną i niebezpieczną klasą podatności w ekosystemach wtyczek WordPress. Najważniejszym krokiem, jaki możesz podjąć, jest zaktualizowanie wtyczki WP Store Locator do wersji 2.3.0 lub nowszej. Po aktualizacji wykonaj kroki detekcji powyżej, aby upewnić się, że Twoja strona nie została dotknięta.
Dla obrońców i zarządzających stronami, połącz łatanie z warstwowymi obronami:
- Utrzymuj oprogramowanie w aktualności,
- Ogranicz możliwości użytkowników,
- Użyj WAF i wirtualnego łatania jako tymczasowej osłony,
- Aktywnie skanuj i monitoruj.
Jeśli potrzebujesz pomocy w wdrażaniu zasad WAF, skanowaniu swojej floty w poszukiwaniu podejrzanych wpsl_address wartości meta lub ustawianiu wirtualnego łatania na wielu stronach, zespół WP‑Firewall może pomóc Ci szybko i bezpiecznie się zabezpieczyć.
Bądź bezpieczny i traktuj wszelkie podejrzane treści po stronie administratora jako pilne — atakujący często potrzebuje tylko jednej zaufanej sesji przeglądarki, aby przekształcić w przeciwnym razie niskoprioritetową podatność w pełne naruszenie.
