Seberapa serius kerentanan keamanan ASP.NET baru ini dan bagaimana cara mengatasinya?

Saya baru saja membaca di internet tentang kerentanan keamanan yang baru ditemukan di ASP.NET. Anda dapat membaca detailnya di sini.

Masalahnya terletak pada cara ASP.NET mengimplementasikan algoritma enkripsi AES untuk melindungi integritas cookie yang dihasilkan aplikasi ini untuk menyimpan informasi selama sesi pengguna.

Ini agak kabur, tetapi di sini ada bagian yang lebih menakutkan:

Tahap pertama serangan membutuhkan beberapa ribu permintaan, tetapi begitu berhasil dan penyerang mendapatkan kunci rahasia, itu benar-benar tersembunyi. Pengetahuan kriptografi yang diperlukan sangat mendasar.

Secara keseluruhan, saya tidak cukup akrab dengan subjek keamanan / cryptograpy untuk mengetahui apakah ini benar-benar serius.

Jadi, haruskah semua pengembang ASP.NET takut akan teknik ini yang dapat memiliki situs web ASP.NET dalam hitungan detik atau apa?

Bagaimana masalah ini mempengaruhi rata-rata pengembang ASP.NET? Apakah itu mempengaruhi kita? Dalam kehidupan nyata, apa konsekuensi dari kerentanan ini? Dan, akhirnya: apakah ada solusi yang mencegah kerentanan ini?

Terima kasih atas jawaban Anda!

EDIT: Biarkan saya meringkas tanggapan yang saya dapatkan

Jadi, ini pada dasarnya adalah jenis serangan "padding oracle". @Sri memberikan penjelasan yang bagus tentang apa arti jenis serangan ini. Berikut adalah video yang mengejutkan tentang masalah ini!

Tentang keseriusan kerentanan ini: Ya, memang serius. Ini memungkinkan penyerang untuk mengetahui kunci mesin suatu aplikasi. Dengan demikian, ia dapat melakukan beberapa hal yang sangat tidak diinginkan.

• Dalam posisi kunci mesin aplikasi, penyerang dapat mendekripsi cookie otentikasi.
• Bahkan lebih buruk dari itu, ia dapat menghasilkan cookie otentikasi dengan nama pengguna mana pun. Dengan demikian, ia dapat muncul sebagai siapa pun di situs. Aplikasi tidak dapat membedakan antara Anda atau peretas yang membuat cookie autentikasi dengan nama Anda untuk dirinya sendiri.
• Ini juga memungkinkan dia untuk mendekripsi (dan juga menghasilkan) cookie sesi , meskipun ini tidak berbahaya seperti yang sebelumnya.
• Tidak terlalu serius: Dia bisa mendekripsi ViewState halaman yang dienkripsi. (Jika Anda menggunakan ViewState untuk menyimpan data rahasia, Anda tidak boleh melakukan ini lagi!)
• Cukup tak terduga : Dengan pengetahuan tentang kunci mesin, penyerang dapat mengunduh file sewenang-wenang dari aplikasi web Anda, bahkan yang biasanya tidak dapat diunduh! (Termasuk Web.Config , dll.)

Berikut adalah beberapa praktik baik yang saya dapatkan yang tidak menyelesaikan masalah tetapi membantu meningkatkan keamanan umum aplikasi web.

• Anda dapat mengenkripsi data sensitif dengan Konfigurasi Terlindungi
• Gunakan cookie Hanya HTTP
• Cegah serangan DoS

Sekarang, mari kita fokus pada masalah ini.

• Scott Guthrie menerbitkan sebuah entri tentang itu di blog-nya
• Posting blog FAQG ScottGu tentang kerentanan
• Pembaruan ScottGu tentang kerentanan
• Microsoft memiliki penasihat keamanan tentang hal itu
• Memahami kerentanan
• Informasi tambahan tentang kerentanan

Solusinya

