HTTP Cookie Security

HTTP Cookie Security Aksiyonu Nedir?

HTTP Cookie Security aksiyonu, Kurum Servislerinden dönen yanıtlardaki çerezlere (cookies) güvenlik özniteliklerinin (attributes) otomatik olarak eklenmesini sağlar. Bu öznitelikler, çerezlerin kötüye kullanımını engelleyerek oturum güvenliğini artırır.

Bu aksiyon yalnızca yanıt (response) aşamasında çalışır ve yanıttaki Set-Cookie başlıklarına seçilen güvenlik özniteliklerini ekler.

ÖncesiSet-Cookie: sessionid=abc123; Path=/

SonrasıSet-Cookie: sessionid=abc123; Path=/; Secure; HttpOnly; SameSite=Strict

HTTP Cookie Security Aksiyonunun Önemi

Çerez güvenlik öznitelikleri, oturum hırsızlığı (session hijacking), cross-site scripting (XSS) ve cross-site request forgery (CSRF) saldırılarına karşı kritik koruma sağlar. Modern güvenlik standartları, tüm çerezlerde bu özniteliklerin kullanılmasını zorunlu kılar.

HTTP Cookie Security aksiyonu;

• Oturum çerezlerinin çalınmasını önler,
• XSS saldırılarında JavaScript ile çerez erişimini engeller,
• CSRF saldırılarına karşı koruma sağlar,
• Çerezlerin yalnızca güvenli bağlantı üzerinden iletilmesini garanti eder,
• Cross-site isteklerde çerez sızmasını engeller.

Bu nedenle HTTP Cookie Security aksiyonu, web uygulamalarının oturum güvenliğini sağlamak için kritik bir bileşendir.

Desteklenen Güvenlik Öznitelikleri

Bu aksiyon ile aşağıdaki çerez güvenlik öznitelikleri eklenebilir.

Öznitelik	Açıklama
Secure	Çerezin yalnızca HTTPS bağlantıları üzerinden gönderilmesini sağlar. HTTP üzerinden çerez iletimini engeller.
HttpOnly	Çereze JavaScript ile erişimi engeller. XSS saldırılarında çerez çalınmasını önler.
SameSite=Strict	Çerezin yalnızca aynı site içindeki isteklerde gönderilmesini sağlar. CSRF saldırılarına karşı en güçlü korumayı sunar.

Kullanılabildiği vService Tipleri

HTTP

L7 TCP

Network

Çalışma Anı

İstek Anı (On Request)

Cevap Anı (On Response)

Nasıl Eklenir?

Yeni bir HTTP Cookie Security Aksiyonu, TR7 web yönetim arayüzü üzerinden aşağıdaki adımlar izlenerek eklenebilir:

1. Sol altta bulunan TR7 logosuna tıklanarak Configuration Menu açılır.
2. Load Balancer → Actions → Add adımları takip edilir.
3. Aksiyon için benzersiz ve açıklayıcı bir isim girilir.
4. Action Type olarak HTTP Cookie Security seçilir.
5. Aksiyona ait ilgili konfigürasyonlar yapılandırılır.
6. Add butonuna tıklanarak aksiyon eklenir.

HTTP Cookie Security Aksiyonu Ekleme Formu

HTTP Cookie Security Aksiyonu Ekleme Formu

INFO

Action Name

Oluşturulacak olan aksiyona benzersiz ve açıklayıcı bir isim girilir.

INFO

Action Type

Aksiyon tipi olarak HTTP Cookie Security seçilir.

Bu aksiyon HTTP vService'lerde ve yalnızca yanıt aşamasında çalıştığından formda Execution Level ve Rule Protocol alanları yer almaz. Aksiyon sayaç desteklemez; Hit Counter ve Set Variable on Hit alanları da bulunmaz.

INFO

Cookie Security Options Zorunlu Varsayılan: Boş

Çerezlere eklenecek güvenlik öznitelikleri bu alandan seçilir. Birden fazla öznitelik aynı anda seçilebilir; form hiçbir seçenek işaretli olmadan açılır.

