Bu yeni ASP.NET güvenlik açığı ne kadar ciddi ve bu sorunu nasıl çözebilirim?

ASP.NET'te yeni keşfedilen bir güvenlik açığı hakkında internette yeni okudum. Ayrıntıları buradan okuyabilirsiniz.

Sorun, ASP.NET'in bu uygulamaların kullanıcı oturumları sırasında bilgi depolamak için oluşturduğu tanımlama bilgilerinin bütünlüğünü korumak için AES şifreleme algoritmasını uygulama biçiminde yatmasıdır.

Bu biraz belirsiz, ama işte daha korkutucu bir bölüm:

Saldırının ilk aşaması birkaç bin istek alır, ancak başarılı olduktan ve saldırgan gizli anahtarları aldığında, tamamen gizlidir.Gerekli olan kriptografik bilgi çok basittir.

Sonuçta, bunun gerçekten ciddi olup olmadığını bilmek için güvenlik / kriptografi konusuna yeterince aşina değilim.

Peki, tüm ASP.NET geliştiricileri saniyeler içinde herhangi bir ASP.NET web sitesine sahip olabilecek bu teknikten korkmalı mıdır?

Bu sorun ortalama ASP.NET geliştiricisini nasıl etkiler? Bizi hiç etkiliyor mu? Gerçek hayatta, bu güvenlik açığının sonuçları nelerdir? Ve son olarak: bu güvenlik açığını önleyen bir geçici çözüm var mı?

Cevaplarınız için teşekkürler!

EDIT: Aldığım yanıtları özetleyeyim

Yani, bu temelde bir "dolgu oracle" saldırı tipidir. @Sri , bu saldırı türünün ne anlama geldiği hakkında harika bir açıklama yaptı. İşte sorun hakkında şok edici bir video!

Bu güvenlik açığının ciddiyeti hakkında: Evet, gerçekten ciddidir. Saldırganın bir uygulamanın makine anahtarını tanımasını sağlar. Böylece, çok istenmeyen bazı şeyler yapabilir.

• Uygulamanın makine anahtarının bulunması durumunda, saldırgan kimlik doğrulama çerezlerinin şifresini çözebilir.
• Daha da kötüsü , herhangi bir kullanıcının adıyla kimlik doğrulama çerezleri oluşturabilir . Böylece, sitede herkes gibi görünebilir. Uygulama siz veya adınızla bir kimlik doğrulama çerezi oluşturan bilgisayar korsanı arasında ayrım yapamıyor.
• Bir önceki çerez kadar tehlikeli olmasa da, oturum çerezlerinin şifresini çözmesini (ve ayrıca oluşturmasını) sağlar .
• Çok ciddi değil: Şifrelenmiş ViewState sayfalarının şifresini çözebilir. (Gizli verileri depolamak için ViewState kullanıyorsanız, bunu yine de yapmamalısınız!)
• Oldukça beklenmedik : Makine anahtarı bilgisiyle saldırgan , normalde indirilemeyen dosyalar da dahil olmak üzere web uygulamanızdan herhangi bir rastgele dosyayı indirebilir! ( Web.Config vb. Dahil )

İşte aldığım iyi uygulamaların bir demet yok sorunu çözmek ama yardım bir web uygulamasının genel güvenliğini artırmak.

• Hassas verileri Korumalı Yapılandırma ile şifreleyebilirsiniz
• Yalnızca HTTP çerezlerini kullan
• DoS saldırılarını önleme

Şimdi bu konuya odaklanalım.

• Scott Guthrie blogunda bir giriş yayınladı
• Güvenlik açığıyla ilgili ScottGu'nun SSS blog yazısı
• ScottGu'nun güvenlik açığıyla ilgili güncellemesi
• Microsoft bu konuda bir güvenlik danışmanlığına sahiptir
• Güvenlik açığını anlama
• Güvenlik açığı hakkında ek bilgi

Çözüm

