Çerez işlemek mayın tarlasıdır

 (grayduck.mn)
3 puan yazan GN⁺ 2024-11-22 | 1 yorum | WhatsApp'ta paylaş
  • HTTP çerezleri web’de durumu korumanın temel mekanizmasıdır, ancak tarayıcılar, sunucular ve standart kütüphaneler izin verilen karakterler ve hata işleme konusunda farklı davrandığından gerçek kesintilere yol açabilir
  • RFC 6265 ailesinde sunucunun gönderdiği Set-Cookie değerleri ile tarayıcının kabul ettiği değerlerin koşulları farklıdır; document.cookie ile oluşturulan değerler sunucu tarafı ayrıştırıcıların varsayımlarıyla çakışır
  • Firefox, Chromium ve Safari boşluk, tırnak, virgül, ters eğik çizgi ve Unicode işleme konusunda birbirinden farklıdır; Safari yasaklı bir karakterle karşılaştığında çerezin tamamını değil, yalnızca baştaki kısmını kaydetme davranışı gösterir
  • Go, tarayıcının kabul ettiği JSON çerezlerini sessizce atlayabilir; Python SimpleCookie anlayamadığı bir çerezden sonraki yüklemeyi durdurabilir; PHP, Ruby ve Rust’ta da izin verilen aralıklar birbirinden farklıdır
  • Tek bir Unicode çerezi Facebook, Netflix, Okta, WhatsApp, AWS, Apple Support gibi büyük sitelerde 400/500 hatalarına veya kısmi arızalara neden olabilir; bu yüzden çerez spesifikasyonu ile kütüphane davranışlarının daha net uyumlu hale getirilmesi gerekir

Tarayıcının kabul ettiği ama Go’nun okuyamadığı çerez

  • Çerezler, JavaScript’te document.cookie veya bir HTTP sunucusu tarafından ayarlanan verilerdir; süresi dolana kadar kapsamı uyan HTTP isteklerine eklenmeye devam ederler
  • Örnek JavaScript, JSON dizesini olduğu gibi oturum çerezi değeri olarak kaydeder
    • Değer {"ginger":"snap","peanutButter":"chocolate chip","snicker":"doodle"} biçimindedir
    • JSON’u çereze koyarken çoğu zaman base64 serileştirme yapılır, ancak tarayıcı bu değeri sorunsuzca ayarlar ve Cookie başlığıyla gönderir
  • Bu çerez Go standart kütüphanesini kullanan koda iletildiğinde sorun ortaya çıkar
    • Go ayrıştırıcısı bu çerezi yorumlayamaz
    • Hata, çağrı yığınının üst katmanlarına zincirleme yayılır

RFC içindeki iki ölçüt uyuşmuyor

  • Çerezler RFC 2109, RFC 2965, RFC 6265 üzerinden tanımlanmıştır ve şu anda güncellenmekte olan bir taslak sürüm vardır
  • RFC, çerez değerlerini iki alanda farklı ele alır
    • Section 4.1.1, sunucunun Set-Cookie ile gönderdiği değerlerde kontrol karakterlerini, boşluğu, çift tırnağı, virgülü, noktalı virgülü, ters eğik çizgiyi vb. hariç tutar
    • Section 5.6, tarayıcının Set-Cookie dizesini ayrıştırırken kontrol karakterleri dışında çok daha geniş bir aralığı kabul etmesine izin verir
  • Temel çatışma, sunucunun göndermesi gereken değerler ile tarayıcının kabul etmesi gereken değerlerin hizalı olmamasıdır
    • Tarayıcı yalnızca sunucunun bizzat ayarladığı çerezleri kabul etseydi etkisi küçük olurdu, ancak document.cookie de çerez oluşturabilir
    • Standart, Cookie başlığını işleyen standart kütüphanelerin kullanıcı ajanı gibi hoşgörülü mü, yoksa sunucu gibi katı mı olması gerektiğini net biçimde belirlemez

