Jak poważna jest ta nowa luka w zabezpieczeniach programu ASP.NET i jak mogę ją obejść?

Właśnie przeczytałem w Internecie o nowo wykrytej luce w zabezpieczeniach w ASP.NET. Możesz przeczytać szczegóły tutaj.

Problem polega na tym, że ASP.NET implementuje algorytm szyfrowania AES w celu ochrony integralności plików cookie generowanych przez te aplikacje do przechowywania informacji podczas sesji użytkownika.

Jest to trochę niejasne, ale tutaj jest bardziej przerażająca część:

Pierwszy etap ataku wymaga kilku tysięcy próśb, ale gdy się powiedzie i atakujący zdobędzie tajne klucze, jest całkowicie podstępny. Wymagana wiedza kryptograficzna jest bardzo podstawowa.

Podsumowując, nie jestem wystarczająco zaznajomiony z tematem bezpieczeństwa / szyfrowania, aby wiedzieć, czy to naprawdę tak poważne.

Czy więc wszyscy programiści ASP.NET powinni obawiać się tej techniki, która może być właścicielem dowolnej witryny ASP.NET w ciągu kilku sekund ?

Jak ten problem wpływa na przeciętnego programistę ASP.NET? Czy to w ogóle wpływa na nas? Jakie są konsekwencje tej podatności w życiu? I wreszcie: czy istnieje jakieś obejście, które zapobiega tej podatności?

Dzięki za odpowiedzi!

EDYCJA: Pozwól, że streszczę otrzymane odpowiedzi

Jest to w zasadzie atak typu „padding oracle”. @Sri zapewniło doskonałe wyjaśnienie, co oznacza ten rodzaj ataku. Oto szokujące wideo na ten temat!

O powadze tej podatności: Tak, to naprawdę poważna sprawa. Pozwala atakującemu poznać klucz maszynowy aplikacji. W ten sposób może robić bardzo niechciane rzeczy.

• Posiadając klucz maszynowy aplikacji, osoba atakująca może odszyfrować uwierzytelniające pliki cookie.
• Co gorsza, może generować uwierzytelniające pliki cookie o nazwie dowolnego użytkownika. W ten sposób może pojawić się jako każdy na stronie. Aplikacja nie jest w stanie rozróżnić między tobą a hakerem, który sam wygenerował cookie uwierzytelniające z Twoim nazwiskiem.
• Pozwala mu również odszyfrować (a także wygenerować) sesyjne pliki cookie , chociaż nie jest to tak niebezpieczne jak poprzednie.
• Nie tak poważnie: może odszyfrować zaszyfrowany stan strony ViewState. (Jeśli używasz ViewState do przechowywania poufnych danych, i tak nie powinieneś tego robić!)
• Zupełnie nieoczekiwany : znając klucz maszynowy, osoba atakująca może pobrać dowolny dowolny plik z aplikacji internetowej, nawet te, których normalnie nie można pobrać! (W tym Web.Config itp.)

Oto kilka dobrych praktyk, które nie rozwiązały problemu, ale pomogły poprawić ogólne bezpieczeństwo aplikacji internetowej.

• Możesz szyfrować poufne dane za pomocą Protected Configuration
• Używaj plików cookie tylko HTTP
• Zapobiegaj atakom DoS

Teraz skupmy się na tym problemie.

• Scott Guthrie opublikował wpis na ten temat na swoim blogu
• W blogu ScottGu FAQ na temat podatności
• Aktualizacja ScottGu dotycząca luki w zabezpieczeniach
• Microsoft ma na ten temat poradnik bezpieczeństwa
• Zrozumienie luki w zabezpieczeniach
• Dodatkowe informacje o luce w zabezpieczeniach

Rozwiązanie

• Włącz customErrors i utwórz pojedynczą stronę błędów, na którą przekierowywane są wszystkie błędy . Tak, nawet 404 . (ScottGu powiedział, że rozróżnienie między 404 a 500 jest niezbędne dla tego ataku.) Również w swoim Application_Errorlub Error.aspxumieść kod, który powoduje losowe opóźnienie. (Wygeneruj losową liczbę i użyj Thread.Sleep do spania przez tak długi czas). Dzięki temu atakujący nie będzie mógł zdecydować, co dokładnie wydarzyło się na twoim serwerze.
• Niektóre osoby zalecały powrót do 3DES. Teoretycznie, jeśli nie użyjesz AES, nie napotkasz słabości bezpieczeństwa w implementacji AES. Jak się okazuje, wcale nie jest to zalecane .

