Çerezlerde güvenlik bayrakları eksik

ÖnemOrta

KapsamTüm site

EmekOrta

DoğrulamaGüvenlik taraması (haftalık ya da Yeniden tara)

Kural anahtarısec_cookie_flags

Kısa cevap

HTTPS üzerinden verilen her çerez Secure taşımalı ki hiçbir zaman düz HTTP ile gönderilmesin. Oturum ve giriş çerezleri ayrıca JavaScript okuyamasın diye HttpOnly ister; SameSite=Lax (ya da Strict) ise tarayıcının bunları başka sitelerin başlattığı isteklere ne zaman ekleyeceğini sınırlar. WordPress'te, PHP'de ve çoğu altyapıda bunlar kod değişikliği değil ayardır. Sıralamaya etkisi yoktur.

Neden önemli

Secure bayrağı olmayan çerez, tarayıcı alan adınıza her http:// isteği yaptığında (eski bir linkle ya da bunu zorlayan kötü niyetli bir Wi-Fi ağında) şifresiz gönderilir ve o ağdaki herkes kopyalayabilir. HttpOnly olmayan oturum çerezini sayfadaki her betik okuyabilir; tek bir XSS hatası ya da ele geçirilmiş bir dış betik hesap ele geçirmeye dönüşür. SameSite, tarayıcının siteler arası istek sahteciliğine (CSRF) karşı yerleşik savunmasıdır.

Kopyalanan bir oturum çerezi, oturum süresince kullanıcının parolası gibi çalışır; yönetici hesapları dahil.

Glimana bunu nasıl tespit eder

Glimana anonim bir ziyaretçinin ana sayfanızda ve en çok iki başka sayfada (önemli sayfalarınızdan biri ve site haritanızda en son güncellenen sayfa) aldığı Set-Cookie başlıklarını okur. Bir çerez şu durumlarda işaretlenir: Secure yoksa; adı oturum ya da giriş çerezine benziyorsa (sess, auth, token, login ya da remember içeriyorsa veya PHPSESSID, laravel_session, JSESSIONID vb. ise) ve HttpOnly yoksa; SameSite geçersiz bir değer taşıyorsa; ya da SameSite=None, Secure olmadan gelmişse. XSRF-TOKEN gibi CSRF çerezlerinden HttpOnly beklenmez. Oturum türünde bir çerez etkilenmişse sorun Orta, değilse Düşük'tür; hiç çerez yoksa kontrol Uygulanmaz olur. Yalnız SameSite eksikliği işaretlenmez; yalnız girişten sonra verilen çerezler görülmez.

Nasıl düzeltilir

Dikkat

Kendi JavaScript'inizin okuması gereken çerezlere (çerez onay bandı, CSRF çerezi) HttpOnly eklemeyin; çalışmayı bırakırlar. Oturum çerezinde SameSite=Strict, e-posta linkinden gelen ya da ödeme veya tek oturum açma sayfasından dönen kullanıcıyı oturumu kapanmış gibi gösterir; Strict'e gerçekten ihtiyacınız yoksa Lax kullanın. Tarayıcılar SameSite=None değerini yalnız Secure ile birlikte kabul eder.

Glimana'da bulguyu bulun. Güvenlik sayfasını açın; bu kontrol Çerezler ve siteler arası erişim grubunda, son taramanın kanıtı başlığının altında. Aynı sorun Sorunlar › Çerezlerde güvenlik bayrakları eksik altında da listelenir.
Düzeltmeyi platformunuzda uygulayın.

WordPressPHP / LaravelApache / Nginx

WordPress çekirdeği giriş çerezlerini HttpOnly ile, HTTPS'i algıladığında da Secure ile verir. Çekirdek çerezleri işaretlendiyse Ayarlar › Genel altındaki iki adresin de https:// ile başladığından emin olun. Bir proxy ya da Cloudflare'in Flexible SSL kipi arkasında WordPress HTTPS'i algılamayabilir; Cloudflare'i Full (strict) kipine alın ya da kendi proxy'nizin arkasındaysanız wp-config.php dosyasına if (($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https') { $_SERVER['HTTPS'] = 'on'; } ekleyin. İşaretlenen çerezlerin çoğu eklentilerden gelir (analitik, çerez onayı, canlı destek, A/B testi): sorundaki çerez adı hangisi olduğunu söyler; eklentiyi güncelleyin ya da ayarlarına bakın.

PHP oturumları için php.ini dosyasında ya da barındırıcınız izin veriyorsa .user.ini içinde: session.cookie_secure = 1, session.cookie_httponly = 1, session.cookie_samesite = Lax. Kendi verdiğiniz çerezler: setcookie('name', $value, ['secure' => true, 'httponly' => true, 'samesite' => 'Lax', 'path' => '/']);. Laravel: .env içinde SESSION_SECURE_COOKIE=true ve SESSION_SAME_SITE=lax yazın, sonra php artisan config:cache çalıştırın; config/session.php içinde http_only zaten true'dur.

Uygulamayı düzeltmek daha iyidir ama bir sunucu kuralı her çereze bayrağı ekleyebilir. Apache (mod_headers), PHP'nin nasıl çalıştığına göre hangisinin işleyeceği değiştiği için iki satırı da yazın: Header always edit Set-Cookie "(?i)^((?:(?!;\s*secure).)+)$" "$1; Secure" ve Header edit Set-Cookie "(?i)^((?:(?!;\s*secure).)+)$" "$1; Secure". Bir uygulamanın önündeki Nginx'te (1.19.3 ve sonrası), proxy yapan location içinde: proxy_cookie_flags ~ secure samesite=lax;. İkisi de tarayıcıda JavaScript'in verdiği çerezlere ulaşmaz.
Glimana'da kontrol edin. Güvenlik sayfasında Yeniden tara düğmesine basın (saatte en çok iki tarama) ya da pazar günkü haftalık taramayı bekleyin; kontrol geçince sorun kapanır.

Düzeltme nasıl doğrulanır

Düzelttikten sonra Güvenlik sayfasında Yeniden tara düğmesine basın (ya da pazar günkü haftalık taramayı bekleyin); kontrol geçtiği anda sorun kapanır.