Aynı işlevselliğe sahip oldukları için tüm çerezleri yerel depolama alanına taşıyarak web sitelerimdeki yükleme sürelerini azaltmak istiyorum. Belirgin uyumluluk sorunları dışında çerez işlevselliğinin yerini almak için yerel depolama birimini kullanmanın artıları / eksileri (özellikle performans açısından) var mı?

Çerezler ve yerel depolama farklı amaçlara hizmet eder. Çerezler öncelikli olarak sunucu tarafı okumak içindir, yerel depolama yalnızca istemci tarafı tarafından okunabilir . Soru şu: Uygulamanızda bu verilere kim ihtiyaç duyuyor - istemci veya sunucu?

İstemciniz (JavaScript'iniz) ise, elbette geçiş yapın. Her HTTP üstbilgisindeki tüm verileri göndererek bant genişliğini boşa harcıyorsunuz.

Sunucunuzsa, yerel depolama o kadar kullanışlı değildir çünkü verileri bir şekilde (Ajax veya gizli form alanları vb. İle) iletmeniz gerekir. Sunucunun her istek için toplam verilerin yalnızca küçük bir alt kümesine ihtiyacı varsa bu sorun yaratabilir.

Ancak oturum çerezinizi her iki şekilde de çerez olarak bırakmak isteyeceksiniz.

Teknik fark ve aynı zamanda benim anlayışım gereği:

1. Veri kaydetmenin eski bir yolu olmanın yanı sıra, Çerezler size 4096 baytlık bir sınır verir (aslında 4095) - her çerez için geçerlidir. Yerel Depolama alanı başına 5 MB büyüklüğündedir - SO Sorusu da bundan bahseder.

2. localStorage, StorageArayüzün bir uygulamasıdır . Son kullanma tarihi olmayan verileri depolar ve çerez sona erme süresinin aksine yalnızca JavaScript aracılığıyla veya Tarayıcı Önbelleği / Yerel Olarak Saklanan Verileri temizleyerek temizlenir.

JWT'ler bağlamında Stormpath , bunları saklamanın olası yollarını ve her yönteme ait (dis) avantajları özetleyen oldukça yararlı bir makale yazmıştır.

Ayrıca XSS ve CSRF saldırılarına ve bunlarla nasıl mücadele edebileceğinize kısa bir genel bakış vardır.

Makalelerinin çevrimdışı olması / sitelerinin kapanması durumunda aşağıdaki makalenin bazı kısa parçacıklarını ekledim.

Yerel depolama

sorunlar:

Web Depolama'ya (localStorage / sessionStorage) aynı etki alanındaki JavaScript aracılığıyla erişilebilir. Bu, sitenizde çalışan tüm JavaScript'lerin web depolama alanına erişebileceği ve bu nedenle siteler arası komut dosyası (XSS) saldırılarına karşı savunmasız olabileceği anlamına gelir. Özetle XSS, bir saldırganın sayfanızda çalışacak JavaScript enjekte edebileceği bir tür güvenlik açığıdır. Temel XSS saldırıları, saldırganın uyarıda bulunduğu form girişleri aracılığıyla JavaScript enjekte etmeyi dener ('Saldırıya Uğradınız'); tarayıcı tarafından çalıştırılıp çalıştırılmadığını ve diğer kullanıcılar tarafından görüntülenip görüntülenemeyeceğini görmek için bir forma dönüştürün.

önleme:

XSS'yi önlemek için ortak yanıt, güvenilir olmayan tüm verilerden kaçmak ve kodlamaktır. Ama bu hikayenin tamamından uzak. 2015 yılında, modern web uygulamaları CDN'lerde veya dış altyapıda barındırılan JavaScript kullanır. Modern web uygulamaları A / B testi, huni / pazar analizi ve reklamlar için 3. taraf JavaScript kitaplıklarını içerir. Diğer insanların kodlarını uygulamalarımıza aktarmak için Bower gibi paket yöneticilerini kullanıyoruz.

Kullandığınız komut dosyalarından yalnızca biri tehlikeye girerse ne olur? Kötü amaçlı JavaScript sayfaya gömülebilir ve Web Deposu tehlikeye atılır. Bu tür XSS saldırıları, herkesin sitenizi ziyaret eden Web Depolama Alanlarını bilgisi olmadan alabilir. Muhtemelen bir grup kuruluş, değerli bir şey depolamamanızı veya web depolama alanında herhangi bir bilgiye güvenmemeyi tavsiye eder. Buna oturum tanımlayıcıları ve simgeleri de dahildir.

Bir depolama mekanizması olarak, Web Depolama aktarım sırasında güvenli bir standart uygulamaz. Her kim Web Depolama'yı okur ve kullanırsa, JWT'yi her zaman HTTPS üzerinden göndermelerini ve asla HTTP göndermemelerini sağlamak için gereken özeni göstermelidir.

Kurabiye

sorunlar:

Çerezlere, HttpOnly çerez bayrağıyla birlikte kullanıldığında, JavaScript aracılığıyla erişilemez ve XSS'ye karşı bağışık değildir. Güvenli çerez bayrağını, çerezin yalnızca HTTPS üzerinden gönderileceğini garanti edecek şekilde de ayarlayabilirsiniz. Bu, geçmişte jeton veya oturum verilerini saklamak için çerezlerin kullanılmasının ana nedenlerinden biridir. Modern geliştiriciler çerezleri kullanmakta tereddüt ederler, çünkü geleneksel olarak sunucuda depolanması için durum gerektirirler, böylece RESTful en iyi uygulamalarını bozarlar. Depolama mekanizması olarak çerezler, çerezde bir JWT saklıyorsanız durumun sunucuda depolanmasını gerektirmez. Bunun nedeni, JWT'nin sunucunun isteği sunmak için ihtiyaç duyduğu her şeyi kapsadığıdır.

Ancak, çerezler farklı bir saldırı türüne karşı savunmasızdır: siteler arası istek sahteciliği (CSRF). CSRF saldırısı, kötü amaçlı bir web sitesi, e-posta veya blog, kullanıcının web tarayıcısının, kullanıcının kimliğinin doğrulandığı güvenilir bir sitede istenmeyen bir eylem gerçekleştirmesine neden olduğunda ortaya çıkan bir saldırı türüdür. Bu, tarayıcının çerezleri nasıl ele aldığından yararlanır. Bir çerez yalnızca izin verildiği alanlara gönderilebilir. Varsayılan olarak, bu tanımlama bilgisini başlangıçta ayarlayan alandır. Tanımlama bilgisi galaxies.com'da veya hahagonnahackyou.com'da olup olmadığınıza bakılmaksızın bir istek için gönderilir.

önleme:

Modern tarayıcılar, SameSitebayrağa ek olarak HttpOnlyveSecure . Bu bayrağın amacı, çerezin siteler arası taleplerde iletilmesini ve birçok CSRF saldırısının önlenmesidir.

Desteklemeyen tarayıcılar SameSiteiçin senkronize edilmiş token kalıpları kullanılarak CSRF önlenebilir. Bu karmaşık görünüyor, ancak tüm modern web çerçeveleri bunu destekliyor.

Örneğin, AngularJS, tanımlama bilgisine yalnızca alan adınız tarafından erişilebildiğini doğrulamak için bir çözüme sahiptir. AngularJS belgelerinden doğrudan:

XHR isteklerini gerçekleştirirken, $ http hizmeti bir çerezden (varsayılan olarak XSRF-TOKEN) bir simge okur ve bunu HTTP üstbilgisi (X-XSRF-TOKEN) olarak ayarlar. Yalnızca alan adınızda çalışan JavaScript çerezi okuyabildiğinden, sunucunuzun XHR'nin alan adınızda çalışan JavaScript'ten geldiğinden emin olabilirsiniz. Bu CSRF korumasını bir xsrfTokenJWT iddiası ekleyerek durumsuz hale getirebilirsiniz :

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "tom@andromeda.com",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

Web uygulama çerçevenizin CSRF korumasından yararlanmak, çerezleri bir JWT depolamak için sağlam hale getirir. CSRF, API'nizden HTTP Tavsiye ve Kaynak üstbilgisi kontrol edilerek de kısmen önlenebilir. CSRF saldırılarında uygulamanızla ilgisi olmayan Yönlendiren ve Köken başlıkları bulunur.

Makalenin tamamını burada bulabilirsiniz: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

Ayrıca, jetonun yapısı ile ilgili olarak JWT'lerin en iyi nasıl tasarlanacağı ve uygulanacağı konusunda yararlı bir makaleleri var: https://stormpath.com/blog/jwt-the-right-way/

İle localStorage, web uygulamaları verileri kullanıcının tarayıcısında yerel olarak depolayabilir. HTML5'ten önce, uygulama verilerinin her sunucu isteğine dahil edilen çerezlerde saklanması gerekiyordu. Web sitesi performansını etkilemeden büyük miktarda veri yerel olarak depolanabilir. olmasına rağmenlocalStorageDaha modern , her iki tekniğin de artıları ve eksileri vardır.

Kurabiye

Artıları

• Eski destek (sonsuza dek sürdü)
• Kalıcı veri
• Son kullanma tarihleri

Eksileri

• Her etki alanı tüm çerezlerini tek bir dizede saklar, bu da verileri ayrıştırmayı zorlaştırabilir
• Veriler şifrelenmez, bu sorun haline gelir, çünkü ... ... boyut olarak küçük olsa da, her HTTP isteğiyle çerezler gönderilir Sınırlı boyut (4KB)
• SQL enjeksiyonu bir çerezden yapılabilir

Yerel depolama

Artıları

• Çoğu modern tarayıcı tarafından desteklenir
• Doğrudan tarayıcıda saklanan kalıcı veriler
• Aynı depolama alanı kuralları yerel depolama verileri için geçerlidir
• Her HTTP isteğiyle gönderilmez
• Alan adı başına ~ 5 MB depolama alanı (bu 5120 KB'dir)

Eksileri

• Daha önce hiçbir şey tarafından desteklenmiyor: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• Sunucunun depolanan istemci bilgilerine ihtiyacı varsa, bilerek göndermeniz gerekir.

localStorageoturum birinci oturum ile hemen hemen aynıdır. Hemen hemen kesin yöntemlere sahipler, bu yüzden oturumdan geçmek localStoragegerçekten çocuk oyuncağı. Ancak, depolanan veriler uygulamanız için gerçekten önemliyse, büyük olasılıkla çerezlerin localStoragekullanılamaması durumunda yedek olarak kullanacaksınız . Tarayıcı desteğini kontrol etmek istiyorsanız localStorage, yapmanız gereken tek şey bu basit komut dosyasını çalıştırmaktır:

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

"Güvenli" (SSL) sayfalarındaki localStorage değerleri izole edilmiştir " , çerezlerin hala erişilebilir olacağı yerlerde 'http' den 'https' güvenli protokole geçerseniz localStorage'ın kullanılamayacağını unutmayın. Güvenli protokollerle çalışıp çalışmadığınızı bilmeniz önemlidir.

Yerel depolama hızı, büyük ölçüde istemcinin kullandığı tarayıcıya ve işletim sistemine bağlıdır. Mac'teki Chrome veya Safari, özellikle daha yeni API'larda bir PC'deki Firefox'tan çok daha hızlı olabilir. Her zaman olduğu gibi, test arkadaşın (herhangi bir kriter bulamadım).

Çerezde yerel depolamaya karşı gerçekten büyük bir fark görmüyorum. Ayrıca, uyumluluk sorunları hakkında daha fazla endişelenmelisiniz: tüm tarayıcılar yeni HTML5 API'lerini desteklemeye bile başlamamıştır, bu nedenle çerezler hız ve uyumluluk için en iyi bahis olacaktır.

Ayrıca, localStoragekullanıcılar mobil Safari'nin bazı sürümlerinde "özel" modda göz attığında kullanılamayacağını da belirtmek gerekir .

Alıntı: MDN ( https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage ):

Not: iOS 5.1 ile başlayarak, Safari Mobile localStorage verilerini ara sıra temizlemeye tabi olan önbellek klasöründe, genellikle alan kısasa, işletim sisteminin en arkasında saklar. Safari Mobile'ın Özel Tarama modu ayrıca localStorage'a yazmayı tamamen önler.

Yerel depolama 5mb'ye kadar çevrimdışı veri depolayabilirken, oturum 5 mb'ye kadar veri depolayabilir. Ancak çerezler yalnızca 4kb verilerini metin biçiminde depolayabilir.

JSON formatında LOCAl ve Session depolama verileri, böylece ayrıştırmak kolaydır. Ancak çerez verileri dize biçimindedir.

Çerezler :

1. HTML5'ten önce tanıtıldı.
2. Son kullanma tarihi vardır.
3. JS veya tarayıcının Tarama Verilerini Temizle veya son kullanma tarihinden sonra temizleyin.
4. Her istek için sunucuya gönderilir.
5. Kapasite 4KB'dir.
6. Yalnızca dizeler çerezlerde saklanabilir.
7. İki tür çerez vardır: kalıcı ve oturum.

Yerel depolama:

1. HTML5 ile tanıtıldı.
2. Son kullanma tarihi yok.
3. Cleard by JS veya Tarayıcının Tarama Verilerini Temizle.
4. Verilerin sunucuya ne zaman gönderilmesi gerektiğini seçebilirsiniz.
5. Kapasite 5 MB'dir.
6. Veriler süresiz olarak saklanır ve bir dize olmalıdır.
7. Sadece bir tür var.