Kilka innych myśli

• Wydaje się, że nie wszyscy uważają, że to obejście jest wystarczająco dobre.

Dziękuję wszystkim, którzy odpowiedzieli na moje pytanie. Wiele się nauczyłem nie tylko o tym problemie, ale ogólnie o bezpieczeństwie w sieci. Oznacziłem odpowiedź @ Mikael jako zaakceptowaną, ale inne odpowiedzi są również bardzo przydatne.

Co mam zrobić, aby się zabezpieczyć?

[Aktualizacja 2010-09-29]

Biuletyn zabezpieczeń firmy Microsoft

Artykuł KB w odniesieniu do poprawki

ScottGu ma linki do plików do pobrania

[Aktualizacja 2010-09-25]

Podczas gdy czekamy na poprawkę, wczoraj ScottGu opublikował aktualizację, w jaki sposób dodać dodatkowy krok, aby chronić swoje witryny za pomocą niestandardowej reguły URLScan.

Dodatkowo dodaj losowy czas snu na stronie błędu, aby uniemożliwić atakującemu odmierzenie czasu odpowiedzi na dodanie informacji o ataku.

W pliku web.config

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

Spowoduje to przekierowanie dowolnego błędu na niestandardową stronę zwróconą z kodem stanu 200. W ten sposób osoba atakująca nie może spojrzeć na kod błędu lub informacje o błędzie w celu uzyskania informacji potrzebnych do dalszych ataków.

Można go również bezpiecznie ustawić customErrors mode="RemoteOnly", ponieważ przekieruje on „prawdziwych” klientów. Tylko przeglądanie z localhost pokaże wewnętrzne błędy .Net.

Ważne jest, aby upewnić się, że wszystkie błędy są skonfigurowane tak, aby zwracały tę samą stronę błędów. Wymaga to jawnego ustawienia defaultRedirectatrybutu w <customErrors>sekcji i upewnienia się, że nie są ustawione kody poszczególnych statusów.

O co chodzi?

Jeśli atakującemu uda się wykorzystać wspomniany exploit, może on pobrać pliki wewnętrzne z poziomu aplikacji internetowej. Zazwyczaj web.config jest celem i może zawierać poufne informacje, takie jak dane logowania w ciągu połączenia z bazą danych, a nawet link do zautomatyzowanej bazy danych SQL Express, której nie chcesz, aby ktoś ją zdobył. Ale jeśli postępujesz zgodnie z najlepszymi praktykami, używasz Protected Configuration do szyfrowania wszystkich wrażliwych danych w pliku web.config.

Linki do referencji

Przeczytaj oficjalny komentarz Microsoftu na temat podatności na stronie http://www.microsoft.com/technet/security/advisory/2416728.mspx . W szczególności część „Obejście” dla szczegółów implementacji tego problemu.

Również niektóre informacje na blogu ScottGu , w tym skrypt do wyszukiwania podatnych aplikacji ASP.Net na twoim serwerze internetowym.

Aby uzyskać wyjaśnienie na temat „Zrozumienia ataków Oracle Padding”, przeczytaj odpowiedź @ sri .

Komentarze do artykułu:

Atak przeprowadzony przez Rizzo i Duonga na aplikacje ASP.NET wymaga, aby implementacja kryptograficzna w witrynie sieci Web miała wyrocznię, która po wysłaniu tekstu zaszyfrowanego nie tylko odszyfruje tekst, ale przekaże nadawcy wiadomość o tym, czy wypełnienie w tekście zaszyfrowanym jest ważny .

Jeśli wypełnienie jest nieprawidłowe, komunikat o błędzie, który otrzyma nadawca, da mu informacje o sposobie działania procesu deszyfrowania witryny.

Aby atak zadziałał, muszą być spełnione następujące warunki:

• Twoja aplikacja musi wyświetlać komunikat o błędzie dotyczący nieprawidłowego wypełnienia.
• Ktoś musi manipulować zaszyfrowanymi plikami cookie lub stanem wyświetlania