• Aktifkan customErrors dan buat satu halaman kesalahan tempat semua kesalahan dialihkan. Ya, bahkan 404-an . (ScottGu mengatakan bahwa membedakan antara 404-an dan 500-an sangat penting untuk serangan ini.) Juga, ke dalam Anda Application_Erroratau Error.aspxmasukkan beberapa kode yang membuat penundaan acak. (Hasilkan nomor acak, dan gunakan Thread. Tidur untuk tidur selama itu.) Ini akan membuat mustahil bagi penyerang untuk memutuskan apa yang sebenarnya terjadi di server Anda.
• Beberapa orang merekomendasikan untuk beralih kembali ke 3DES. Secara teori, jika Anda tidak menggunakan AES, Anda tidak menemukan kelemahan keamanan dalam implementasi AES. Ternyata, ini tidak dianjurkan sama sekali .

Beberapa pemikiran lain

• Tampaknya tidak semua orang berpikir solusinya cukup baik.

Terima kasih untuk semua orang yang menjawab pertanyaan saya. Saya belajar banyak tentang tidak hanya masalah ini, tetapi keamanan web secara umum. Saya menandai jawaban @ Mikael sebagai diterima, tetapi jawaban lainnya juga sangat berguna.

Apa yang harus saya lakukan untuk melindungi diri saya sendiri?

[Pembaruan 2010-09-29]

Buletin keamanan Microsoft

Artikel KB dengan referensi untuk memperbaiki

ScottGu memiliki tautan untuk unduhan

[Pembaruan 2010-09-25]

Sementara kami menunggu perbaikan, kemarin ScottGu memposting pembaruan tentang cara menambahkan langkah ekstra untuk melindungi situs Anda dengan aturan URLScan khusus.

Selain itu tambahkan waktu tidur acak di halaman kesalahan untuk mencegah penyerang dari waktu tanggapan untuk informasi serangan tambahan.

Di web.config

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

Ini akan mengarahkan kesalahan apa pun ke halaman khusus yang dikembalikan dengan 200 kode status. Dengan cara ini penyerang tidak dapat melihat kode kesalahan atau informasi kesalahan untuk informasi yang diperlukan untuk serangan lebih lanjut.

Juga aman untuk diatur customErrors mode="RemoteOnly", karena ini akan mengarahkan ulang klien "nyata". Hanya menjelajah dari localhost yang akan menunjukkan kesalahan .Net internal.

Bagian yang penting adalah memastikan bahwa semua kesalahan dikonfigurasi untuk mengembalikan halaman kesalahan yang sama. Ini mengharuskan Anda untuk secara eksplisit mengatur defaultRedirectatribut pada <customErrors>bagian tersebut dan memastikan bahwa tidak ada kode per-status yang ditetapkan.

Apa yang dipertaruhkan?

Jika penyerang berhasil menggunakan exploit tersebut, ia dapat mengunduh file internal dari dalam aplikasi web Anda. Biasanya web.config adalah target dan mungkin berisi informasi sensitif seperti informasi login dalam string koneksi database, atau bahkan tautan ke database sql-express otomatis yang tidak Anda inginkan ada orangnya. Tetapi jika Anda mengikuti praktik terbaik, Anda menggunakan Konfigurasi Terlindungi untuk mengenkripsi semua data sensitif di web.config Anda.

Tautan ke referensi

Baca komentar resmi Microsoft tentang kerentanan di http://www.microsoft.com/technet/security/advisory/2416728.mspx . Khususnya bagian "Penanganan Masalah" untuk detail implementasi tentang masalah ini.

Juga beberapa informasi di blog ScottGu , termasuk skrip untuk menemukan aplikasi ASP.Net yang rentan di server web Anda.

Untuk penjelasan tentang "Memahami Padding Oracle Attacks", baca jawaban @ sri .

Komentar untuk artikel:

Serangan yang diterapkan oleh Rizzo dan Duong terhadap aplikasi ASP.NET mensyaratkan bahwa implementasi kripto di situs Web memiliki oracle bahwa, ketika mengirim ciphertext, tidak hanya akan mendekripsi teks tetapi memberikan pengirim pesan tentang apakah bantalan dalam ciphertext valid .

Jika padding tidak valid, pesan kesalahan yang diterima pengirim akan memberinya beberapa informasi tentang cara proses dekripsi situs bekerja.

Agar serangan berhasil, yang berikut ini harus benar:

• Aplikasi Anda harus memberikan pesan kesalahan tentang padding yang tidak valid.
• Seseorang harus mengutak-atik cookie terenkripsi atau kondisi tampilan Anda

