Naprawianie flag bezpieczeństwa cookies w WordPress

Jeśli InspectWP raportuje cookies bez flag Secure, HttpOnly lub SameSite, Twoja witryna może być podatna na przejęcie sesji, kradzież cookies opartą na XSS lub ataki cross-site request forgery (CSRF). Te trzy flagi to najważniejsze atrybuty bezpieczeństwa cookies i razem chronią dane sesji Twoich użytkowników. Na szczęście naprawienie ich w WordPress jest proste, gdy zrozumiesz, co robi każda flaga i gdzie ją zastosować.

Zrozumienie flag bezpieczeństwa cookies i ich celu

Zanim zastosujesz naprawy, warto zrozumieć, przed czym chroni każda flaga:

• Flaga Secure: Zapewnia, że cookie jest wysyłane tylko przez połączenia HTTPS. Bez tej flagi cookie może być przesyłane przez nieszyfrowane HTTP, umożliwiając atakującemu w tej samej sieci (np. publicznym wifi) przechwycenie go za pomocą prostego packet sniffera. Gdy zdobędzie cookie sesji, może podszyć się pod użytkownika. Ten atak nazywa się przejęciem sesji lub sidejackingiem.
• Flaga HttpOnly: Zapobiega dostępowi JavaScript do cookie poprzez document.cookie. To kluczowa ochrona przed atakami cross-site scripting (XSS). Jeśli atakującemu uda się wstrzyknąć złośliwy JavaScript na Twoją stronę (przez podatną wtyczkę, pole komentarza lub wejście użytkownika), flaga HttpOnly zapobiegnie odczytaniu przez ten skrypt cookies sesji i wysłaniu ich do zewnętrznego serwera.
• Flaga SameSite: Kontroluje, czy cookie jest wysyłane z żądaniami cross-site. To chroni przed atakami CSRF, w których złośliwa witryna nakłania przeglądarkę użytkownika do wykonywania uwierzytelnionych żądań do Twojej witryny. Atrybut SameSite ma trzy możliwe wartości:
  • Strict: Cookie nigdy nie jest wysyłane z żądaniami cross-site. Daje to najsilniejszą ochronę, ale może zepsuć przepływy logowania, gdy użytkownicy klikają linki ze źródeł zewnętrznych takich jak e-maile czy inne strony.
  • Lax: Cookie jest wysyłane przy nawigacji najwyższego poziomu (kliknięcie linku), ale nie przy żądaniach osadzonych (obrazy, iframe, AJAX). To zalecany domyślny wybór dla większości witryn WordPress.
  • None: Cookie jest wysyłane przy wszystkich żądaniach, w tym cross-site. Musi być łączone z flagą Secure i jest potrzebne tylko dla cookies, które muszą działać w kontekstach cross-site, takich jak integracje dostawców płatności lub osadzone widgety.

Hardening cookies uwierzytelniania WordPress

WordPress ustawia kilka cookies dla zalogowanych użytkowników, w tym wordpress_logged_in_* i wordpress_sec_*. To najbardziej wrażliwe na bezpieczeństwo cookies na Twojej witrynie, ponieważ kontrolują dostęp administratora. Aby je zahardenować, dodaj następujące stałe do swojego pliku wp-config.php, przed linią mówiącą "That's all, stop editing!":

// Wymuszaj wysyłanie cookies tylko przez HTTPS
define('FORCE_SSL_ADMIN', true);

// Ustaw domenę i ścieżkę cookie
define('COOKIE_DOMAIN', 'example.com');
define('COOKIEPATH', '/');

// Zahardenuj cookies sesji PHP
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');

Stała FORCE_SSL_ADMIN jest szczególnie ważna. Wymusza, aby WordPress używał HTTPS dla panelu administracyjnego i stron logowania, zapewniając, że cookies uwierzytelniania są ustawiane tylko przez szyfrowane połączenia. Bez tego użytkownik logujący się przez HTTP przesyłałby swoje dane logowania i cookies w postaci tekstu jawnego.

Zwróć uwagę, że @ini_set wpływa tylko na cookies sesji PHP, nie na cookies specyficzne dla WordPress. WordPress używa własnych funkcji ustawiania cookies, które nie zależą od sesji PHP. Aby zabezpieczyć konkretnie cookies WordPress, potrzebujesz podejść na poziomie serwera opisanych poniżej.