Tarayıcılara göre çerez değeri kabul farkları

  • Firefox

    • Firefox’un çerez değeri denetimi, RFC 6265’in yasakladığı bazı karakterlere izin verir
    • İzin verilen, RFC’nin dışlanmasını önerdiği karakterler şunlardır
      • 0x09 yatay sekme
      • 0x20 boşluk
      • 0x22 çift tırnak
      • 0x2C virgül
      • 0x5C ters eğik çizgi
    • Bu davranış geçmişte Chrome ile uyumluluğu sağlamak için eklenmiş ve iki kod tabanında da kalmıştır
    • network.cookie.blockUnicode ayarı 0x80 ve üzerindeki değerleri reddedebilir; ilgili çalışma bug 1797231 altında izlenir
    • 0x7F’e izin verilmesi sorunu bug 1797235 ile Firefox 108’de düzeltilmiştir

  • Chromium

    • Chromium çerez değerlerinde yalnızca kontrol karakterlerini ve noktalı virgülü reddeder
    • Firefox’tan biraz daha katıdır; 0x09 yatay sekmeyi kabul etmez
    • RFC’den farklı olarak boşluk, çift tırnak, virgül, ters eğik çizgi ve Unicode karakterleri kabul edip yeniden gönderebilir

  • Safari / WebKit

    • Safari’nin çerez saklama kodu kapalı kaynaklı CFNetwork içinde olduğu için doğrudan doğrulamak zordur
    • JavaScript ile 0x00’dan 0xFF’e kadar çerez değerleri ayarlanarak yapılan kontrolde Safari’nin şu değerleri kabul ettiği görüldü
      • 0x09 yatay sekme
      • 0x20 boşluk
      • 0x22 çift tırnak
      • 0x5C ters eğik çizgi
    • Safari 0x7F delete ile 0x80-FF high ASCII / Unicode karakterlerine izin vermez
    • RFC, kontrol karakteriyle karşılaşınca çerezin tamamının yok sayılmasını söyler; Safari ise yasaklı karaktere kadar olan değeri kabul eder
    • -- , -- değeri ayarlandığında virgül çevresindeki boşluğu kaldıran bir Safari hatası da gözlemlenmiştir

Diller ve standart kütüphaneler arasındaki ayrıştırma farkları

  • Go

    • Go’nun çerez kodu, sunucunun Set-Cookie ile gönderdiği değerlere ilişkin RFC ifadesine nispeten yakın davranır
    • Gerçek kullanımda yaygın olan boşluk ve virgüle izin verir, ancak çift tırnak, noktalı virgül ve ters eğik çizgiye izin vermez
    • Örnek Cookie başlığında JSON çerezi yer alırsa Go’nun request.Cookies() sonucunda yalnızca cookie1=foo ve cookie3=bar kalır
    • Tarayıcının kabul ettiği cookie2, istisna veya açık hata olmadan sessizce çıkarılır

  • PHP

    • PHP’de yerel bir çerez ayrıştırma fonksiyonu olmadığı için izin verilen aralığı kesin olarak söylemek zordur, ancak test sonuçlarına göre kontrol karakteri işleme davranışı tutarlı değildir
    • 0x00-0x09 ve 0x0D carriage return gibi değerler çalışır
    • 0x10 data link escape veya 0x7F delete kullanıldığında PHP 400 Bad Request hatası verir
    • Unicode çerezler de test çıktısında görünür

  • Python

    • Python’un http.cookies.SimpleCookie sınıfı bir JSON çereziyle karşılaştığında sonraki çerezlerin yüklenmesini sessizce durdurur
    • Örnek girdide çıktıda yalnızca cookie1=foo kalır
    • Bir alt alan adı temel alan adına sorunlu bir çerez ayarlayabiliyorsa, tek bir çerez tüm sitenin çerez işlemesini bozabilir
    • Kontrol karakterlerinin işlenmesi de düzensizdir
      • Bazı kontrol karakterleri boş değer olarak yüklenir
      • Değerin başına ve sonuna aa eklenirse kontrol karakteri içeren çerez yüklenmez

  • Ruby

    • Ruby’nin CGI::Cookie.parse fonksiyonu ayrıştırma sırasında oldukça hoşgörülü davranıyor gibi görünür
    • Kontrol karakterlerini, sekmeyi, çift tırnağı, virgülü, ters eğik çizgiyi, 0x7F’i ve Unicode karakterleri kabul eder; çerez jar’ından çıkarırken percent-encoding uygular
    • Bu yaklaşım çerez dünyasında optimale yakın olabilir, ancak document.cookie ile ayarlayan kod percent-encoding uygulanmış yansıyan değer beklemiyor olabilir

  • Rust

    • Rust varsayılan çerez işleme özelliği sunmadığı için popüler cookie crate’i temel alınarak kontrol edilmiştir
    • Varsayılan ayarlarla cookie crate’i en hoşgörülü tarafa yakındır ve iletilen UTF-8 dizesini kabul ediyor gibi görünür