Jadi, jika Anda mengembalikan pesan kesalahan yang dapat dibaca manusia di aplikasi Anda seperti "Ada yang salah, silakan coba lagi" maka Anda seharusnya cukup aman. Membaca sedikit di komentar pada artikel juga memberikan informasi berharga.

• Menyimpan id sesi di cookie yang di-crypted
• Menyimpan data nyata dalam keadaan sesi (bertahan dalam db)
• Tambahkan tunggu acak ketika informasi pengguna salah sebelum mengembalikan kesalahan, jadi Anda tidak dapat menghitung waktunya

Dengan cara itu cookie yang dibajak hanya dapat digunakan untuk mengambil sesi yang kemungkinan besar tidak lagi ada atau tidak valid.

Akan menarik untuk melihat apa yang sebenarnya disajikan pada konferensi Ekoparty, tetapi saat ini saya tidak terlalu khawatir tentang kerentanan ini.

Memahami Padding Serangan Oracle

Mari kita asumsikan aplikasi Anda menerima string terenkripsi sebagai parameter - apakah parameter itu cookie, parameter url atau yang lainnya tidak penting. Ketika aplikasi mencoba memecahkan kode itu, ada 3 hasil yang mungkin -

1. Hasil 1 : String terenkripsi didekripsi dengan benar, dan aplikasi dapat memahaminya. Berarti, jika string terenkripsi adalah nomor akun 10 digit, setelah dekripsi aplikasi menemukan sesuatu seperti "1234567890" dan bukan "abcd1213ef"

2. Hasil 2 : Padding-nya benar, tetapi setelah dekripsi string yang didapat adalah omong kosong yang tidak bisa dipahami oleh aplikasi. Misalnya, string didekripsi ke "abcd1213ef", tetapi aplikasi hanya mengharapkan angka. Sebagian besar aplikasi akan menampilkan pesan seperti "Nomor akun tidak valid".

3. Hasil 3 : Padding salah, dan aplikasi melempar beberapa jenis pesan kesalahan. Sebagian besar aplikasi akan menampilkan pesan umum seperti "Terjadi kesalahan".

Agar serangan Padding Oracle berhasil, penyerang harus dapat membuat beberapa ribu permintaan, dan harus dapat mengklasifikasikan respons menjadi salah satu dari 3 ember di atas tanpa kesalahan.

Jika kedua kondisi ini terpenuhi, penyerang akhirnya dapat mendekripsi pesan, dan kemudian mengenkripsi ulang dengan apa pun yang diinginkannya. Ini hanya masalah waktu.

Apa yang bisa dilakukan untuk mencegahnya?

1. Hal paling sederhana - apa pun yang sensitif tidak boleh dikirim ke klien, dienkripsi atau tidak dienkripsi. Simpan di server.

2. Pastikan bahwa hasil 2 dan hasil 3 dalam daftar di atas muncul persis sama dengan penyerang. Seharusnya tidak ada cara untuk mencari tahu satu dari yang lain. Ini tidak semudah itu - penyerang dapat membedakan menggunakan beberapa jenis serangan waktu.

3. Sebagai garis pertahanan terakhir, miliki Firewall Aplikasi Web. Serangan padding oracle perlu membuat beberapa permintaan yang terlihat hampir mirip (berubah sedikit demi sedikit), sehingga WAF dimungkinkan untuk menangkap dan memblokir permintaan tersebut.

PS Penjelasan yang baik tentang Padding Oracle Attacks dapat ditemukan di posting blog ini . Penafian: Ini BUKAN blog saya.

Dari apa yang saya baca sampai sekarang ...

Serangan itu memungkinkan seseorang untuk mendekripsi cookie yang terhirup, yang bisa berisi data berharga seperti saldo bank

Mereka memerlukan cookie terenkripsi dari pengguna yang sudah masuk, pada akun apa pun. Mereka juga perlu menemukan data dalam cookie - Saya harap pengembang tidak menyimpan data penting dalam cookie :). Dan ada cara yang saya miliki di bawah ini untuk tidak membiarkan asp.net menyimpan data dalam cookie login.

