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

   Haziran 22, 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.

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.

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.

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.

Tüm güvenlik özellikleri doğru yapılandırılmış olsa bile, kötü amaçlı yazılım veya kimlik avı saldırıları yoluyla çerez hırsızlığı riski vardır. Bu nedenle, potansiyel olarak çalınan çerezleri tanımlamak için tespit mekanizmalarının uygulanması kapsamlı güvenlik için çok önemlidir.

Çevre Tabanlı Tespit

Kullanıcı Çevre Bilgilerini Saklayarak bir oturum kurulduğunda, oturum kaçırmayı gösterebilecek şüpheli değişiklikleri tespit edebilirsiniz:

  • IP Adresi Değişikliği: IP adresi veya coğrafi konumundaki önemli değişiklikler oturum kaçırma gösterebilir. Örneğin, New York’tan tipik olarak oturum açan bir kullanıcı, sitenize farklı bir ülkeden aniden erişiyor gibi görünüyorsa.
  • Kullanıcı-Ajan Değişikliği: Aynı çerez ile istek gönderen farklı tarayıcılar veya cihazlar.
  • Dil Tercihi Değişikliği: Ani değişiklikler Accept-Language başlık.
  • Erişim Zamanı Desenleri: Belirli bir kullanıcı için olağandışı saatlerde etkinlik.

Örnek Uygulama (Sunucu tarafı):

// When creating a session
session.save({
  ip: request.clientIP,
  userAgent: request.headers.userAgent,
  language: request.headers.acceptLanguage,
  // Additional environment information
});

// On subsequent requests
if (hasSignificantEnvironmentChange(session, request)) {
  // Take action - trigger additional verification
}

Riske dayalı oturum doğrulaması

Şüpheli aktivite tespit edildiğinde, dereceli yanıt mekanizmaları uygulayın:

  • Düşük risk: İnsan etkileşimini doğrulamak için bir captcha görüntüleyin
  • Orta risk: Ek Doğrulama İsteyin (Güvenlik Sorusu, E -posta Doğrulama Kodu)
  • Yüksek risk: Tam kimlik bilgileri ve potansiyel olarak 2FA ile yeniden kimlik doğrulaması
  • Kritik risk: Oturumu hemen geçersiz kılın ve alternatif kanallar aracılığıyla kullanıcıyı bilgilendirin

Güvenliği kullanıcı deneyimi ile dengelemek önemlidir – birçok doğrulama talebi meşru kullanıcıları hayal kırıklığına uğratabilir. Yalnızca ödeme işleme, hesap ayarları değişiklikleri veya şifre güncellemeleri gibi hassas işlemler için riske dayalı doğrulamayı uygulamayı düşünün.

Cihaza bağlı oturum kimlik bilgileri

Çerez hırsızlığını azaltmaya umut verici bir yaklaşım, cihaza bağlı oturum kimlik bilgilerini kullanmaktır. Bu teknik, kriptografik yollarla oturum çerezlerini belirli cihaza bağlar:

  • Tarayıcı, oturum açma sırasında bir kamu-özel anahtar çifti oluşturur
  • Oturum bu anahtar çifte kriptografik olarak bağlı
  • Çerez çalınsa bile, saldırgan orijinal cihazda güvenli bir şekilde saklanan özel anahtar olmadan kullanamaz

Bu teknoloji hala gelişiyor ve henüz yaygın olarak desteklenmese de, basit taşıyıcı jetonlarından gönderen kısıtlamalı jetonlara çerezleri değiştirdiği için güvenli oturum yönetimi için gelecekteki yönü temsil ediyor.

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-Ageayrıca çerez hırsızlığını tespit etmek ve azaltmak için gelişmiş teknikler. Her güvenlik önleminin nasıl çalıştığını ve faydalarını anlamak çok önemlidir.

Çerez güvenliğinin çekirdeği bu korumaların kombinasyon halinde uygun şekilde kullanılmasında yatmaktadı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. Çerez özniteliklerini doğru bir şekilde yapılandırmanın yanı sıra, sunucu tarafı algılama mekanizmalarının uygulanması, önemli bir ek güvenlik katmanı sağlar.



Source link