• CustomErrors özelliğini etkinleştirin ve tüm hataların yönlendirildiği tek bir hata sayfası oluşturun . Evet, 404'ler bile . (ScottGu, bu saldırı için 404 ve 500'leri ayırt etmenin çok önemli olduğunu söyledi.) Ayrıca, rastgele bir gecikme yapan bir kodun içine Application_Errorveya Error.aspxkodunuza koyun. (Rastgele bir sayı oluşturun ve bu kadar uzun süre uyumak için Thread.Sleep'ı kullanın.) Bu, saldırganın sunucunuzda tam olarak ne olduğuna karar vermesini imkansız hale getirir.
• Bazı insanlar 3DES'e geri dönmeyi önerdi. Teorik olarak, AES kullanmazsanız, AES uygulamasındaki güvenlik zayıflığıyla karşılaşmazsınız. Sonuç olarak, bu hiç tavsiye edilmez .

Başka düşünceler

• O görünüyor değil herkes geçici çözüm yeterince iyi olduğunu düşünür.

Soruma cevap veren herkese teşekkürler. Sadece bu konuda değil, genel olarak web güvenliği hakkında çok şey öğrendim. @ Mikael'in cevabını kabul edilmiş olarak işaretledim, ancak diğer cevaplar da çok faydalı.

Kendimi korumak için ne yapmalıyım?

[2010-09-29 Güncellemesi]

Microsoft güvenlik bülteni

Düzeltmeye atıfta bulunan KB Makalesi

ScottGu'nun indirmeleri için bağlantıları var

[2010-09-25 Güncellemesi]

Düzeltmeyi beklerken dün ScottGu , sitelerinizi özel bir URLScan kuralıyla korumak için nasıl ek bir adım ekleyeceğinize dair bir güncelleme yayınladı.

Ayrıca, saldırganın ek saldırı bilgilerinin yanıtlarını zamanlamasını önlemek için hata sayfasına rastgele bir zaman uykusu ekleyin .

Web.config içinde

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

Bu, herhangi bir hatayı 200 durum koduyla döndürülen özel bir sayfaya yönlendirir. Bu şekilde bir saldırgan, sonraki saldırılar için gereken bilgiler için hata koduna veya hata bilgilerine bakamaz.

customErrors mode="RemoteOnly""Gerçek" istemcileri yönlendireceği için ayarlamak da güvenlidir . Yalnızca localhost'ta gezinmek dahili .Net hatalarını gösterecektir.

Önemli olan, tüm hataların aynı hata sayfasına dönecek şekilde yapılandırıldığından emin olmaktır. Bu defaultRedirect, <customErrors>bölümdeki özniteliği açıkça ayarlamanız ve durum başına kodların ayarlanmadığından emin olmanızı gerektirir .

Ne tehlikede?

Bir saldırgan belirtilen açıklamayı kullanmayı başarırsa, web uygulamanızdan dahili dosyalar indirebilir. Genellikle web.config bir hedeftir ve bir veritabanı bağlantı dizesindeki oturum açma bilgileri gibi hassas bilgileri içerebilir, hatta birinin ele geçirmesini istemediğiniz otomobil sql-express veritabanına bağlanabilir. Ancak en iyi uygulamayı izliyorsanız, web.config dosyasındaki tüm hassas verileri şifrelemek için Korumalı Yapılandırma'yı kullanırsınız.

Referanslara bağlantılar

Microsoft'un güvenlik açığı hakkındaki resmi yorumunu http://www.microsoft.com/technet/security/advisory/2416728.mspx adresinde bulabilirsiniz . Bu sorunla ilgili uygulama ayrıntıları için özellikle "Geçici Çözüm" bölümü.

Ayrıca web sunucunuzda savunmasız ASP.Net uygulamalarını bulmak için bir komut dosyası da dahil olmak üzere ScottGu'nun blogu hakkında bazı bilgiler .

"Dolgu Oracle Saldırılarını Anlamak" hakkında açıklama için @ sri'nin cevabını okuyun .

Makaleye yapılan yorumlar:

Rizzo ve Duong'un ASP.NET uygulamalarına karşı uyguladığı saldırı, Web sitesindeki kripto uygulamasının, şifreli metin gönderildiğinde yalnızca metnin şifresini çözmekle kalmayıp , gönderene şifreli metinde dolgu olup olmadığı hakkında bir mesaj vermesini gerektirir. geçerlidir .

Dolgu geçersizse, gönderenin aldığı hata iletisi, sitenin şifre çözme işleminin nasıl çalıştığı hakkında ona bazı bilgiler verir.

Saldırının çalışması için aşağıdakiler doğru olmalıdır:

• Uygulamanız, doldurmanın geçersiz olduğu konusunda bir hata mesajı vermelidir.
• Birisi şifreli çerezlerinizi veya görünüm durumunuzu kurcalamalı

Bu nedenle, uygulamanızda "Bir şeyler ters gitti, lütfen tekrar deneyin" gibi okunabilir hata iletileri döndürürseniz , oldukça güvenli olmalısınız. Makaledeki yorumları biraz okumak da değerli bilgiler verir.

• Şifrelenmiş çerezde oturum kimliği saklama
• Gerçek verileri oturum durumunda saklar (db'de devam eder)
• Hatayı iade etmeden önce kullanıcı bilgileri yanlış olduğunda rastgele bir bekleme ekleyin, böylece zamanlayamazsınız

Bu şekilde ele geçirilmiş bir çerez yalnızca artık mevcut olmayan veya geçersiz kılınmış bir oturumu almak için kullanılabilir.

Ekoparty konferansında gerçekte nelerin sunulduğunu görmek ilginç olacak, ancak şu anda bu güvenlik açığı için çok endişelenmiyorum.

Dolgu Oracle Saldırılarını Anlama

Uygulamanızın şifreli bir dizeyi parametre olarak kabul ettiğini varsayalım - parametrenin bir çerez, bir url parametresi veya başka bir şey önemsiz olması. Uygulama kodunu çözmeye çalıştığında, 3 olası sonuç vardır -

1. Sonuç 1 : Şifrelenmiş dize düzgün bir şekilde şifresini çözdü ve uygulama bunu anlamlandı. Yani, şifreli dize 10 haneli bir hesap numarasıysa, şifre çözme işleminden sonra uygulama "abcd1213ef" değil "1234567890" gibi bir şey buldu

2. Sonuç 2 : Dolgu doğruydu, ancak şifre çözme işleminden sonra elde edilen dize, uygulamanın anlayamadığı anlamsızdı. Örneğin, dize "abcd1213ef" olarak şifresi çözüldü, ancak uygulama yalnızca sayı bekliyordu. Çoğu uygulama "Geçersiz hesap numarası" gibi bir mesaj gösterir.

3. Sonuç 3 : Dolgu yanlıştı ve uygulama bir tür hata mesajı attı. Çoğu uygulama "Bazı hatalar oluştu" gibi genel bir mesaj gösterir.

Başarılı olmak için Doldurma Bilgisi saldırının amacıyla, saldırgan istekleri binlerce yapmak gerekir, ve hatasız yukarıdaki 3 kova birine tepkisini sınıflandırmak gerekir.

Bu iki koşul karşılanırsa, saldırgan sonunda iletinin şifresini çözebilir ve ardından istediği şeyle yeniden şifreleyebilir. Bu sadece bir zaman meselesi.

Bunu önlemek için ne yapılabilir?

1. En basit şey - hassas olan hiçbir şey istemciye asla gönderilmemeli, şifrelenmemeli veya şifrelenmemelidir. Sunucuda saklayın.

2. Yukarıdaki listedeki sonuç 2 ve sonuç 3'ün saldırganla tamamen aynı göründüğünden emin olun . Birini diğerinden anlamanın hiçbir yolu olmamalıdır. Ancak bu o kadar kolay değil - bir saldırgan bir tür zamanlama saldırısı kullanarak ayrımcılık yapabilir.

3. Son savunma hattı olarak, bir Web Uygulaması Güvenlik Duvarına sahip olun. Dolgu kehanet saldırısı, neredeyse benzer görünen (her seferinde bir bit değiştirme) birkaç istekte bulunmalıdır, bu nedenle bir WAF'ın bu tür istekleri yakalaması ve engellemesi mümkün olmalıdır.

PS Bu blog gönderisinde Padding Oracle Attacks hakkında iyi bir açıklama bulabilirsiniz . Feragatname: Bu benim blogum DEĞİL.

Okuduğumdan şimdiye kadar ...

Saldırı, birinin banka bakiyeleri gibi değerli veriler içerebilecek kokmuş çerezlerin şifresini çözmesine izin verir

Herhangi bir hesapta önceden oturum açmış olan bir kullanıcının şifrelenmiş çerezine ihtiyaçları vardır. Ayrıca çerezlerde veri bulmaları gerekiyor - Umarım geliştiriciler çerezlerde kritik veriler saklamazlar :). Ve asp.net giriş çerezinde veri depolamak izin vermemek için bir yolu var.

Birisi, tarayıcı verilerine el koymazsa çevrimiçi olan bir kullanıcının çerezini nasıl alabilir? Veya IP paketini koklamak mı?

Bunu önlemenin bir yolu, çerezlerin SSL şifrelemesi olmadan taşınmasına izin vermemektir.

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Ayrıca bir başka önlem de Rollerin çerezlerde saklanmasını önlemektir.

<roleManager enabled="true" cacheRolesInCookie="false">

Şimdi normal sayfalar için güvenli olmayan çerezler hakkında, bu kullanıcının ne yaptığını ve ne yapmadığını, ona nasıl güvendiğini, hangi ekstra kontrolü yapabileceğinizi düşünmek için biraz daha düşünmeye ihtiyaç duyuyor (örneğin ip üzerinde bir değişiklik görüyorsanız , belki güvenlik sayfasından yeniden giriş yapana kadar ona güvenmeyi bırakın).

Referans:
Bazı bilgisayar korsanları bir kullanıcıdan gelen çerezi çalabilir ve bir web sitesinde bu adla oturum açabilir mi?

Saldırıların nereden geldiğini nasıl kontrol edersiniz ve bilgi vermeyin. Burada dolgu geçersiz olduğunu önlemek için basit bir yol yazdı ve aynı zamanda saldırganları izlemek için günlüğe kaydetme: CryptographicException: Dolgu geçersiz ve kaldırılamaz ve viewtate MAC doğrulaması başarısız oldu

Saldırganı izlemenin yolu dolgunun geçersiz olduğunu kontrol etmektir. Basit bir prosedürle onları izleyebilir ve engelleyebilirsiniz - anahtarı bulmak için sayfanızda binlerce çağrıya ihtiyaç duyarlar!

Güncelleme 1.

Ben ANAHTAR bulmak ve veri şifresini varsayalım varsayalım aracı indirmek var, ve ben yukarıdaki kodu onun tuzak Gösterim kontrol kontrol . Benim testleri bu araç düzeltmek için çok daha fazlası var, örneğin olduğu gibi sıkıştırılmış görünüm durumunu tarayamaz ve benim testleri çökmesine.

Bazıları bu aracı veya bu yöntemi kullanmaya çalışırsanız, yukarıdaki kod onları izleyebilir ve bunları "Hizmet Reddini Önle (DOS)" gibi basit bir kodla veya Reddetmeyi önlemek için bu kod gibi sayfanızdan engelleyebilirsiniz. hizmet .

Güncelleme 2

Bu, bugüne kadar okuduğumdan , hata hakkında bilgi vermemeye gerçekten ihtiyaç duyduğunu ve sadece özel bir hata sayfası yerleştirdiğini ve isterseniz bu sayfaya rastgele bir gecikme oluşturabileceğinizi düşünüyorum.

bu konuda çok ilginç bir video .

Yani yukarıdakilerin hepsi daha fazla koruma için daha fazla önlemdir, ancak bu özel sorun için% 100 gerekli değildir. Örneğin, ssl çerezini kullanmak snif sorununu çözmek, Rolleri önbelleğe almamak, büyük çerezleri göndermemek ve geri almak için iyi değildir ve tüm hazır kodları kırmaktan kaçınmak için yönetici rolünü yerleştirmektir. onun kurabiyesi.

Görüş, saldırı bulmak için sadece bir önlem daha izler.

İşte MS yanıtı. Her şey "özel bir hata sayfası kullan" anlamına gelir ve hiçbir ipucu vermeyeceksiniz.

EDIT
İşte scottgu bazı daha ayrıntılı bilgi.

Http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx adresindeki tartışmadan ScottGu'nun yanıtlarını ekleme

CustomErrors yerine özel IHttpModule etkileniyor mu?

S: Web.config dosyamda bildirilen bir öğe yok, bunun yerine bölümün içinde bir IHttpModule var. Bu modül hatayı kaydeder ve bir arama sayfasına (404'ler için) veya bir hata sayfasına (500'ler için) yönlendirir. Ben savunmasız mıyım?

Y: Modülü her zaman arama sayfasına yönlendirmek için geçici olarak güncellemenizi tavsiye ederim. Bu saldırının çalışmasının yollarından biri, 404'ler ile 500 hata arasında bir ayrım aramasıdır. Her zaman aynı HTTP kodunu döndürmek ve aynı yere göndermek, engellenmesine yardımcı olmanın bir yoludur.

Düzeltme eki bunu düzeltmek için çıktığında, bunu yapmanız gerekmeyeceğini (ve eski davranışa geri dönebileceğinizi) unutmayın. Ama şimdilik 404 ile 500'leri müşterilere ayırmamanızı tavsiye ederim.

404 ve 500 hataları için farklı hatalar kullanmaya devam edebilir miyim?

S: Yukarıda açıklanan ilkeleri ihlal etmeden hatadaki varsayılan yönlendirmeye ek olarak yine de özel bir 404 sayfamız tanımlanabilir mi?

C: Hayır - gerçek düzeltme için bir yama yayınlayana kadar, tüm hataları homojenleştiren yukarıdaki çözümü öneririz. Bu saldırının çalışmasının yollarından biri, 404'ler ile 500 hata arasında bir ayrım aramasıdır. Her zaman aynı HTTP kodunu döndürmek ve aynı yere göndermek, engellenmesine yardımcı olmanın bir yoludur.

Düzeltme eki bunu düzeltmek için çıktığında, bunu yapmanız gerekmeyeceğini (ve eski davranışa geri dönebileceğinizi) unutmayın. Ancak şimdilik 404 ve 500'leri müşterilere ayırmamalısınız.

Bu, web.config dosyasının görüntülenmesine nasıl izin verir?

S: Bu, web.config dosyasının görüntülenmesine nasıl izin verir? Bu yalnızca ViewState'in şifresinin çözülmesini sağlıyor gibi görünüyor, ayrıca bilginin açığa çıkmasına izin veren başka bir ilgili güvenlik açığı var mı? Neler olup bittiğini daha iyi açıklamak için saldırıyı detaylandıran bir teknik inceleme belgesi var mı?

Y: Genel olarak gösterilen saldırı, ASP.NET'te dosyaların (genellikle javascript ve css) indirilmesine izin veren ve isteğin bir parçası olarak gönderilen bir anahtarla güvenlik altına alınan bir özelliğe dayanır. Maalesef bir anahtarı taklit edebiliyorsanız, bir uygulamanın web.config dosyasını (ancak uygulamanın dışındaki dosyaları değil) indirmek için bu özelliği kullanabilirsiniz. Açıkçası bunun için bir yama yayınlayacağız - o zamana kadar yukarıdaki geçici çözüm saldırı vektörünü kapatana kadar.

DÜZENLEME: Ek http://weblogs.asp.net/scottgu/archive/2010/09/20/ adresinde bulunan ikinci blog yazısında ek SSS mevcuttur.

IMO, bunun için genel bir önleme yok, duruma göre ele alınması gerekiyor:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

Birkaç önemli bağlantı:

• MS Güvenlik Danışma Belgesi 2416728 (bu resmi bilgidir)
• MS Güvenlik Araştırma ve Savunma ekibinden ek bilgi
  • "ASP.NET Güvenlik Açığı'nı Anlama" (2010-09-17)
  • "ASP.NET Güvenlik Açığı hakkında Ek Bilgi" (2010-09-20)
• Scott Gu: "Önemli: ASP.NET'te Güvenlik Açığı" (2010-09-18)

[Bunun ciddiyet yönüne cevap vermek için (yayımlananlar ve geçici çözümler diğer cevaplar tarafından kapsanmaktadır).]

Saldırılan anahtar, hem görüntüleme durumunu hem de oturum çerezlerini korumak için kullanılır. Normalde bu anahtar, web uygulamasının her yeni örneğiyle birlikte ASP.NET tarafından dahili olarak oluşturulur. Bu, çalışan sürecinin kullanım ömrünün zararını sınırlayacaktır, elbette yoğun bir uygulama için bu günler olabilir (yani bir sınırın fazla olmaması). Bu süre zarfında saldırgan ViewState değerlerini değiştirebilir (veya enjekte edebilir) ve oturumlarını değiştirebilir.

Oturumların çalışan işlem ömrünü uzatabilmesini veya web çiftliklerine izin vermesini istiyorsanız (yani gruptaki tüm örnekler herhangi bir kullanıcı oturumunu işleyebilir) anahtarın sabit kodlanması gerekir web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

Bunlar, elbette, yeni oluşturulan anahtarlar, Windows şifreleme rasgele sayı üretecine erişmek için aşağıdaki PowerShell'i kullanıyorum:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(Doğrulama için 20 ve şifre çözme anahtarları için 16 dizi uzunluğu kullanarak.)

Genel hata sayfalarını belirli bir hatayı sızdırmayacak şekilde değiştirmenin yanı sıra, yukarıdaki anahtarları değiştirmek için iyi bir zaman gibi görünebilir (veya bir süredir çalışıyorsa çalışan işlemlerini döngüye sokabilirsiniz).

[Edit 2010-09-21: Başa bağlantılar eklendi]

Sadece bu benim tam üstlenmek yayınlanmıştır benim blog konuda ekstra araştırma sonrasında,. Bence neden bir auth kurabiyesi yapmak kadar ilerlediklerini açıklığa kavuşturmak önemli.

Sadece bazı gerçekleri doğrudan almak istiyorum:

1. saldırı, makine anahtarını doğrudan almanıza izin vermez. Bununla birlikte, mesajların şifresini çözmeye ve yenilerini yeniden şifrelemeye izin verdiği için, sahip olduğu gibi.
2. gerçek anahtarları elde etmenin yolu, yeniden şifrelemeyi 1'deki gibi değiştirme ve web.config dosyasını alma becerilerini kullanmaktır. Ne yazık ki, bazılarının bu anahtarları web.config dosyasına site düzeyinde koyması (farklı tartışma) nedenleri vardır ve örnek videoda DotnetNuke'un varsayılan olmasından faydalanırlar.
3. tüm web.config almak için webresources.axd ve / veya scriptresources.axd kullandıklarını gösterir. Bunların sadece gömülü kaynaklarla çalıştığını düşündüm, ama öyle değil.
4. uygulama asp.net MVC ise gerçekten webresources.axd ve / veya scriptresources.axd gerekmez, bu yüzden bu kapatılabilir. Viewstate kullanmıyoruz. Yani, diğer asp.net özelliklerinden herhangi biri yerinde geçici çözüm ile farklı bilgi verirse bana net değil yani göz ardı kimlik doğrulama bilet geçerli sonuçlar doldurma sırasında hata geçersiz sonuçlar verirse bilmiyorum (bilmiyorum durum böyle olsun veya olmasın) ... oturum çerezi için aynı analiz uygulanmalıdır.
5. asp.net üyelik sağlayıcısı çerezlerdeki rolleri 'önbelleğe alır', bunu kapatın.

Yaklaşık 1, afaik şifreli mesajlar mesajın bir yerinde küçük bir çöp parçasını tolere etmek için% 100 keyfi ihtiyaç olamaz, çünkü mesajda kontrol edilemeyen değerin şifresini çözen 1 blok vardır.

Son olarak, bu sorunun ms'nin bu durumda kendi rehberliğini izlememesinin sonucu olduğunu söylemek isterim: bir özellik, istemciye gönderilen bir şeyin kurcalamaya dayanıklı olduğuna dayanır.

Daha fazla:

Ben göz ardı kimlik doğrulama bilet geçerli sonuçlar doldurma sırasında dolgu geçersiz sonuçlar verirse bilmiyorum (durumun olup olmadığını bilmiyorum) ... aynı analiz oturum çerez için geçerli olmalıdır.

Yetkilendirme çerezi imzalanır ve kağıttaki bilgilerden, gerçek anahtarlara ulaşmazlarsa (yetkilendirme çerezini oluşturmadan önce videoda yaptıkları gibi) imzalı bir çerez oluşturamazlar.

Aristos'un belirttiği gibi, çerezdeki oturum kimliği için bu kullanıcı oturumu için rasgele, bu nedenle hedef güvenlik düzeyine sahip bir kullanıcıdan koklanması ve bu oturum aktifken kırılması gerekir. O zaman bile, kullanıcı işlemlerini atamak / yetkilendirmek için kimlik doğrulamasına güveniyorsanız, etki minimum olacaktır / Oturumun o uygulamada ne için kullanıldığına çok bağlıdır.

Bu hata için bir düzeltme eki Windows Update sitesinde yayımlanmıştır: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Asp.Net MVC de bu sorundan etkilenir (Sharepoint gibi ...)

MVC düzeltmesini burada ele aldım: ASP.NET MVC oracle doldurma saldırısına karşı savunmasız mı?