Seçilebilecek öznitelikler:

• Mark as Secure: Çerezin yalnızca HTTPS bağlantıları üzerinden gönderilmesini sağlar. HTTP üzerinden çerez iletimini engeller.
• Mark as HttpOnly: Çereze JavaScript ile erişimi engeller. XSS saldırılarında çerez çalınmasını önler.
• Mark as SameSite=Strict: Çerezin yalnızca aynı site içindeki isteklerde gönderilmesini sağlar. CSRF saldırılarına karşı en güçlü korumayı sunar.

En az bir öznitelik seçilmesi zorunludur; hiçbiri işaretlenmeden aksiyon eklenemez (En az 1 adet seçilmeli uyarısı verilir).

Seçim sırası korunur ve özniteliklerin çereze eklenme sırasını belirler.

Özniteliklerin Uygulanma Biçimi

Öznitelik	Mevcut değer varsa	Uygulanma koşulu
Secure	Başlık satırında secure ifadesi geçiyorsa öznitelik hiç eklenmez.	Yalnızca HTTPS üzerinden gelen isteklerin yanıtlarında eklenir.
HttpOnly	Başlık satırında httponly ifadesi geçiyorsa öznitelik hiç eklenmez.	Koşulsuz.
SameSite=Strict	Mevcut SameSite değeri kaldırılır ve yerine Strict yazılır.	Koşulsuz.

SameSite değeri ezilir

Kurum Servisi çerezi SameSite=Lax veya SameSite=None ile üretmiş olsa bile, bu seçenek işaretliyken değer korunmaz; her zaman Strict ile değiştirilir. Aksiyonun SameSite için değer seçtiren bir alanı yoktur.

Adında "secure" veya "httponly" geçen çerezler atlanır

Secure ve HttpOnly için yapılan "zaten var mı" denetimi, özniteliği değil başlık satırının tamamını tarar ve büyük/küçük harf ayrımı yapmaz.

Bu nedenle adında veya değerinde bu kelimeler geçen çerezler hiçbir zaman işaretlenmez: __Secure-SID=…, secure_token=…, insecure=0 çerezlerine Secure eklenmez; httponly_flag=… çerezine HttpOnly eklenmez. Tarayıcıların __Secure- ön ekli çerezler için Secure özniteliğini zorunlu tuttuğu düşünüldüğünde, bu çerezlerin uygulama tarafında doğru üretilmiş olması gerekir.

Aksiyon, yanıttaki tüm Set-Cookie başlıklarına uygulanır; belirli çerezleri adıyla hedefleyen bir alan bulunmaz.

Öznitelikler yanıt akışının en son aşamasında eklenir. Bu nedenle yalnızca Kurum Servisinden dönen çerezler değil, TR7'nin kendi ürettiği yanıtlardaki çerezler de kapsanır: bağlantı devamlılığı çerezi, CAPTCHA doğrulama çerezi, yönlendirme ve hata sayfası yanıtları.

Aksiyonun vService başına sayı sınırı yoktur; aynı vService'e birden fazla kez eklenirse SameSite=Strict özniteliği çereze iki kez yazılabilir.

INFO

Form Butonları

Add

Add butonuna tıklanarak aksiyon ekleme işlemi tamamlanır.

Add & Repeat

Add & Repeat butonu ile aksiyon ekleme işlemi tamamlanır ve farklı konfigürasyonlarla ilgili pencereden çıkılmadan yeni bir aksiyon daha eklenebilir.

Aksiyon Eklendi

WARNING

HTTP Cookie Security aksiyonu koşul gerektirmez ve tanımlandığı vService üzerinde koşulsuz (Always) olarak uygulanır.

Koşulsuz çalışan aksiyonlar, trafik içeriğine bağlı değerlendirme yapmadan, ilgili vService üzerindeki tüm trafiği veya davranışı doğrudan etkiler.

Canlı ortamlarda, bu tür aksiyonların devreye alınması öncesinde hedef servis davranışlarının ve olası etkilerin dikkatle değerlendirilmesi önerilir. Aksi durumda, beklenmeyen servis davranışları veya operasyonel sorunlar oluşabilir.