Jeśli więc zwrócisz czytelne dla człowieka komunikaty o błędach, takie jak „Coś poszło nie tak, spróbuj ponownie”, to powinieneś być całkiem bezpieczny. Przeczytanie trochę komentarzy na temat tego artykułu również dostarcza cennych informacji.

• Przechowuj identyfikator sesji w zaszyfrowanym pliku cookie
• Przechowuj rzeczywiste dane w stanie sesji (utrwalone w db)
• Dodaj losowe oczekiwanie, gdy informacje o użytkowniku są błędne, zanim zwrócisz błąd, więc nie możesz go zmierzyć

W ten sposób przechwycone ciasteczko może być użyte tylko do odzyskania sesji, która najprawdopodobniej nie jest już obecna lub unieważniona.

Ciekawie będzie zobaczyć, co faktycznie zostanie zaprezentowane na konferencji Ekoparty, ale teraz nie martwię się zbytnio o tę podatność.

Zrozumienie Padding Oracle Attacks

Załóżmy, że twoja aplikacja akceptuje zaszyfrowany ciąg jako parametr - niezależnie od tego, czy jest to plik cookie, parametr adresu URL czy coś innego jest nieistotne. Gdy aplikacja próbuje go zdekodować, istnieją 3 możliwe wyniki -

1. Rezultat 1 : Zaszyfrowany ciąg został poprawnie odszyfrowany, a aplikacja mogła go zrozumieć. Oznacza to, że jeśli zaszyfrowany ciąg był 10-cyfrowym numerem konta, po odszyfrowaniu aplikacja znalazła coś w rodzaju „1234567890”, a nie „abcd1213ef”

2. Rezultat 2 : Wypełnienie było prawidłowe, ale po odszyfrowaniu uzyskany ciąg był bełkotem, którego aplikacja nie mogła zrozumieć. Na przykład ciąg odszyfrowano do „abcd1213ef”, ale aplikacja spodziewała się tylko liczb. Większość aplikacji wyświetli komunikat „Nieprawidłowy numer konta”.

3. Rezultat 3 : Dopełnienie było niepoprawne, a aplikacja zgłosiła komunikat o błędzie. Większość aplikacji wyświetla ogólny komunikat typu „Wystąpił błąd”.

Aby atak Padding Oracle zakończył się powodzeniem, osoba atakująca musi mieć możliwość wysłania kilku tysięcy żądań, i musi być w stanie bezbłędnie zaklasyfikować odpowiedź do jednego z powyższych 3 segmentów.

Jeśli te dwa warunki zostaną spełnione, osoba atakująca może ostatecznie odszyfrować wiadomość, a następnie ponownie ją zaszyfrować za pomocą dowolnej opcji. To tylko kwestia czasu.

Co można zrobić, aby temu zapobiec?

1. Najprostsza rzecz - nic wrażliwego nigdy nie powinno być wysyłane do klienta, szyfrowane lub nieszyfrowane. Zachowaj na serwerze.

2. Upewnij się, że atakujący 2 i wynik z powyższej listy wyglądają dokładnie tak samo dla atakującego. Nie powinno być sposobu, aby zrozumieć jedno z drugiego. Nie jest to jednak takie łatwe - atakujący może dyskryminować za pomocą pewnego rodzaju ataku czasowego.

3. Ostatnią linią obrony jest zapora sieciowa. Atak typu padding oracle musi wykonać kilka żądań, które wyglądają prawie podobnie (zmieniają się jeden bit na raz), więc WAF powinien mieć możliwość wychwycenia i zablokowania takich żądań.

PS Dobre objaśnienie ataków padding Oracle można znaleźć w tym poście na blogu . Uwaga: To NIE jest mój blog.

Z tego co czytałem do tej pory ...

Atak umożliwia odszyfrowanie wąchanych plików cookie, które mogą zawierać cenne dane, takie jak salda bankowe

Potrzebują zaszyfrowanego pliku cookie użytkownika, który był już zalogowany na dowolnym koncie. Muszą także znaleźć dane w ciasteczkach - mam nadzieję, że programiści nie przechowują krytycznych danych w ciasteczkach :). I jest sposób, który mam poniżej, aby nie pozwolić asp.net przechowywać dane w pliku cookie logowania.

