Kurabiyeler nasıl güvence altına alınır | Hahwul

   Mayıs 30, 2025  Posted in Mix


Çerezler web uygulamalarında önemli bir rol oynar, ancak aynı zamanda güvenlik ayarlarına dikkat edilmesi gerekir. Bu yazıda, çerezleri daha güvenli bir şekilde yönetmek için çeşitli özelliklere derinlemesine bakacağız. Özellikle nasıl niteliklerin nasıl olduğunu keşfedeceğiz SameSiteile birlikte HttpOnly– Secure– Path– Domain– ExpiresVe Max-Ageher biri çerez güvenliğinin desteklenmesine katkıda bulunur.

Çerezler, kullanıcıları tanımlayan oturum kimlikleri gibi hassas bilgileri saklayabilir. Bu çerezler bir saldırgan tarafından çalınırsa, oturum kaçırma riski vardır ve kullanıcı hesaplarına yetkisiz erişime izin verir. Ayrıca, çerezler, siteler arası istek ambgiteri (CSRF) saldırılarında kullanılabilir ve kullanıcıların bir web sitesinde istenmeyen eylemler gerçekleştirmesine yol açar. Bu nedenle, her çerez özniteliğini anlamak ve bunları doğru yapılandırmak kritik öneme sahiptir.

Çerezlerinizin sağlam olmasına yardımcı olacak temel güvenlik özelliklerini inceleyelim.

1. Httponly: XSS’ye karşı koruma

Ne zaman HttpOnly Öznitelik ayarlandı, çereze JavaScript’in üzerinden erişilemez document.cookie API. Bu, saldırganların bir web sitesindeki siteler arası komut dosyası (XSS) güvenlik açıkları yoluyla enjekte edilen kötü amaçlı komut dosyaları aracılığıyla kullanıcı çerez değerlerini (özellikle oturum kimlikleri) çalmasını önlemede etkilidir.

Örnek (HTTP başlığı):

Set-Cookie: session_id=verysecretvalue; HttpOnly

Ayarlanması tavsiye edilir HttpOnly Hassas çerezler için, özellikle kullanıcı kimlik doğrulaması ile ilgili olanlar için özellik. Temel bir savunma mekanizması olsa da, etkinliği önemlidir.

2. Güvenli: Şifreli şanzımanın sağlanması

İle bir kurabiye Secure Öznitelik yalnızca bir HTTPS bağlantısı üzerinden iletilir. Bu, çerezin şifrelenmemiş HTTP bağlantıları üzerinden gönderilmeyeceği anlamına gelir, böylece bir saldırganın ağdaki çerezi kesebileceği ortadaki insan (MITM) saldırılarından korunur.

Örnek (HTTP başlığı):

Set-Cookie: user_preference=dark_mode; Secure

Çoğu modern web sitesi varsayılan olarak HTTPS kullandığından, Secure Öznitelik de önerilir. Kullanıyorsanız, SameSite=None politika, Secure öznitelik eşzamanlı olarak ayarlanmalıdır.

3. Samesite: CSRF Kalkanı (derinlemesine)

. SameSite Özellik, siteler arası talep ampudu (CSRF) saldırılarına karşı savunmada çok önemli bir rol oynar. Bu öznitelik, tarayıcıya bir çerezin diğer kökenlerden (saha arası) başlatılan isteklerle gönderilip gönderilmeyeceğini söyler. Daha basit bir şekilde, web sitenizden bir kurabiye olup olmadığını kontrol eder (siteA.com) İlişkisiz bir web sitesinden gönderilen bir talebe dahil edilecektir (evil.com) ile siteA.com.

. SameSite Öznitelik üç değerden birine sahip olabilir:

  • Strict: Bu en güçlü koruma seviyesini sağlar. İle ayarlanan kurabiyeler SameSite=Strict yalnızca istek, kullanıcının şu anda etkileşime girdiği aynı siteden (birinci taraf bağlam) kaynaklanıyorsa gönderilir. Örneğin, bir kullanıcı harici bir siteden sizinkine bir bağlantıyı tıklarsa, çerezler Strict gönderilmeyecek. Sonuç olarak, bir giriş oturumu çerezi ayarlanmışsa Strictkullanıcı harici bir bağlantı aracılığıyla geldiğinde oturum açabilir ve tekrar giriş yapması gerekebilir.

    • Ne Zaman Kullanılmalı: Şifre değişiklikleri, içerik oluşturma veya sipariş işleme gibi durum değiştiren eylemlerle ilgili çerezler için uygundur.
    • Örnek: Set-Cookie: session_id=verysecretvalue; SameSite=Strict

  • Lax: Bu biraz daha rahat bir ortam Strict Ama yine de mükemmel güvenlik sunuyor. Lax Genellikle gibi davranır Strict Ve çoğu siteler arası istekte çerez göndermez. Bununla birlikte, bir kullanıcının harici birinden sitenize gitmek için bir bağlantıyı tıkladığı gibi, güvenli bir HTTP yöntemi (GET, Head, Seçenekler, Trace) kullanarak üst düzey bir gezinme ise, siteler arası isteklere çerez gönderir. Bu, kullanıcıların çoğu senaryo için CSRF korumasından ödün vermeden harici bağlantılardan geldiklerinde oturum açmış durumlarını korumalarını sağlar. Birçok modern tarayıcı benimsedi Lax Hayır kurabiyeler için varsayılan olarak SameSite öznitelik belirtilir.

    • Ne Zaman Kullanılmalı: Güvenlik ve kullanıcı deneyimi arasında iyi bir denge sunan genel oturum yönetimi çerezleri için çok uygundur.
    • Örnek: Set-Cookie: tracking_id=randomstring; SameSite=Lax

  • None: Bu ayarla, çerezlerin hem aynı saha hem de çapraz site gibi tüm isteklere, çerezlerin nasıl davrandığına benzer şekilde çerezler gönderilir. SameSite öznitelik tanıtıldı. Ancak kritik bir gereklilik SameSite=None kullanılır, Secure Öznitelik de belirtilmelidir (SameSite=None; Secure). Bu, çerezin yalnızca güvenlik risklerini azaltmak için bir önlem olan HTTPS bağlantıları üzerinde çalıştığını zorunlu kılar.

    • Ne Zaman Kullanılmalı: Çerezlerin, hizmetiniz harici bir hizmette bir IFrame içine gömüldüğü ve çerez tabanlı kimlik doğrulama gerektirdiği gibi, çoklu alanları kapsayan tek oturum açma (SSO) senaryoları veya AD ve analiz komut dosyaları için gibi çerezler arası bir bağlamda açıkça ihtiyaç duyulan durumlar için az miktarda kullanılır.
    • Önemli: Bu en esnek seçenek olduğundan, potansiyel riskler de taşır. İhtiyatlı ve sadece kesinlikle gerekli olduğunda kullanın ve asla atlamayın Secure bağlanmak.
    • Örnek: Set-Cookie: third_party_widget_session=externalvalue; SameSite=None; Secure