Operasyonel ve Güvenli Kullanım Önerileri

• Secure Özniteliği Yalnızca HTTPS'te Eklenir. Mark as Secure işaretli olsa dahi öznitelik, yalnızca HTTPS üzerinden gelen isteklerin yanıtlarına eklenir; şifresiz HTTP üzerinden gelen isteklerin yanıtlarına eklenmez. TLS sonlandırması yapmayan bir vService'te seçenek işaretli görünür ancak hiçbir çereze Secure uygulanmaz. Bu nedenle seçenek, HTTPS yapılandırması tamamlanmış vService'lerde anlamlıdır.
• Karma HTTP/HTTPS Yayında Oturum Kopabilir. Secure işaretli bir çerez, tarayıcı tarafından şifresiz HTTP bağlantılarında hiç gönderilmez. Aynı uygulama hem HTTP hem HTTPS üzerinden yayınlanıyorsa HTTP tarafındaki oturum kopar; bu durumda önce Redirect to HTTPS ile tüm trafik HTTPS'e taşınmalıdır.
• LB Çerezlerinin de Etkilendiğini Unutmayın. Öznitelikler bağlantı devamlılığı ve CAPTCHA çerezlerine de uygulanır; SameSite=Strict seçilmesi, dış sitelerden dönen akışlarda devamlılık çerezinin gönderilmemesine ve isteğin başka bir Kurum Servisine düşmesine yol açabilir.
• HttpOnly Her Zaman Önerilir. Oturum çerezleri için HttpOnly özniteliği her zaman etkinleştirilmelidir. Bu, XSS saldırılarında çerezlerin JavaScript ile çalınmasını önler.
• SameSite=Strict Dikkatli Kullanılmalı. SameSite=Strict en güçlü CSRF korumasını sağlar, ancak bazı senaryolarda sorun yaratabilir: harici sitelerden gelen linkler çerez göndermez, OAuth/SSO akışları etkilenebilir, ödeme entegrasyonları çalışmayabilir. Bu durumlar söz konusuysa, uygulamanın SameSite=Lax veya SameSite=None kullanması gerekebilir. Bu aksiyon Strict değerini kullandığından, özel değerler için Replace HTTP Header Content aksiyonu kullanılabilir.
• Tüm Öznitelikleri Birlikte Kullanın. Maksimum güvenlik için tüm özniteliklerin birlikte kullanılması önerilir: Secure (HTTPS zorunluluğu), HttpOnly (JavaScript koruması), SameSite=Strict (CSRF koruması).
• Test ortamında doğrulanır. Özellikle SameSite=Strict, bazı uygulamalarda beklenmeyen davranışlara neden olabilir; canlı ortama alınmadan önce tüm kullanıcı akışları test edilir.

Canlı Ortamlarda Yaygın Kullanım Senaryoları

Aşağıdaki örnekler, ilgili aksiyonun gerçek sistemlerde en sık karşılaşılan kullanım senaryolarında nasıl uygulandığını göstermektedir. Bu senaryolar, canlı ortamlarda yaygın olarak tercih edilen ve sahada edinilmiş deneyimlere dayanan pratikleri temel alır.

Senaryo 1: Bankacılık/E-Ticaret Uygulaması Maksimum Güvenlik

Problem: Bankacılık uygulaması oturum çerezlerini (SESSIONID) güvenlik öznitelikleri olmadan gönderiyor. Kullanıcılar man-in-the-middle saldırılarına, XSS ile çerez çalınmasına ve CSRF saldırılarına açık durumda.

Çözüm: Tüm güvenlik özniteliklerini (Secure, HttpOnly, SameSite=Strict) aktif ederek maksimum oturum güvenliği sağlayın.

Konfigürasyon:

• Cookie Security Options:
  • Mark as Secure ✓
  • Mark as HttpOnly ✓
  • Mark as SameSite=Strict ✓

Sonuç:

• ✅ HTTPS zorunluluğu → Çerezler sadece HTTPS üzerinden iletilir, HTTP'de çalışmaz.
• ✅ XSS koruması → JavaScript ile document.cookie erişimi engellenir, çerez çalınamaz.
• ✅ CSRF koruması → Cross-site isteklerde çerez gönderilmez, CSRF saldırıları başarısız olur.
• ✅ Güvenlik standartları → PCI-DSS, OWASP gereksinimlerini karşılar.

Senaryo 2: HTTP'den HTTPS'e Geçiş Sonrası Güvenlik

Problem: Web sitesi HTTP'den HTTPS'e geçti ancak Kurum Servisi hala çerezleri güvenlik özniteliği olmadan gönderiyor. Kullanıcılar HTTP'ye downgrade edilerek çerezleri çalınabiliyor (SSL stripping saldırısı).

Çözüm: Secure özniteliğini ekleyerek çerezlerin sadece HTTPS üzerinden iletilmesini zorunlu kılın.

Konfigürasyon:

• Cookie Security Options:
  • Mark as Secure ✓

Sonuç:

• ✅ HTTPS zorunluluğu → HTTPS üzerinden verilen çerezler Secure ile işaretlenir ve tarayıcı bunları yalnızca HTTPS bağlantılarında gönderir.
• ✅ SSL stripping koruması → HTTPS üzerinden verilmiş bir çerez, bağlantı HTTP'ye düşürülse bile tarayıcı tarafından gönderilmez.
• ✅ Aşamalı geçiş → Diğer öznitelikler (HttpOnly, SameSite) sonra eklenebilir.
• ❌ HTTP üzerinden gelen istekler → Bu isteklerin yanıtlarına Secure eklenmez; koruma yalnızca HTTPS üzerinden verilen çerezler için geçerlidir. Sitenin tamamının HTTPS'e taşınması (ör. Redirect to HTTPS) bu boşluğu kapatır.

Senaryo 3: XSS Zafiyeti Olan Legacy Uygulama Koruması

Problem: Eski PHP uygulamasında XSS (Cross-Site Scripting) zafiyeti var ve kodu hemen düzeltmek mümkün değil. Saldırganlar JavaScript ile oturum çerezlerini çalarak kullanıcı hesaplarına erişebiliyor.

Çözüm: HttpOnly özniteliği eklenerek JavaScript'in çerezlere erişimi engellenir ve XSS etkisi azaltılır.

Konfigürasyon:

• Cookie Security Options:
  • Mark as HttpOnly ✓

Sonuç:

• ✅ XSS koruması → JavaScript ile document.cookie çalışmaz, çerez okunamaz.
• ✅ Oturum çalma engellenir → XSS zafiyeti olsa bile oturum çerezleri çalınamaz.
• ✅ Kod değişikliği yok → Kurum Servisinde hiçbir değişiklik yapmadan güvenlik artırılır.
• ❌ XSS saldırısı → Hala sayfa içeriğini manipüle edebilir ama çerez çalamaz.

Senaryo 4: CSRF Saldırılarına Karşı Cookie Seviyesinde Koruma

Problem: E-ticaret sitesinde CSRF token mekanizması yok. Saldırganlar kullanıcıları kötü niyetli sitelere yönlendirerek onların oturumunu kullanarak istem dışı işlem yaptırabiliyor (CSRF saldırısı).

Çözüm: SameSite=Strict özniteliği eklenerek cross-site isteklerde çerez gönderimi engellenir.

Konfigürasyon:

• Cookie Security Options:
  • Mark as SameSite=Strict ✓

Sonuç:

• ✅ CSRF koruması → Cross-site isteklerde çerez gönderilmez, CSRF saldırıları başarısız olur.
• ✅ Third-party engelleme → Harici sitelerden gelen istekler oturum bilgisi taşımaz.
• ⚠️ OAuth/SSO dikkat → Harici linklerden gelen kullanıcılar oturum bilgisini kaybedebilir.
• ⚠️ Payment gateway → Ödeme entegrasyonları etkilenebilir, test edilmeli.