Gerçek web sitelerinde ortaya çıkan etki

  • Bu sorun, test sitesinde üçüncü taraf kütüphane güncellemesi elle doğrulanırken keşfedildi
    • Otomatik testlerde yakalanması zor bir değişiklikti
    • Olduğu gibi dağıtılsaydı sonraki ziyaretçiler bozuk bir çerez alabilir ve güncelleme geri alınana ve çerez silinene kadar nedeni belirsiz hatalarla kilitlenebilirdi
  • Bu sorun küçük sitelerle veya belirli bir framework ile sınırlı değildir
  • Tarayıcı konsolundan aşağıdaki gibi alan adına Unicode çerezi ayarlandığında birçok büyük site bozulabilir
    • document.cookie="unicodeCookie=🍪; domain=.grayduck.mn; Path=/; SameSite=Lax"
  • Gözlemlenen örnekler şöyledir
    • Facebook: Hata sayfası gösterilir ve görseller de bozulur
    • Instagram ve Threads: Basit bir 500 hatası oluşur
    • Netflix: NSES-500 hatası döndürür ve yardım sayfası da bozulur
    • Okta: Tüm giriş sayfaları 400 hatası döndürür
    • WhatsApp: “whatsapp error” gösterilir
    • Amazon: Çoğu şey çalışır, ancak bazı özellikler rastgele bozulur
    • AWS: Giriş konsolu 400 hatası döndürür ve kesilir
    • Apple Support: Cihaz listesini yükleyemez
    • Best Buy: Navigasyon çalışır, ancak arama işlevi çalışmaz
    • eBay: Çoğu düzeltilmiştir, ancak bazı kısımlar hâlâ 400 hatası verir
    • Home Depot: Düzeltilmesi planlanıyor
    • Intuit: Hatanın nedenini tespit eden tek site
    • Outlook: Başka bir 400 hatası örneği görülür