Hangi SameSite Değer Seçmelisiniz? Aksi halde belirli bir neden yoksa, SameSite=Lax varsayılan olarak iyi bir uygulamadır. Son derece hassas operasyonları işleyen çerezler için, SameSite=Strict düşünülebilir. Siteler arası istekler için kesinlikle çerezler gerekiyorsa, SameSite=None; Secure uygun yaklaşımdır.

. Path Öznitelik, çerezin gönderileceği sunucudaki URL yolunu kısıtlar. Örneğin, Path=/admin sadece istekler için gönderilecek /admin ve onun alt dizinleri (örneğin, /admin/users). Gibi başka yollara istekler için gönderilmeyecek /dashboard veya kök (/).

Örnek (HTTP başlığı):

Set-Cookie: admin_session_token=secretadminstuff; Path=/admin; HttpOnly; Secure

Bu, gereksiz yere diğer uygulama bağlamlarına iletilmesini önleyerek çerezin maruziyetini en aza indirmeye yardımcı olur. Belirtilmezse, varsayılan yol, çerezi ayarlayan belgenin yoludur.

. Domain Özellik, çerezin gönderileceği ana bilgisayar (lar) ı belirtir. Ayarlanmışsa Domain=example.comçerez talep için gönderilecek example.com ve tüm alt alanları (örneğin, www.example.com– api.example.com). Eğer Domain Öznitelik atlanır, çerez yalnızca onu ayarlayan tam ana bilgisayara gönderilir (alt alanlar hariç).

Örnek (HTTP başlığı):

Set-Cookie: site_wide_preference=blue_theme; Domain=example.com

Aşırı geniş Domain ayarlar (örneğin, bir tld gibi .com) bir güvenlik riskidir ve tarayıcılar tarafından reddedilir. Ayrıca, Domain Öznitelik yalnızca geçerli ana bilgisayarın ana alanına ayarlanabilir; Tamamen farklı bir alana ayarlanamaz.

Bir son kullanma süresi belirleyerek çerez kalıcılığını yönetmek önemlidir. Bunun için iki özellik kullanılır: Expires Ve Max-Age.

  • Expires: Çerez süresinin ne zaman sona ereceğini (UTC’de) kesin tarih ve saati belirtir.

    • Örnek: Set-Cookie: legacy_cookie=data; Expires=Fri, 31 Dec 2025 23:59:59 GMT

  • Max-Age: Çerez sona erene kadar süreyi saniyeler içinde belirtir. Örneğin, Max-Age=3600 çerezin bir saat geçerli olduğu anlamına gelir. Max-Age öncelikli Expires. Eğer Max-Age 0 veya negatif bir değer olarak ayarlanır, çerez hemen silinir.

    • Örnek: Set-Cookie: short_lived_token=tempdata; Max-Age=3600

Eğer hiçbiri Expires ne Max-Age ayarlanmış, çerez bir oturum kurabiyesi ve tarayıcı kapatıldığında silinir. Ancak, tarayıcı ayarları oturumları (ve dolayısıyla oturum çerezlerini) geri yükleyebileceğinden, hassas bilgiler için açık, kısa bir son kullanma süresi belirlemek daha güvenli bir uygulamadır.

Sonuç: Katmanlı güvenlik anahtardır

Çerez güvenliği için çeşitli özellikleri ayrıntılı olarak araştırdık: HttpOnly– Secure– SameSite– Path– Domain– ExpiresVe Max-Age. Her özelliğin nasıl çalıştığını ve güvenlik avantajlarını anlamak çok önemlidir.

Çerez güvenliğinin çekirdeği, bu özellikleri kombinasyon halinde uygun şekilde kullanmaktır. Hiçbir tek ayar tüm tehditlere karşı savunamaz, bu nedenle web uygulamalarınızı ve kullanıcılarınızı korumak için her zaman derinlemesine bir savunma stratejisi düşünün.



Source link