Ustawianie flag cookies przez konfigurację PHP

Dla PHP 7.3 i nowszych możesz ustawić domyślne atrybuty cookies, które dotyczą wszystkich cookies tworzonych przez funkcję PHP setcookie(). Dodaj je do swojego pliku php.ini, jeśli masz dostęp:

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

Jeśli nie masz dostępu do php.ini (typowe na hostingu współdzielonym), możesz zamiast tego ustawić te wartości w swoim pliku .htaccess:

# Ustaw bezpieczne domyślne wartości cookies dla sesji PHP
php_value session.cookie_secure 1
php_value session.cookie_httponly 1
php_value session.cookie_samesite "Lax"

Pamiętaj, że te ustawienia dotyczą tylko cookies tworzonych przez natywną obsługę sesji PHP. Rdzeń WordPress i większość wtyczek używają setcookie() lub wp_set_auth_cookie() bezpośrednio, które nie dziedziczą automatycznie tych ustawień ini. Dla kompleksowego pokrycia podejście na poziomie serwera przez nagłówek jest bardziej niezawodne.

Naprawianie wszystkich cookies przez Apache .htaccess

Najbardziej niezawodny sposób dodawania flag bezpieczeństwa do każdego cookie na serwerze Apache to modyfikacja nagłówka Set-Cookie na poziomie serwera. To przechwytuje wszystkie cookies, w tym te ustawione przez rdzeń WordPress, wtyczki i skrypty firm trzecich:

# Dodaj flagi bezpieczeństwa do wszystkich cookies
<IfModule mod_headers.c>
    Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"
</IfModule>

Umieść to w głównym pliku .htaccess swojej witryny. Dyrektywa Header always edit używa wyrażenia regularnego do dopasowania wszystkich nagłówków Set-Cookie i dodaje flagi bezpieczeństwa do każdego z nich.

Jest jedno ważne zastrzeżenie do tego podejścia. Jeśli cookie już ma jedną z tych flag (np. wtyczka sama ustawia Secure), możesz skończyć z duplikatami flag jak Secure; Secure. Większość przeglądarek obsługuje duplikaty łaskawie, ale czystsze podejście używa negative lookahead, aby uniknąć dodawania już obecnych flag:

<IfModule mod_headers.c>
    # Dodaj flagę Secure, jeśli nie jest jeszcze obecna
    Header always edit Set-Cookie "^((?!.*Secure).*)$" "$1; Secure"

    # Dodaj flagę HttpOnly, jeśli nie jest jeszcze obecna
    Header always edit Set-Cookie "^((?!.*HttpOnly).*)$" "$1; HttpOnly"

    # Dodaj SameSite=Lax, jeśli żaden atrybut SameSite nie jest obecny
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"
</IfModule>

Ta wersja sprawdza każde cookie osobno i dodaje flagę tylko wtedy, gdy jeszcze jej nie ma. Jest bardziej szczegółowa, ale zapobiega potencjalnym problemom z duplikowanymi atrybutami.

Naprawianie wszystkich cookies przez konfigurację Nginx

Dla serwerów Nginx podejście zależy od Twojej wersji Nginx:

Nginx 1.19.3 i nowszy obsługuje natywnie dyrektywę proxy_cookie_flags:

# W bloku serwera lub location
proxy_cookie_flags ~ secure httponly samesite=lax;

Znak ~ dopasowuje wszystkie cookies. Możesz też kierować konkretne cookies według nazwy:

# Zastosuj tylko do cookies sesji WordPress
proxy_cookie_flags wordpress_logged_in_* secure httponly samesite=lax;
proxy_cookie_flags wordpress_sec_* secure httponly samesite=lax;

Starsze wersje Nginx (przed 1.19.3) mogą używać dyrektywy proxy_cookie_path jako obejście:

# Obejście dla starszych wersji Nginx
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

Jeśli używasz Nginx jako reverse proxy dla Apache lub PHP-FPM, możesz też potrzebować dodać nagłówki przez moduł more_set_headers lub dyrektywę add_header. Jednak add_header nie modyfikuje nagłówków Set-Cookie, więc proxy_cookie_flags jest właściwym podejściem.

Naprawianie cookies na witrynach proxowanych przez Cloudflare lub CDN