Standartlar ve uyumluluk arasındaki düzeltme zorluğu

  • 30 yıllık temel bir spesifikasyondaki sorunu düzeltmek çok zordur ve bu sorun için iyi bir çözüm bulunmama ihtimali yüksektir
  • Tarayıcı tarafında bu tür çerezleri engelleme seçeneği hem Mozilla hem de Google tarafından incelenmiş ve üzerinde çalışılmıştır
  • Tek taraflı engelleme uyumluluk sorunları nedeniyle karmaşıktır
    • ASCII olmayan çerezler, tüm çerezlerin %0,01’inden azı düzeyinde yaygın değildir
    • Telemetry verileri Argentina, Mexico, Finland gibi ülkelerde çok daha sık görüldüğünü gösterir
    • Mozilla hızlıca açılabilecek network.cookie.blockUnicode ayarını uygulamıştır, ancak Chromium ile davranış uyumluluğu sorunları nedeniyle etkinleştirmemiştir
  • Sunucu tarafında düzeltme de mümkün olabilir, ancak bu milyonlarca web sitesine ve diller ile framework’lerin iç hata işleme davranışlarına yayılır
    • Facebook veya Netflix gibi yerler bunu hafifletebilir, ancak ortalama bir site işletmecisinin çözmek için zamanı veya yetkinliği olması zordur
  • Temel çözüm, IETF HTTP Working Group’un çerez spesifikasyonunu kendi içinde hizalaması ve çerez işleme sistemlerinin nasıl davranması gerektiğini katı biçimde belirlemesidir
    • ASCII dışı karakterlere izin verilip verilmeyeceği sunucu tarafında ve kullanıcı ajanlarında aynı olmalıdır
    • Tarayıcıların, dillerin ve framework’lerin çerezleri işleme adımları da Content Security Policy gibi modern W3C standartlarında olduğu gibi açıkça belirtilmelidir
    • Hatalı tek bir çerez yüzünden diğer çerezlerin işlenmesinin de durması, çeşitli beklenmedik arızalara yol açabileceğinden kabul edilmesi zordur