Bagaimana seseorang bisa mendapatkan cookie dari pengguna yang sedang online jika dia tidak mendapatkan data browser? Atau mengendus paket IP?

Salah satu cara untuk mencegahnya adalah dengan tidak mengizinkan cookie untuk dikirim tanpa enkripsi ssl.

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

Juga satu langkah lagi adalah mencegah menyimpan Peran dalam cookie.

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

Sekarang tentang cookie yang tidak aman untuk halaman reguler, ini perlu lebih banyak dipikirkan apa yang Anda lakukan meninggalkan pengguna Anda dan apa yang tidak, bagaimana Anda mempercayainya, pemeriksaan tambahan apa yang dapat Anda lakukan (misalnya jika Anda melihat perubahan pada ip , mungkin berhenti percaya padanya sampai masuk lagi dari halaman keamanan).

Referensi:
Bisakah beberapa hacker mencuri cookie dari pengguna dan login dengan nama itu di situs web?

Cara memeriksa dari mana serangan datang dan tidak memberikan kembali informasi. Saya menulis di sini cara sederhana untuk mencegah padding tidak valid dan login pada saat yang sama untuk melacak penyerang: CryptographicException: Padding tidak valid dan tidak dapat dihapus dan Validasi viewstate MAC gagal

Cara untuk melacak penyerang adalah dengan memeriksa padding yang tidak valid. Dengan prosedur sederhana, Anda dapat melacak dan memblokirnya - mereka membutuhkan ribuan panggilan pada halaman Anda untuk menemukan kunci!

Perbarui 1.

Saya telah mengunduh alat yang mengira itu menemukan KUNCI dan mendekripsi data, dan seperti yang saya katakan perangkap pada kode di atas yang memeriksa kondisi tampilan . Dari pengujian saya, alat ini memiliki lebih banyak untuk diperbaiki, misalnya tidak dapat memindai keadaan tampilan terkompresi seperti apa adanya dan crash pada pengujian saya.

Jika seseorang mencoba menggunakan alat ini atau metode ini, kode di atas dapat melacaknya dan Anda dapat memblokirnya dari halaman Anda dengan kode sederhana seperti ini "Prevent Denial Of Service (DOS)" , atau seperti kode ini untuk mencegah Penolakan layanan .

Perbarui 2

Tampaknya dari apa yang saya baca sampai sekarang bahwa hanya berpikir yang benar-benar memerlukannya untuk tidak memberikan informasi kembali tentang kesalahan , dan hanya menempatkan halaman kesalahan khusus dan jika Anda suka, Anda dapat membuat dan menunda acak ke halaman ini.

video yang sangat menarik tentang masalah ini.

Jadi semua hal di atas lebih untuk perlindungan lebih tetapi tidak 100% diperlukan untuk masalah khusus ini. Sebagai contoh untuk menggunakan cookie ssl adalah menyelesaikan masalah snif, yang tidak men-cache Peran dalam cookie itu baik untuk tidak mengirim dan mendapatkan kembali cookie besar, dan untuk menghindari seseorang yang semuanya siap memecahkan kode, untuk hanya menempatkan peran admin di kue dia.

Kondisi tampilan hanya melacak satu langkah lagi untuk menemukan serangan.

Inilah tanggapan MS. Semuanya bermuara pada "gunakan halaman kesalahan khusus" dan Anda tidak akan memberikan petunjuk apa pun.

EDIT
Berikut adalah beberapa informasi lebih rinci dari scottgu.

Menambahkan tanggapan ScottGu diambil dari diskusi di http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Apakah kustom IHttpModule bukan customErrors yang terpengaruh?

T: Saya tidak memiliki elemen yang dideklarasikan di web.config saya, saya memiliki IHttpModule di dalam bagian. Modul ini mencatat kesalahan dan mengalihkan ke halaman pencarian (untuk 404's) atau ke halaman kesalahan (untuk 500's). Apakah saya rentan?

A: Saya akan merekomendasikan sementara memperbarui modul untuk selalu mengarahkan ke halaman pencarian. Salah satu cara serangan ini bekerja adalah mencari perbedaan antara 404 dan 500 kesalahan. Selalu mengembalikan kode HTTP yang sama dan mengirimkannya ke tempat yang sama adalah salah satu cara untuk membantu memblokirnya.