Jeśli Twoja witryna WordPress znajduje się za Cloudflare lub innym proxy CDN, dochodzi dodatkowa warstwa obsługi cookies. Cloudflare ustawia własne cookies (takie jak __cf_bm do zarządzania botami), a te cookies są zarządzane przez Cloudflare, nie przez Twoją konfigurację serwera. Nie możesz dodać flag bezpieczeństwa do cookies Cloudflare przez .htaccess czy konfigurację Nginx.

Cookies Cloudflare domyślnie zawierają już flagi Secure i HttpOnly. Jeśli InspectWP oznacza cookie Cloudflare jako pozbawione flagi, prawdopodobnie chodzi o problem z wyświetlaniem lub o cookie z funkcji Cloudflare, która celowo pomija określone flagi (np. cookies analityki, które potrzebują dostępu JavaScript i dlatego nie mają HttpOnly).

Dla cookies ustawianych przez Twój serwer origin opisane powyżej naprawy w .htaccess lub Nginx działają poprawnie również wtedy, gdy Cloudflare stoi przed witryną. Cloudflare przekazuje nagłówki Set-Cookie z Twojego serwera do klienta bez modyfikacji.

Radzenie sobie z cookies wtyczek pozbawionymi flag bezpieczeństwa

Wiele wtyczek WordPress ustawia własne cookies i nie wszystkie zawierają poprawne flagi bezpieczeństwa. Częsti winowajcy to:

• Wtyczki zgody na cookies: Wtyczki takie jak CookieYes, Complianz lub GDPR Cookie Consent ustawiają cookies, aby zapamiętać wybór zgody użytkownika. Sprawdź ustawienia każdej wtyczki pod kątem opcji "Bezpieczne cookies" lub "Bezpieczeństwo cookies". Niektóre wtyczki dodały te opcje w najnowszych wersjach.
• Wtyczki analityki i śledzenia: Google Analytics, Matomo i podobne wtyczki mogą ustawiać cookies śledzące bez flag bezpieczeństwa. Podejście na poziomie serwera (Apache/Nginx) to najlepsze rozwiązanie dla nich, ponieważ wtyczki rzadko oferują konfigurację flag cookies.
• Wtyczki cache: WP Rocket, LiteSpeed Cache i inne ustawiają cookies identyfikacji cache, którym może brakować flag. Również tutaj podejście na poziomie serwera obsługuje to automatycznie.
• WooCommerce: WooCommerce ustawia kilka cookies dla danych koszyka i zarządzania sesją. Najnowsze wersje WooCommerce (5.0+) ustawiają flagę Secure, gdy witryna używa HTTPS, ale starsze wersje mogą tego nie robić. Zaktualizuj WooCommerce do najnowszej wersji i zastosuj poprawkę nagłówka na poziomie serwera jako siatkę bezpieczeństwa.
• Wtyczki logowania i członkostwa: Wtyczki takie jak MemberPress, Restrict Content Pro lub WP-Members mogą ustawiać własne cookies sesji. Sprawdź aktualizacje wtyczki, ponieważ wiele dodało obsługę flag bezpieczeństwa w odpowiedzi na zmiany przeglądarek dotyczące egzekwowania SameSite.

Podejście na poziomie serwera (Apache Header edit lub Nginx proxy_cookie_flags) to najbardziej niezawodne rozwiązanie, ponieważ przechwytuje wszystkie cookies niezależnie od tego, która wtyczka lub skrypt je ustawia. Nawet jeśli aktualizacja wtyczki usunie flagi, Twoja konfiguracja serwera doda je z powrotem.

Specjalne rozważania dla cookies SameSite=None

Niektóra funkcjonalność wymaga, aby cookies były wysyłane w kontekstach cross-site. Częste przykłady to:

• Callbacki dostawców płatności: Usługi takie jak PayPal, Stripe lub Mollie mogą przekierować użytkowników z powrotem na Twoją witrynę po płatności. Jeśli Twoje cookie sesji używa SameSite=Strict, użytkownik zostanie wylogowany po przekierowaniu, ponieważ przeglądarka nie wyśle cookie przy nawigacji cross-site.
• Osadzona treść (iframe): Jeśli Twoja witryna WordPress jest osadzona w iframe na innej domenie, cookies potrzebują SameSite=None; Secure, aby funkcjonować. Jest to istotne dla konfiguracji headless WordPress lub witryn oferujących osadzalne widgety.
• Przepływy OAuth i SSO: Wdrożenia single sign-on przekierowujące przez zewnętrznych dostawców tożsamości mogą wymagać SameSite=None dla cookie sesji podczas przepływu uwierzytelniania.