Jak ktoś może uzyskać plik cookie użytkownika, który jest online, jeśli nie dostanie danych przeglądarki? Lub wąchać pakiet IP?

Jednym ze sposobów, aby temu zapobiec, jest uniemożliwienie transportu plików cookie bez szyfrowania ssl.

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

Kolejnym środkiem jest zapobieganie przechowywaniu ról w ciasteczkach.

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

Teraz, jeśli chodzi o pliki cookie, które nie są bezpieczne dla zwykłych stron, wymaga to trochę więcej zastanowienia się nad tym, co zostawiłeś użytkownikowi, a co nie, w jaki sposób mu ufasz, jakie dodatkowe kontrole możesz zrobić (na przykład, jeśli zauważysz zmianę na ip , może przestań mu ufać, aż ponownie zalogujesz się na stronie bezpieczeństwa).

Odniesienie:
Czy jakiś haker może ukraść plik cookie od użytkownika i zalogować się przy użyciu tej nazwy na stronie internetowej?

Jak sprawdzić, skąd pochodzą ataki i nie przekazywać informacji. Napisałem tutaj prosty sposób, aby zapobiec dopełnieniu jest nieprawidłowe, a logowanie w tym samym czasie w celu wyśledzenia atakujących: CryptographicException: Dopełnienie jest nieprawidłowe i nie można go usunąć, a sprawdzanie poprawności adresu MAC stanu nie powiodło się

Sposób na śledzenie atakującego polega na sprawdzeniu, czy wypełnienie jest nieprawidłowe. Za pomocą prostej procedury możesz je wyśledzić i zablokować - potrzebują kilku tysięcy połączeń na twojej stronie, aby znaleźć klucz!

Aktualizacja 1.

Pobrałem narzędzie, które przypuszcza, że ​​znajduje KLUCZ i odszyfrowuje dane, i jak mówię, jego pułapka na powyższy kod, który sprawdza stan widoku . Z moich testów to narzędzie ma wiele więcej do naprawienia, na przykład nie może skanować stanu widoku skompresowanego, jak jest, i jego awarii w moich testach.

Jeśli ktoś spróbuje użyć tego narzędzia lub tej metody, powyższy kod może je wyśledzić i można zablokować je ze strony za pomocą prostego kodu, takiego jak ten „Zapobieganie odmowie usługi (DOS)” , lub podobnego kodu do zapobiegania odmowie usługi .

Aktualizacja 2

Z tego, co czytałem do tej pory, wydaje się, że jedyna myśl, która jest naprawdę potrzebna, aby nie dawać informacji o błędzie i po prostu umieścić niestandardową stronę błędu, a jeśli chcesz, możesz po prostu utworzyć i losowe opóźnienie na tej stronie.

bardzo ciekawe wideo na ten temat.

Tak więc wszystko to oznacza więcej środków w celu zapewnienia większej ochrony, ale nie jest w 100% konieczne w przypadku tego konkretnego problemu. Na przykład użycie pliku cookie ssl rozwiązuje problem snif, a nie buforowanie ról w ciasteczkach, dobrze jest nie wysyłać i nie odzyskiwać dużych plików cookie, a także uniknąć sytuacji, w której ktoś jest gotowy złamać kod, po prostu umieszczając rolę administratora na jego ciastko.

Stan widoku śledzi tylko jeden krok do znalezienia ataku.

Oto odpowiedź MS. Wszystko sprowadza się do „skorzystania z niestandardowej strony błędu” i nie będziesz rozdawać żadnych wskazówek.

EDYCJA
Oto kilka bardziej szczegółowych informacji ze scottgu.

Dodanie odpowiedzi ScottGu zaczerpniętych z dyskusji na stronie http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Czy ma to wpływ na niestandardowy moduł IHttpModule zamiast customErrors?

P: Nie mam elementu zadeklarowanego w moim pliku web.config, zamiast tego mam IHttpModule wewnątrz sekcji. Ten moduł rejestruje błąd i przekierowuje na stronę wyszukiwania (dla 404) lub na stronę błędu (dla 500). Czy jestem wrażliwy?