Perhatikan bahwa ketika tambalan keluar untuk memperbaikinya, Anda tidak perlu melakukan ini (dan dapat kembali ke perilaku lama). Tetapi untuk saat ini saya akan merekomendasikan untuk tidak membedakan antara 404 dan 500 untuk klien.

Bisakah saya terus menggunakan kesalahan yang berbeda untuk kesalahan 404 dan 500?

T: Saya mengerti kita masih dapat memiliki halaman kustom 404 yang didefinisikan sebagai tambahan dari redirect default pada kesalahan, tanpa melanggar prinsip-prinsip yang dijelaskan di atas?

A: Tidak - sampai kami merilis patch untuk perbaikan nyata, kami menyarankan solusi di atas yang menyeragamkan semua kesalahan. Salah satu cara serangan ini bekerja adalah mencari perbedaan antara 404 dan 500 kesalahan. Selalu mengembalikan kode HTTP yang sama dan mengirimkannya ke tempat yang sama adalah salah satu cara untuk membantu memblokirnya.

Perhatikan bahwa ketika tambalan keluar untuk memperbaikinya, Anda tidak perlu melakukan ini (dan dapat kembali ke perilaku lama). Tetapi untuk saat ini Anda tidak boleh membedakan antara 404-an dan 500-an dengan klien.

Bagaimana ini memungkinkan pemaparan web.config?

T: Bagaimana ini memungkinkan pemaparan web.config? Ini tampaknya hanya mengaktifkan mendekripsi dari ViewState, apakah ada kerentanan terkait lainnya yang juga memungkinkan pengungkapan informasi? Apakah ada whitepaper yang merinci serangan untuk penjelasan yang lebih baik tentang apa yang terjadi?

A: Serangan yang ditampilkan di publik bergantung pada fitur di ASP.NET yang memungkinkan file (biasanya javascript dan css) untuk diunduh, dan yang diamankan dengan kunci yang dikirim sebagai bagian dari permintaan. Sayangnya jika Anda dapat memalsukan kunci, Anda dapat menggunakan fitur ini untuk mengunduh file web.config suatu aplikasi (tetapi bukan file di luar aplikasi). Kami jelas akan merilis patch untuk ini - sampai saat itu solusi di atas menutup vektor serangan.

EDIT: FAQ tambahan tersedia di blogpost kedua di http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

IMO, tidak ada pencegahan yang menyeluruh untuk ini, perlu ditangani berdasarkan kasus per kasus:

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

Beberapa tautan penting:

• Penasihat Keamanan MS '2416728 (ini adalah informasi resmi)
• Informasi tambahan dari tim Penelitian & Pertahanan Keamanan MS
  • "Memahami Kerentanan ASP.NET" (2010-09-17)
  • "Informasi Tambahan tentang Kerentanan ASP.NET" (2010-09-20)
• Scott Gu: "Penting: Kerentanan Keamanan ASP.NET" (2010-09-18)

[Untuk menjawab aspek keseriusan ini (apa yang telah dipublikasikan dan penyelesaiannya diliputi oleh jawaban lain)]

Kunci yang diserang digunakan untuk melindungi keadaan tampilan dan cookie sesi. Biasanya kunci ini dihasilkan secara internal oleh ASP.NET dengan setiap instance baru aplikasi web. Ini akan membatasi ruang lingkup kerusakan pada masa kerja proses pekerja, tentu saja untuk aplikasi yang sibuk ini bisa berhari-hari (yaitu tidak banyak batasnya). Selama waktu ini penyerang dapat mengubah (atau menyuntikkan) nilai ke dalam kondisi tampilan dan mengubah sesi mereka.

Bahkan lebih serius jika Anda ingin sesi dapat menjangkau masa kerja proses pekerja, atau mengizinkan web farm (yaitu semua contoh di farm dapat menangani sesi pengguna apa pun) kuncinya perlu dikodekan secara keras, ini dilakukan di web.config:

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

Itu, tentu saja, kunci yang baru dibuat, saya menggunakan PowerShell berikut untuk mengakses generator nomor acak kriptografi 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}

(Menggunakan panjang array 20 untuk validasi dan 16 untuk kunci dekripsi.)