Jeśli potrzebujesz SameSite=None dla konkretnych cookies, jednocześnie utrzymując SameSite=Lax jako domyślne, potrzebujesz bardziej ukierunkowanej konfiguracji. W Apache:

<IfModule mod_headers.c>
    # Domyślnie: dodaj SameSite=Lax do wszystkich cookies
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"

    # Nadpisanie dla konkretnych cookies wymagających dostępu cross-site
    Header always edit Set-Cookie "(payment_session=.*)" "$1; SameSite=None; Secure"
</IfModule>

Dodawanie bezpieczeństwa cookies przez wtyczkę WordPress

Jeśli nie masz dostępu do plików konfiguracyjnych serwera (typowe na zarządzanym hostingu WordPress), możesz użyć wtyczki WordPress do dodawania flag bezpieczeństwa cookies. Podejście wtyczkowe działa poprzez podpinanie się do filtra wp_headers lub użycie funkcji PHP header(), aby zmodyfikować nagłówki Set-Cookie przed wysłaniem ich do przeglądarki:

function add_cookie_security_flags($headers) {
    // To wpływa na nagłówki wysyłane przez WordPress
    if (is_ssl()) {
        $headers['Set-Cookie'] = 'Secure; HttpOnly; SameSite=Lax';
    }
    return $headers;
}
add_filter('wp_headers', 'add_cookie_security_flags');

// Dla bezpieczeństwa cookies na poziomie PHP
function enforce_cookie_security() {
    if (is_ssl() && PHP_VERSION_ID >= 70300) {
        ini_set('session.cookie_secure', '1');
        ini_set('session.cookie_httponly', '1');
        ini_set('session.cookie_samesite', 'Lax');
    }
}
add_action('init', 'enforce_cookie_security', 1);

To podejście ma ograniczenia. Wpływa tylko na cookies ustawiane po wystrzeleniu hooka init WordPress i nie może modyfikować cookies ustawianych przez JavaScript lub skrypty zewnętrzne. Podejście na poziomie serwera jest zawsze bardziej kompleksowe.

Weryfikacja flag bezpieczeństwa cookies po zastosowaniu napraw

Po wdrożeniu napraw dokładne testowanie jest niezbędne, aby potwierdzić, że wszystko działa poprawnie:

1. Wyczyść wszystkie cookies przeglądarki: Otwórz developer tools przeglądarki, przejdź do zakładki Application (Chrome) lub Storage (Firefox) i usuń wszystkie cookies dla swojej domeny. Pozwala to przetestować świeże cookies z nowymi flagami.
2. Odwiedź swoją witrynę i zaloguj się: Po zalogowaniu wróć do developer tools i sprawdź każde cookie. W Chrome panel Application > Cookies pokazuje kolumny dla Secure, HttpOnly i SameSite. Każde cookie uwierzytelniania powinno pokazywać znacznik wyboru dla Secure i HttpOnly oraz wyświetlać "Lax" dla SameSite.
3. Przetestuj krytyczne przepływy użytkowników: Przejdź przez kluczową funkcjonalność swojej witryny: dodaj produkty do koszyka (przy WooCommerce), wyślij formularze, przejdź przez proces realizacji zamówienia i użyj funkcji członkostwa. Zmiany SameSite mogą sporadycznie zepsuć przepływy cross-site; dlatego testuj wszystko, co obejmuje przekierowania z zewnętrznych usług.
4. Przetestuj logowanie z linków zewnętrznych: Wyślij sobie e-mail resetu hasła i kliknij link. Jeśli użyłeś SameSite=Strict (niezalecane), ten przepływ może się zepsuć, ponieważ cookie nie zostanie wysłane przy nawigacji cross-site z klienta poczty.
5. Uruchom InspectWP ponownie: Uruchom nowy skan swojej witryny w InspectWP, aby potwierdzić, że wszystkie ostrzeżenia dotyczące bezpieczeństwa cookies zostały rozwiązane. InspectWP sprawdza każde cookie osobno, dzięki czemu możesz zobaczyć dokładnie, które cookies mają teraz poprawne flagi.