Önerilen çerez işleme prosedürü

  • field-value ile başlayıp ; ve , üzerinden bölerek raw-cookie-pair listesi oluşturulur; ancak virgül noktalı virgülün eş anlamlısı olarak ele alınmaz
  • Her raw-cookie-pair şu sırayla işlenir
    • = yoksa sonraki pair’e geçilir
    • Baştaki ve sondaki boşluklar kaldırılır
    • İlk = işaretinden öncesi cookie-name-octets, sonrası cookie-value-octets olarak ele alınır
    • Değer çift tırnakla başlıyorsa baştaki bir çift tırnak kaldırılır; sonda çift tırnak varsa bir tane kaldırılır
    • Ad veya değer sunucunun kabul edemeyeceği biçimdeyse ilgili pair atlanır
    • Kalan [cookie-name-octets, cookie-value-octets] tuple’ı sunucunun tanımladığı yöntemle işlenir
  • Sunucular için ayrıca çerez adı token olmayan tuple’ların reddedilmesi ve çerez değeri cookie-octet içinde olmayan octet içeriyorsa reddedilmesi yönünde öneri yapılır

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-22
Hacker News görüşleri

  • Çerezler garip tuzaklar ve rahatsız edici davranışlarla dolu, ama %99,95 oranında düzgün çalışıyor. En sevdiğim çerez mayın tarlası cookie shadowing; aynı adla, sadece domain ve path gibi temel öznitelikleri farklı olacak şekilde çerez ayarlarsanız, neredeyse aynı birden fazla çerez aynı anda oluşuyor ve backend ya da JS tarafında hangisinin hangisi olduğunu ayırt etmenin bir yolu yok.
    https://example.com/somepath adresine gidip tarayıcı konsoluna aşağıdakileri girmeniz yeterli.
    document.cookie = "foo=a";
    document.cookie = "foo=b; domain=.example.com";
    document.cookie = "foo=c; path=/somepath";
    document.cookie
    Bende sonuç 'foo=c; foo=a; foo=b' oldu.

    • Şirkette bunu kimin tasarladığını bilmiyorum ama staging ve geliştirme ortamlarını aynı domain altında tutmuşlar ve koca şirket bu kalıbı takip ediyor.
      Gerçekten inanılmaz büyük bir hata.
    • Aynı tarayıcıda bir web sitesinde birden fazla hesap kullanırken görülen tuhaf davranışların önemli bir kısmı bununla açıklanabilir gibi geliyor.
    • /somepath altındaysanız üç değer içinden en spesifik olan C’yi almak oldukça mantıklı görünüyor. Tüm değerler sırayla döndüğü için, hem path’e özel değeri hem de global değeri görebiliyorsunuz; bu da en iyi uzlaşma gibi hissettiriyor.
      Yine de o sihirli document.cookie setter’ını hiç sevmiyorum ama artık neredeyse 30 yıllık bir şey olduğu için yapacak bir şey yok.
    • Bu arada teknik olarak domain başındaki nokta izinli değil ve yok sayılıyor: https://www.rfc-editor.org/rfc/rfc6265#section-4.1.2.3
      jshttp/cookie tarafında doğrulama yakın zamanda sıkılaştırılınca bu konu yeniden gündeme geldi: https://github.com/jshttp/cookie/pull/167
      O PR’den sonra doğrulama, yazıda bahsedilen tarayıcı koduna benzer şekilde yeniden biraz gevşetildi.
      İlk değişiklik, bizim kodda encoding yapmadan string’leri birleştirerek cookie header oluşturan bir bug bulmamızla başladı. Bazen değerde boşluk oluyordu ve istek bozuluyordu; bunu önlemek için geliştiricilere jshttp/cookie’nin serialize() fonksiyonunu kullanmalarını önermeyi düşünüyorduk ama bu fonksiyonun doğrulamasının gördüğümüz bug’ı yakalamak için yeterli olmadığını fark ettik.
      Bir yama önerince başka biri, doğrulamanın fazla gevşek olması nedeniyle çerezin name alanına JS enjekte edilebildiğini ve başka bir yerde bunun value olarak yorumlanabildiğini fark etti. Oldukça sıra dışı bir kod enjeksiyonu yolu ortaya çıkıyordu.
    • Evet, gerçekten çok fazla tehlike noktası var. https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng bu sorunu ve bağlantılı baş ağrılarını ayrıntılı biçimde ele alıyor.

  • Yazı Rust yaklaşımından söz ediyor ama diğer dillerin aksine Rust standart kütüphanesinde çerez işleme yer almıyor. Aslında bakılan şey üçüncü taraf cookie crate’inin davranışı ve Ruby’de olduğu gibi percent-encoding seçeneği de içeriyor: https://docs.rs/cookie/0.18.1/cookie/

    • İyi bir adı erkenden kapıp fiilen standartlaşma yöntemi bu.

  • HTTP protokolünün içinde fiilen birbirinden farklı on bin kadar protokol gömülü gibi duruyor. Tarayıcılar ve web sunucuları türlü türlü özellik ekledi; her birinin hem spesifikasyonu hem de fiili spesifikasyonu var ve bunların hepsi neredeyse tek bir genel amaçlı HTTP şemsiyesi altında taşınıyor.
    İstemcinin bu on bin gayriresmî protokolün hangi sürümüyle uyumlu olduğunu belirtmesinin bir yolu yok, sunucunun da yok. Spesifikasyonları yükseltemiyorsunuz çünkü geri kalan istemciler bunu anlamıyor ve geriye dönük uyumluluk da yok.
    Sonuçta kimsenin üzerinde anlaşamadığı ve düzeltemediği rastgele bir kaos kalmış durumda. Planlı kullanım dışı bırakma da olmadığı için geçmişteki kötü kararları taşımaya devam etmek zorundayız.

    • Anlamadıkları protokolleri engelleyen berbat middleware cihazları da bunun sebeplerinden biri. “Varsayılan olarak başarısızlığa zorlamak daha güvenlidir” mantığıyla hareket ettikleri için, artık sonsuza dek tüm yeni uygulama trafiğinin gerçek internette çalışabilmesi için HTTP üzerinden tünellenmesi gerekecek.
    • Açıkçası artık bu dünyayla barıştım ve planlı kullanım dışı bırakmaların olduğu bir dünyadan daha az sevdiğimi de sanmıyorum.
    • Tekelci şirketlerin tertemiz spesifikasyonlar koyup istedikleri zaman zorla kullanım dışı bırakma dayatamamasını istiyorsanız, bunun bedeli olarak anarşiyi kabullenmeniz gerekiyor.

  • Yaklaşık 10 yıl önce bir projede çerez tabanlı oturum uygulamıştım ve kimlik doğrulamanın Safari’de çalışıp Chrome’da çalışmamasının nedenini debug etmek gerçekten çok uğraştırmıştı. Tam olarak hangisi olduğunu hatırlamıyorum ama tarayıcılardan biri biçim yanlışsa çerezi hiç ayarlamıyordu.
    Özellikle tuhaf bir şey de yapmamıştık; aklımda kaldığı kadarıyla mesele - ile _ farkıydı.

    • Safari ile Chrome arasında büyük/küçük harf duyarlılığı farkı varmış gibi hatırlıyorum. Belki de Set-Cookie header’ındaydı.
      Bir zamanlar bu yüzden çerez anahtarlarında camelCase kullanamadığımız olmuştu.
      Arayınca da tam sorunu pek bulamıyorum.

  • Çerezler ortaya çıktığından kısa süre sonra, makul kullanımın sadece opaque token koymak ve sunucunun bir dahaki sefere bunun aynı istemci olduğunu anlamasını sağlamak, geri kalan her şeyi de sunucu tarafında tutmak olduğu düşünülüyordu sanırım.
    İstemcinin prensip olarak sunucunun asla göndermeyeceği değerleri işleyebilmesinin neden sorun olduğunu anlamıyorum. Böyle değerleri göndermeyin yeter; “bunu gönderirse ne olur?” gibi bilmecelerle uğraşmaya gerek yok.

    • Çerezler eski bir teknoloji. Web’in hâlâ genç olduğu 90’larda ilk eklenen şeylerden biriydi ve kötü fikirler birkaç kez tekrarlandı.
      Yine de opaque token saklayabileceğiniz tek yer olduğu için kimlik doğrulamada kullanmak zorundasınız.

  • Çerez başlığını ayrıştırma tam bir karmaşa. “Standart”, sahada gerçekten var olan davranışları yansıtmıyor; backend sunucusu, kütüphane ve framework’lerin kabul ettiği biçimler birbirinden farklı, tarayıcılar da bambaşka şeyler yapıyor
    Frontend ve backend’i tamamen kontrol ediyorsanız büyük bir sorun olmayabilir, ama farklı şeyleri birbirine bağlamanız gereken anda durum çok hızlı biçimde saçmalaşıyor

  • Çerezler büyük ve karmaşık bir keşmekeş gibi görünüyor, üstelik geriye dönük uyumluluk yüzünden neredeyse değiştirmek de imkânsız. Böyle durumlarda tamamen ayrı yeni bir mekanizma yapmak daha doğru olmaz mı diye düşündürüyor
    Örneğin NewCookie gibi bir mekanizma yeni baştan tanımlanıp en baştan tutarlı çalışacak şekilde yeniden tasarlanabilir. Modern güvenlik önlemleri yerleşik gelir, daha katı bir spesifikasyon ve düzgün Unicode desteği de eklenebilir

    • NewCookie’den söz edilmesi komik, çünkü gerçekte zaten kullanımdan kalkmış bir Set-Cookie2 başlığı var: https://stackoverflow.com/q/9462180/3474615
    • NewCookie kabaca tarayıcı Local Storage’a karşılık geliyor
      En azından bazı kullanım senaryolarında öyle; tabii başlıklarla doğrudan entegre değil
    • Asıl sorun, çerezlerin takip ile fazla derinden iç içe geçmiş olması gibi görünüyor. Şimdi daha iyi bir çerez yapmaya kalkarsanız, böyle bir kavramın var olmasını bile istemeyen gizlilik savunucularının engeline takılmanız çok olası
      Çerezler zaten var olduğu için biz de çerezlere bağlı kalıyoruz
    • İstemci tarafı durumu saklamak için en güvenli yer DOM ve URL. Her kullanım senaryosunu kapsamaz ama örneğin e-postadaki ön onay bağlantısına tıklanan alan gibi durumları kapsar
      Müşterilerin kontrol ettiği alan adlarındaki çerezleri iOS Safari’nin rastgele yutması sorununu kovalamakla tam bir ay harcadım. Google, Twitter, Facebook gibi alan adlarında oturum durumunun böyle kaybolduğunu hiç görmedim
    • İsminin NewCookie’den daha iyi olması gerekir. SuperCookie, UltraCookie, BetterCookie gibi öneriler de yapılabilir
      Biraz daha ciddi söylersek, cookie kelimesinden kaçınıp tamamen başka bir ad vermek daha iyi olur. cookie sözcüğü fazla yük taşıyor

  • Yazarın işe JSON.stringify sonucunu çereze koyarak başlamış olması, sorunun birinin string’e çevrilen JSON içine noktalı virgül koymasından kaynaklanmaması açısından daha da şaşırtıcı
    Çerezlerle ilgili dertlerin çoğu, rastgele kullanıcı girdisini çereze koymaya çalıştığınızda çıkıyor gibi görünüyor. Bunu yapmamalısınız. Kimlik doğrulama token’larında olduğu gibi yalnızca sabit uzunlukta alfasayısal ASCII dizeleri kullanırsanız sorun olmaz

  • Bunun epey büyük bir mayın tarlası olduğuna katılıyorum
    Geliştirici olarak etrafından dolanma yöntemi, değeri URL güvenli Base64 ile kodlamak. Böylece ham bayt değerlerini elde eder, iç temsili de istediğiniz gibi kullanabilirsiniz. Ama yazıda da dendiği gibi, bu %100 kontrol edebildiğiniz bir şey değil. Sonuçta bunlar kullanıcı aracısı ve öyle olmaları da gerekiyor
    Keşke daha fazla kullanıcı aracısı, “hat üzerindeki baytlar ve dua” yaklaşımı yerine standartlara uyumu seçseydi. Ekran görüntüsündeki 400 yanıtları spesifikasyona uygun yanıtlar. Başlıklar en baştan UTF-8 olsaydı ya da önce ASCII olup sonradan UTF-8’e izin verilseydi daha iyi olabilirdi. Gerçi ilki nedensellik açısından zor, ikincisi de başlangıçta geçersiz olan değerleri geçerli hâle getirdiği için yine sorun çıkarabilir

    • URL güvenli Base64 derken tam olarak ne kastedildiğini mutlaka açıkça belirtmek gerekir. base64url kodlaması, base64 üstüne URL kodlaması eklemekle yaklaşık %3 durumda uyumsuzdur; geliştirme sırasında kolayca gözden kaçar ama prod’da mutlaka patlar
    • Çerez değerlerine =, /, + karakterlerini koyabildiğiniz için standart Base64 kodlaması da kullanılabilir :)

  • Yazı Postel yasası ile alay ediyor ama çerezi ayarlayan taraf gönderirken tutucu davransaydı, baştan böyle bir yazıya gerek kalmazdı

    • Alay edilmeyi hak ediyor. Postel yasası korkunç bir fikirdi ve her yere mayın tarlaları döşedi
      Bazen bu mayınlar basit bir bug değil, büyük bir güvenlik açığı da olabiliyor
      İstemci spesifikasyona uymayan veri gönderiyorsa bu bir bug’dır ve düzeltilmelidir. Sunucunun niyeti tahmin edip kabul etmesi asla normalleşmemeli
    • Postel yasasının sorunu, gönderen tarafın hiçbir zaman gerçekten tutucu olmamasıdır. Alıcıların çoğunun kabul ettiği ayrıntılı davranışlar sonunda göndericiler tarafından kullanılmaya başlanır