Selain memodifikasi halaman kesalahan publik untuk tidak membocorkan kesalahan spesifik, akan tampak saat yang tepat untuk mengubah kunci di atas (atau proses pekerja siklus jika sudah berjalan beberapa saat).

[Edit 2010-09-21: Tautan yang ditambahkan ke atas]

Saya baru saja memposting pandangan penuh saya tentang hal ini di blog saya , setelah penelitian ekstra tentang masalah ini. Saya pikir ini penting untuk menjelaskan mengapa mereka sampai sejauh memalsukan cookie auth.

Hanya ingin meluruskan beberapa fakta:

1. serangan tidak membiarkan Anda mendapatkan kunci mesin secara langsung. Yang mengatakan, itu cukup seperti itu, karena memungkinkan untuk mendekripsi pesan, dan memodifikasi ulang / mengenkripsi yang baru.
2. cara mendapatkan kunci yang sebenarnya adalah dengan menggunakan kemampuan mereka untuk memodifikasi ulang / mengenkripsi seperti pada 1 dan dapatkan web.config. Sayangnya ada beberapa alasan mengapa beberapa meletakkan kunci ini di web.config di tingkat situs (diskusi berbeda), dan dalam video contoh, mereka mendapat manfaat dari hal itu sebagai default dari DotnetNuke.
3. untuk mendapatkan web.config semuanya menunjukkan bahwa mereka menggunakan webresources.axd dan / atau scriptresources.axd. Saya pikir ini hanya bekerja dengan sumber daya tertanam, tetapi tampaknya itu tidak terjadi.
4. jika aplikasinya adalah asp.net MVC, kita tidak benar-benar membutuhkan webresources.axd dan / atau scriptresources.axd, sehingga itu bisa dimatikan. Kami juga tidak menggunakan kondisi tampilan. Yang mengatakan, tidak jelas bagi saya jika ada fitur asp.net lain memberikan info yang berbeda dengan solusi di tempat yaitu saya tidak tahu apakah padding memberikan hasil yang tidak benar dalam kesalahan sementara padding hasil yang valid dalam tiket otentikasi diabaikan (tidak tahu jika ini masalahnya atau tidak) ... analisis yang sama harus diterapkan pada cookie sesi.
5. peran 'cache' penyedia keanggotaan asp.net di cookie, matikan itu.

Sekitar 1, afaik pesan terenkripsi tidak dapat 100% sewenang-wenang untuk mentolerir sepotong kecil sampah di suatu tempat di pesan, karena ada 1 blok dalam pesan yang mendekripsi nilai yang tidak dapat dikendalikan.

Akhirnya saya ingin mengatakan bahwa masalah ini adalah hasil dari ms tidak mengikuti panduannya sendiri dalam hal ini: sebuah fitur bergantung pada sesuatu yang dikirim ke klien sebagai bukti perusakan.

Lebih lanjut tentang:

Saya tidak tahu apakah padding memberikan hasil yang tidak valid dalam kesalahan sementara padding hasil yang valid dalam tiket otentikasi yang diabaikan (tidak tahu apakah ini kasusnya atau tidak) ... analisis yang sama harus diterapkan pada cookie sesi.

Cookie auth ditandatangani, dan dari info di koran mereka seharusnya tidak dapat membuat cookie yang ditandatangani jika mereka tidak mendapatkan kunci yang sebenarnya (seperti yang mereka lakukan dalam video sebelum membuat cookie auth).

Seperti yang disebutkan Aristos, untuk id sesi dalam cookie, itu acak untuk sesi pengguna, jadi itu harus diendus dari pengguna dengan tingkat keamanan target dan retak saat sesi itu aktif. Bahkan jika Anda mengandalkan otentikasi untuk menetapkan / mengotorisasi operasi pengguna, maka dampaknya akan minimal / itu akan sangat tergantung pada apa Sesi digunakan untuk aplikasi itu.

Patch untuk bug ini telah dirilis pada Pembaruan Windows: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Asp.Net MVC juga dipengaruhi oleh masalah ini (seperti Sharepoint, ...)

Saya telah membahas perbaikan untuk MVC di sini: Apakah ASP.NET MVC rentan terhadap serangan padding oracle?