it-swarm-tr.com

Güvenli Oturum Çerezleri

Güvenli oturum çerezleri oluşturma yöntemleri ararken bu yayına rastladım: Güvenli Çerez Protokolü . Bir oturum çerezi için aşağıdaki formülü önerir:

cookie = user | expiration | data_k | mac

nerede

  • | Birleştirme anlamına gelir.
  • user istemcinin kullanıcı adıdır.
  • expiration, çerezin sona erme zamanıdır.
  • data_k, k. Anahtarı kullanılarak şifrelenen istemciyle ilişkilendirilmiş şifreli verilerdir (oturum kimliği veya alışveriş sepeti bilgileri gibi).
    • k özel bir sunucu anahtarından türetilir sk; k = HMAC(user | expiration, sk).
    • data_kAES kullanılarak k anahtarı kullanılarak şifrelenebilir.
  • mac, çerezin gerçekliğini doğrulamak için çerezin bir HMAC'sidir; mac = HMAC(user | expiration | data | session-key, k).
    • data, istemciyle ilişkili şifrelenmemiş verilerdir.
    • session-key SSL oturum anahtarıdır.
  • HMACHMAC-MD5 veya HMAC-SHA1.

Makaleye göre, çerez gizliliği sağlar ve tekrar ve hacim saldırılarına karşı korur. Bana göre (güvenlik/kriptografide amatör olmak) bu oldukça iyi görünüyor. Genel olarak oturum çerezleri veya çerezler için bu yöntem ne kadar iyidir?

35
user369450

Evet, bu çerezleri korumak için oldukça iyi bir şema gibi görünüyor.

Bu alandaki diğer bir yeni program da çok iyi düşünülmüş, SCS: HTTP için Güvenli Çerez Oturumları . Güvenlik tehditlerinin ne olabileceği konusunda iyi bir fikir edinmek için bu belgenin güvenlik tartışmasını okumanızı tavsiye ederim.

Bahsettiğiniz çerez şemasının amacını ve rolünü anlamaya yardımcı olmak için, yedeklememe ve bir bağlam sunmama izin verin. Web uygulamalarının oturum durumunu sürdürmesi yaygındır: yani, ömrü geçerli oturumla sınırlı olan ve geçerli oturuma bağlı olan bir durum. Oturum durumunu korumanın iki yolu vardır:

  1. Oturum durumunu sunucuda saklayın. Web sunucusu tarayıcıya bir oturum çerezi besler: tek amacı büyük, tahmin edilemez bir bit dizgisi tutmak olan bir çerez oturum tanımlayıcısı olarak işlev görür. Sunucu, oturum tanımlayıcısından bu oturumla ilişkili tüm oturum durumuyla eşleşen, açık oturum başına bir giriş içeren bir arama tablosu tutar. Bu, web uygulama kodunun belirli bir HTTP/HTTPS isteğiyle ilişkili oturum durumunu almasını ve güncellemesini kolaylaştırır. Çoğu web uygulaması çerçevesi, oturum durumunu sunucu tarafında depolamak için yerleşik destek sağlar.

    Bu, oturum durumunu depolamanın en güvenli yoludur. Oturum durumu sunucuda depolandığından, istemcinin buna doğrudan erişimi yoktur. Bu nedenle, saldırganların oturum durumunu okuması veya kurcalaması (veya eski değerleri tekrar oynatması) mümkün değildir. Web uygulamanız birden fazla arka uç işlem düğümü arasında dağıtılmışsa, oturum durumunun tüm sunucular arasında senkronize olmasını sağlamak için fazladan bir çalışma gerekir.

  2. Oturum durumunu istemcide saklayın. Diğer yaklaşım oturum durumunu bir çereze koymak ve çerezi tarayıcıya göndermek. Şimdi tarayıcıdan sonraki her istek oturum durumunu içerecektir. Web uygulaması oturum durumunu değiştirmek istiyorsa, tarayıcıya güncellenmiş bir çerez gönderebilir.

    Saf bir şekilde yapılırsa, bu büyük bir güvenlik açığıdır, çünkü kötü niyetli bir istemcinin oturum durumunu görüntülemesine ve değiştirmesine izin verir. Birincisi, oturum durumuna dahil edilmiş gizli veriler varsa bir sorundur. İkincisi, sunucu oturum durumuna herhangi bir şekilde güvenirse veya ona güvenirse bir sorundur (örneğin, oturum durumunun oturum açmış kullanıcının kullanıcı adını içerip içermediğini ve bu kullanıcının yönetici olup olmadığını gösteren biraz düşünün; kötü niyetli bir istemci web uygulamasının kimlik doğrulama mekanizmasını atlayabilir).

    Bahsettiğiniz teklif ve SCS şeması, bu risklere karşı mümkün olduğu kadar savunmayı amaçlamaktadır. Bunu çoğunlukla başarılı olacak şekilde yapabilirler. Ancak, kötü niyetli bir istemcinin çerezi silmesini (ve böylece oturum durumunu temizlemesini) engelleyemezler. Ayrıca, eski sürüm aynı oturumdan gelmişse, kötü niyetli bir istemcinin çerezin eski bir değerini yeniden oynatmasını (ve böylece oturum durumunu daha eski bir değere sıfırlamasını) engelleyemezler. Bu nedenle, web uygulaması geliştiricisinin bu risklerin farkında olması ve oturum durumunda hangi değerlerin depolandığına dikkat etmesi gerekir.