Rozwiązywanie częstych problemów po włączeniu flag bezpieczeństwa cookies

• Użytkownicy są wylogowywani po kliknięciu linków e-mail: Dzieje się to, gdy ustawione jest SameSite=Strict. Przełącz się na SameSite=Lax, który zezwala na cookies przy nawigacji najwyższego poziomu z zewnętrznych witryn, jednocześnie blokując osadzone żądania cross-site.
• Integracja z dostawcą płatności nie działa: Niektórzy dostawcy płatności kierują użytkowników podczas realizacji zamówienia przez własną domenę. Jeśli cookie sesji nie jest wysyłane po przekierowaniu, użytkownik traci koszyk lub status logowania. Ustaw konkretnie cookie sesji płatności na SameSite=None; Secure, podczas gdy inne cookies pozostają na SameSite=Lax.
• Baner zgody na cookies wciąż się pojawia: Jeśli cookie wtyczki zgody na cookies jest ustawiane bez flagi Secure, a Twoja witryna przekierowuje z HTTP do HTTPS, cookie ustawione przez HTTP nie zostanie wysłane przez HTTPS, powodując ponowne pojawienie się banera. Upewnij się, że Twoja witryna działa w pełni na HTTPS, a cookie zgody zawiera flagę Secure.
• Konflikty cache: Niektóre wtyczki cache cachują nagłówki Set-Cookie razem z treścią strony. Po zastosowaniu zmian flag cookies na poziomie serwera wyczyść cały cache (zarówno cache strony, jak i object cache), aby zapewnić, że nowe nagłówki zaczną obowiązywać.
• Zduplikowane flagi cookies: Jeśli widzisz atrybuty takie jak Secure; Secure lub SameSite=Lax; SameSite=Lax w swoich cookies, wiele warstw dodaje te same flagi. Sprawdź swój .htaccess, wp-config.php, ustawienia PHP ini i wszelkie wtyczki bezpieczeństwa pod kątem nakładających się konfiguracji. Użyj podejścia z negative lookahead regex w .htaccess, aby zapobiec duplikatom.

Najlepsze praktyki bezpieczeństwa cookies w WordPress

• Zawsze używaj HTTPS: Flaga Secure jest bezsensowna bez HTTPS. Upewnij się, że cała Twoja witryna ładuje się przez HTTPS, w tym wszystkie zasoby (obrazy, skrypty, arkusze stylów). Użyj stałej FORCE_SSL_ADMIN i rozważ nagłówek HSTS, aby zapobiec wszelkim dostępom HTTP.
• Domyślnie SameSite=Lax: To zapewnia silną ochronę CSRF bez psucia normalnej nawigacji. Używaj SameSite=None tylko dla konkretnych cookies, które naprawdę potrzebują dostępu cross-site, a SameSite=Strict używaj tylko wtedy, gdy jesteś pewien, że żadna zewnętrzna nawigacja do Twojej witryny nie musi zachowywać sesji.
• Stosuj flagi na poziomie serwera: Konfiguracja na poziomie serwera (Apache .htaccess lub konfiguracja Nginx) przechwytuje wszystkie cookies niezależnie od pochodzenia. Jest to bardziej niezawodne niż podejścia na poziomie wtyczki lub PHP.
• Utrzymuj WordPress i wtyczki zaktualizowane: Nowoczesne wersje rdzenia WordPress i większości popularnych wtyczek ustawiają poprawne flagi cookies, gdy HTTPS jest aktywny. Utrzymywanie wszystkiego zaktualizowanego zmniejsza liczbę niezabezpieczonych cookies, które musisz naprawiać na poziomie serwera.
• Regularnie audytuj cookies: Okresowo uruchamiaj skany InspectWP, aby odkryć nowe cookies wprowadzone przez aktualizacje wtyczek lub nowe integracje. Bezpieczeństwo cookies nie jest jednorazową naprawą; wymaga ciągłej uwagi w miarę ewolucji Twojej witryny.
• Testuj w wielu przeglądarkach: Chrome, Firefox, Safari i Edge obsługują atrybuty cookies nieco inaczej. Chrome jest najostrzejszym egzekutorem polityk SameSite, podczas gdy Safari ma własną Intelligent Tracking Prevention, która wpływa na zachowanie cookies. Testuj swoją witrynę po zmianach we wszystkich głównych przeglądarkach.