Odp .: Poleciłbym tymczasowo zaktualizować moduł, aby zawsze przekierowywał na stronę wyszukiwania. Jednym ze sposobów działania tego ataku jest szukanie rozróżnienia między błędami 404 a 500. Zawsze zwracanie tego samego kodu HTTP i wysyłanie go w to samo miejsce jest jednym ze sposobów na jego zablokowanie.

Zauważ, że kiedy łatka pojawi się, aby to naprawić, nie będziesz musiał tego robić (i możesz przywrócić stare zachowanie). Ale na razie nie polecam klientom rozróżniania między 404 a 500.

Czy mogę nadal używać różnych błędów dla błędów 404 i 500?

P: Rozumiem, że nadal możemy zdefiniować niestandardową stronę 404 oprócz domyślnego przekierowania w przypadku błędu, bez naruszania zasad opisanych powyżej?

Odp .: Nie - dopóki nie opublikujemy łatki dla prawdziwej poprawki, zalecamy powyższe obejście, które ujednolica wszystkie błędy. Jednym ze sposobów działania tego ataku jest szukanie rozróżnienia między błędami 404 a 500. Zawsze zwracanie tego samego kodu HTTP i wysyłanie go w to samo miejsce jest jednym ze sposobów na jego zablokowanie.

Zauważ, że kiedy łatka pojawi się, aby to naprawić, nie będziesz musiał tego robić (i możesz przywrócić stare zachowanie). Ale na razie nie powinieneś rozróżniać klientów od 404 do 500.

W jaki sposób umożliwia to ujawnienie pliku web.config?

P: W jaki sposób umożliwia to ujawnienie pliku web.config? Wydaje się, że pozwala to na odszyfrowanie tylko ViewState, czy istnieje inna powiązana luka, która umożliwia również ujawnienie informacji? Czy jest jakaś biała kartka opisująca atak, aby lepiej wyjaśnić, co się dzieje?

Odp .: Atak pokazany publicznie opiera się na funkcji w ASP.NET, która umożliwia pobieranie plików (zazwyczaj javascript i css) i która jest zabezpieczona kluczem wysyłanym jako część żądania. Niestety, jeśli możesz sfałszować klucz, możesz użyć tej funkcji do pobrania pliku web.config aplikacji (ale nie plików spoza aplikacji). Oczywiście wydamy łatkę do tego - do tego czasu powyższe obejście zamyka wektor ataku.

EDYCJA: dodatkowe FAQ dostępne w drugim blogu na http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

IMO nie ma na to ogólnego zapobiegania, należy postępować indywidualnie dla każdego przypadku:

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

Kilka istotnych linków:

• Poradnik bezpieczeństwa MS 2416728 (jest to oficjalna informacja)
• Dodatkowe informacje od zespołu ds. Badań i obrony bezpieczeństwa MS
  • „Zrozumienie luki w zabezpieczeniach programu ASP.NET” (2010-09-17)
  • „Dodatkowe informacje o luce w zabezpieczeniach programu ASP.NET” (2010-09-20)
• Scott Gu: „Ważne: Luka w zabezpieczeniach programu ASP.NET związana z bezpieczeństwem” (18.09.2010)

[Aby odpowiedzieć na poważny aspekt tego (co zostało opublikowane, a obejścia są objęte innymi odpowiedziami).]

Atakowany klucz służy do ochrony plików cookie zarówno stanu przeglądania, jak i sesji. Zwykle ten klucz jest generowany wewnętrznie przez ASP.NET przy każdym nowym wystąpieniu aplikacji sieci web. Ograniczy to zakres szkód do czasu życia procesu roboczego, oczywiście w przypadku pracowitej aplikacji mogą to być dni (tj. Niewielki limit). W tym czasie atakujący może zmienić (lub wstrzyknąć) wartości do ViewState i zmienić swoją sesję.

Jeszcze poważniej, jeśli chcesz, aby sesje mogły obejmować okresy istnienia procesów roboczych lub zezwalały farmom internetowym (tj. Wszystkie instancje w farmie mogą obsługiwać dowolną sesję użytkownika), klucz musi być zakodowany na stałe, odbywa się to w web.config:

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

Są to oczywiście nowo utworzone klucze. Korzystam z następującego programu PowerShell, aby uzyskać dostęp do kryptograficznego generatora liczb losowych w systemie Windows:

$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}