Bu nedenle, oturum durumunu çerezlerde saklamak, çerezleri korumak için bu şifreleme şemalarından birini kullansanız bile, sunucuda depolamaktan biraz daha risklidir. (Ancak, oturum durumunu çerezlerde saklayacaksanız, çerezlerdeki değerleri korumak için bu iki şemadan birini kullanmanızı kesinlikle öneririm. )

Neden sunucu tarafında kolayca saklanabileceği düşünüldüğünde, oturum durumunu çerezlerde saklayalım ki? Çoğu zaman, bunun için bir sebep yoktur. Bununla birlikte, bazı istisnai durumlarda - sahip olduğu depolama alanı miktarında aşırı derecede kısıtlanmış bir HTTP sunucusu veya senkronize oturum durumu için iyi bir destek olmadan birden fazla makineye dağıtılan yük dengeli web uygulamaları gibi - oturum durumunu çerezlerde depolamayı ve ardından bu şemalardan birini kullanmak için haklı nedenler iyi bir fikirdir.

Not; İlgili bir konu: ASP.NET Görünüm Durum kullanırsanız, şifrelenecek ve kimliği doğrulanacak şekilde yapılandırdığınızdan emin olun: ie, ViewStateEncryptionMode - Always ve EnableViewStateMac - true; birden çok sunucu düğümü kullanıyorsanız, güçlü bir şifreleme anahtarı oluşturun ve her bir sunucunun machineKey tuşunu bu anahtarı kullanacak şekilde yapılandırın . Son olarak, ASP.NET çerçevesinin güncel bir sürümüne sahip olduğunuzdan emin olun; eski sürümler ciddi bir güvenlik açığı vardıViewState kriptounda .

30
D.W.

Ne problemi çözmeye çalışıyorsun?

Düşünebileceğim iki şey var:

  1. Güvenli kullanıcı oturumları ayarlamak istiyorsunuz. Bu durumda, büyük olasılıkla kendi oturum çerezlerinizi oluşturmanız bile gerekmez - bunlar sunucunuzla bir SSL oturumu üzerinden oluşturulabilir ve herhangi bir web sitesi ihtiyacı için genellikle güvenli. Sitenin SSL'yi doğru bir şekilde uyguladığından emin olun ve PHP veya ASP gibi ortak dillerde bulunabilen gibi iyi bilinen bir oturum oluşturma yöntemi kullanın.
  2. Daha sonra almak üzere güvenli verileri çerezde saklamak istiyorsunuz. Çerezlerle ilgili birçok sorun nedeniyle güvenliğini sağlamak çok daha zordur. Bunun yerine sunucu tarafını depolamak ve verileri başka bir yöntem kullanarak kullanıcıyla ilişkilendirmek daha iyidir. Bunu yapmanız gerekiyorsa, açıkladığınız yöntem genel olarak oldukça iyi görünüyor, ancak tekrarlama saldırılarını veya SSL gibi ortadaki adam gibi diğer saldırıları nasıl önlediğini net değilim.

Daha fazla tartışmak isterseniz doğrudan benimle iletişime geçmekten çekinmeyin.

4
Charlie B

Önerdikleri yöntemin bir kısmı, SSL oturum anahtarını şifrelenmiş yükün bir parçası olarak kullanmaktır - ancak bu yalnızca SSL oturumu kadar uzun sürer - yani, bu yöntemi birden fazla tarayıcı oturumuna yayılması amaçlanan çerezler için kullanamazsınız. Ayrıca tam olarak önemsiz değil; SSL oturum anahtarını tutmak için, özellikle SSL sonlandırması http sunucusundan başka bir yerde.

Uygulamada, çerez için rasgele bir değeri depolanan veri tarafına tanıtıcı olarak kullanmak çok daha basittir. Bu, tarayıcı kullanıcı aracısının karması ve istemcinin net adı (not IP adresi) gibi şeylere bağlanabilir. Ve/veya gerekirse sunucudaki SSL oturum anahtarı. Tüm bu verileri şifrelemeye ve istemciye iletmeye gerek yoktur.

2
symcbean

Bu, aşağıdaki konuları çözdüğü için makul bir uygulamadır:

  • Reddetmeme (değerin doğrulanması değiştirilmedi)
  • Gizlilik (şifrelenmiş içeriğin okunamaması)

Bununla birlikte, kullanıcı bilgileri biraz zayıftır ve daha sonra karşılaştırmak için şifreli bilgilerin içine dahil edilmezse tehlikeye girebilir.

Çerezler veya istemci tarafından erişilebilen verilerle ilgili en büyük sorun, istemcinin (bilgisayar korsanı) değiştirebilmesi veya kopyalayabilmesidir. Oturum ele geçirme, SSL'ye rağmen kolayca gerçekleştirilebilir (daha önce yeterli olarak yorumlandığı gibi - ki bu da yeterli değildir). Çeşitli kötü amaçlı yazılım formları, ortadaki adam, tarayıcıdaki adam ve diğer saldırılar oturum çerezini yakalayabilir, başka bir makineye kopyalayabilir ve şimdi bu oturuma 'sahip olabilirler'. Amazon gibi bir dosya üzerinde kart sistemi için bu sorunlu olabilir.

Bu teklif üzerindeki döngüyü kapatmak için, istemci kimliğinin makul olarak benzersiz olması ve daha sonra başka bir bilgisayarın oturum çerezi çalmasını önlemek için şifreli bölümdeki verilere bağlanması gerekir. Bunun dışında, teklifin bileşenleri sağlam görünüyor.

0
Darrell Teague