(Przy użyciu tablicy o długości 20 do sprawdzania poprawności i 16 do kluczy deszyfrujących).

Oprócz modyfikowania publicznych stron błędów, aby nie wyciekły z określonego błędu, wydaje się, że to dobry moment na zmianę powyższych kluczy (lub cykliczne procesy robocze, jeśli były uruchomione przez jakiś czas).

[Edytuj 2010-09-21: Dodano linki do góry]

Właśnie opublikowałem swoje pełne zdanie na ten temat na moim blogu , po dodatkowych badaniach na ten temat. Myślę, że ważne jest wyjaśnienie, dlaczego posuwają się tak daleko, jak fałszowanie pliku cookie uwierzytelniania.

Chcę tylko wyjaśnić kilka faktów:

1. atak nie pozwala uzyskać klucza maszyny bezpośrednio. To powiedziawszy, jest prawie tak, jak miało, ponieważ pozwala odszyfrować wiadomości i zmodyfikować ponownie / zaszyfrować nowe.
2. sposób, w jaki uzyskuje się rzeczywiste klucze, polega na ich zdolności do modyfikowania ponownego / szyfrowania jak w 1 i pobrania pliku web.config. Niestety istnieją powody, dla których niektórzy umieszczają te klucze w pliku web.config na poziomie witryny (inna dyskusja), aw przykładowym wideo korzystają z tego, że jest domyślną wersją DotnetNuke.
3. aby pobrać web.config, wszystkie wskazują, że używają webresources.axd i / lub scriptresources.axd. Myślałem, że działają one tylko z osadzonymi zasobami, ale wydaje się, że tak nie jest.
4. jeśli aplikacja to asp.net MVC, tak naprawdę nie potrzebujemy webresources.axd i / lub scriptresources.axd, więc można je wyłączyć. Nie korzystamy również z viewstate. To powiedziawszy, nie jest dla mnie jasne, czy którakolwiek z innych funkcji asp.net daje inne informacje z tym obejściem, tj. Nie wiem, czy wypełnianie daje nieprawidłowe wyniki błędu, podczas gdy wypełnianie poprawnych wyników powoduje ignorowanie biletu uwierzytelnienia (nie wiem jeśli tak jest lub nie) ... ta sama analiza powinna mieć zastosowanie do pliku cookie sesji.
5. Dostawca członkostwa w asp.net „buforuje” role w ciasteczkach, wyłącz to.

Około 1, afaik, zaszyfrowane wiadomości nie mogą być w 100% arbitralne, aby tolerować niewielki kawałek śmieci gdzieś w wiadomości, ponieważ w wiadomości jest 1 blok, który odszyfrowuje wartość, której nie można kontrolować.

Na koniec chciałbym powiedzieć, że ten problem wynika z nieprzestrzegania przez MS własnych wskazówek w tym przypadku: funkcja polega na tym, że coś wysyłane do klienta jest odporne na manipulację.

Więcej na:

Nie wiem, czy wypełnianie daje błędne wyniki, a wypełnianie poprawnych wyników ignorowanym biletem uwierzytelniającym (nie wiem, czy tak jest) ... taka sama analiza powinna mieć zastosowanie do pliku cookie sesji.

Autoryzowany plik cookie jest podpisany, a na podstawie informacji w gazecie nie powinni być w stanie wygenerować podpisanego pliku cookie, jeśli nie uzyskają rzeczywistych kluczy (tak jak to zrobili w filmie przed sfałszowaniem automatycznego pliku cookie).

Jak wspomniał Aristos, identyfikator sesji w pliku cookie jest losowy dla sesji użytkownika, więc musiałby być wąchany przez użytkownika o docelowym poziomie bezpieczeństwa i łamany, gdy sesja jest aktywna. Nawet wtedy, gdy polegasz na uwierzytelnianiu w celu przypisania / autoryzacji operacji użytkownika, wpływ byłby minimalny / wiele zależy od tego, do czego służy sesja w tej aplikacji.

Poprawka dla tego błędu została wydana w Windows Update: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Problem ten dotyczy również Asp.Net MVC (podobnie jak Sharepoint, ...)

Omówiłem tutaj poprawkę dla MVC: Czy ASP.NET MVC jest podatny na atak padania wyroczni?