Lỗ hổng bảo mật ASP.NET mới này nghiêm trọng đến mức nào và làm cách nào để khắc phục nó?

Tôi vừa đọc trên mạng về một lỗ hổng bảo mật mới được phát hiện trong ASP.NET. Bạn có thể đọc chi tiết ở đây.

Vấn đề nằm ở chỗ ASP.NET thực hiện thuật toán mã hóa AES để bảo vệ tính toàn vẹn của cookie mà các ứng dụng này tạo ra để lưu trữ thông tin trong các phiên của người dùng.

Điều này hơi mơ hồ, nhưng đây là một phần đáng sợ hơn:

Giai đoạn đầu tiên của cuộc tấn công cần vài nghìn yêu cầu, nhưng một khi nó thành công và kẻ tấn công có được các khóa bí mật, nó hoàn toàn lén lút. Kiến thức về mật mã học là rất cơ bản.

Nói chung, tôi không đủ quen thuộc với chủ đề bảo mật / tiền điện tử để biết điều này có thực sự nghiêm trọng không.

Vì vậy, tất cả các nhà phát triển ASP.NET có sợ kỹ thuật này có thể sở hữu bất kỳ trang web ASP.NET nào trong vài giây hay không?

Vấn đề này ảnh hưởng đến nhà phát triển ASP.NET trung bình như thế nào? Nó có ảnh hưởng đến chúng ta không? Trong cuộc sống thực, hậu quả của lỗ hổng này là gì? Và, cuối cùng: có một số cách giải quyết ngăn chặn lỗ hổng này?

Cảm ơn câu trả lời của bạn!

EDIT: Hãy để tôi tóm tắt các câu trả lời tôi nhận được

Vì vậy, đây về cơ bản là một kiểu tấn công "sấm sét". @Sri cung cấp một lời giải thích tuyệt vời về ý nghĩa của kiểu tấn công này. Dưới đây là một video gây sốc về vấn đề này!

Về mức độ nghiêm trọng của lỗ hổng này: Vâng, nó thực sự nghiêm trọng. Nó cho phép kẻ tấn công làm quen với khóa máy của một ứng dụng. Vì vậy, anh ta có thể làm một số điều rất không mong muốn.

• Để xác định khóa máy của ứng dụng, kẻ tấn công có thể giải mã cookie xác thực.
• Thậm chí tệ hơn thế, anh ta có thể tạo cookie xác thực với tên của bất kỳ người dùng nào. Vì vậy, anh ta có thể xuất hiện như bất cứ ai trên trang web. Ứng dụng không thể phân biệt giữa bạn hoặc hacker đã tạo cookie xác thực với tên của bạn.
• Nó cũng cho phép anh ta giải mã (và cũng tạo ra) cookie phiên , mặc dù điều này không nguy hiểm như trước đây.
• Không quá nghiêm trọng: Anh ta có thể giải mã ViewState được mã hóa của các trang. (Nếu bạn sử dụng ViewState để lưu trữ dữ liệu tình cờ, bạn không nên làm điều này bằng mọi cách!)
• Khá bất ngờ : Với kiến ​​thức về khóa máy, kẻ tấn công có thể tải xuống bất kỳ tệp tùy ý nào từ ứng dụng web của bạn, ngay cả những tệp thông thường không thể tải xuống! (Bao gồm Web.Config , v.v.)

Đây là một loạt các thực tiễn tốt mà tôi đã nhận được mà không giải quyết được vấn đề mà giúp cải thiện tính bảo mật chung của một ứng dụng web.

• Bạn có thể mã hóa dữ liệu nhạy cảm với Cấu hình được bảo vệ
• Sử dụng cookie chỉ HTTP
• Ngăn chặn các cuộc tấn công DoS

Bây giờ, hãy tập trung vào vấn đề này.

• Scott Guthrie đã xuất bản một mục về nó trên blog của mình
• Blog FAQ của ScottGu về lỗ hổng
• Cập nhật về lỗ hổng của ScottGu
• Microsoft có một lời khuyên bảo mật về nó
• Hiểu về lỗ hổng
• Thông tin bổ sung về lỗ hổng

Giải pháp

• Bật customErrors và tạo một trang lỗi duy nhất mà tất cả các lỗi được chuyển hướng. Có, thậm chí 404s . (ScottGu nói rằng sự khác biệt giữa 404 và 500 là điều cần thiết cho cuộc tấn công này.) Ngoài ra, vào Application_Errorhoặc Error.aspxđặt một số mã gây chậm trễ ngẫu nhiên. (Tạo một số ngẫu nhiên và sử dụng Thread.S ngủ để ngủ lâu như vậy.) Điều này sẽ khiến kẻ tấn công không thể quyết định chính xác những gì đã xảy ra trên máy chủ của bạn.
• Một số người đề nghị chuyển trở lại 3DES. Về lý thuyết, nếu bạn không sử dụng AES, bạn sẽ không gặp phải điểm yếu bảo mật trong việc triển khai AES. Hóa ra, điều này không được khuyến khích chút nào .

Một số suy nghĩ khác

• Có vẻ như không phải ai cũng nghĩ cách giải quyết là đủ tốt.

Cảm ơn tất cả những người đã trả lời câu hỏi của tôi. Tôi đã học được rất nhiều về không chỉ vấn đề này, mà cả bảo mật web nói chung. Tôi đã đánh dấu câu trả lời của @ Mikael là được chấp nhận, nhưng các câu trả lời khác cũng rất hữu ích.

Tôi nên làm gì để bảo vệ bản thân?

[Cập nhật 2010-09-29]

Bản tin bảo mật của Microsoft

Điều KB có liên quan đến sửa chữa

ScottGu có các liên kết để tải xuống

[Cập nhật 2010-09-25]

Trong khi chúng tôi đang chờ khắc phục, hôm qua ScottGu đã đăng một bản cập nhật về cách thêm một bước bổ sung để bảo vệ trang web của bạn bằng quy tắc URLScan tùy chỉnh.

Ngoài ra, thêm một thời gian ngủ ngẫu nhiên trong trang lỗi để ngăn kẻ tấn công định thời gian cho các phản hồi để thêm thông tin tấn công.

Trong web.config

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

Điều này sẽ chuyển hướng bất kỳ lỗi nào đến một trang tùy chỉnh được trả lại với mã trạng thái 200. Bằng cách này, kẻ tấn công không thể nhìn vào mã lỗi hoặc thông tin lỗi để biết thông tin cần thiết cho các cuộc tấn công tiếp theo.

Nó cũng an toàn để thiết lập customErrors mode="RemoteOnly", vì điều này sẽ chuyển hướng các khách hàng "thực sự". Chỉ duyệt từ localhost sẽ hiển thị lỗi .Net nội bộ.

Phần quan trọng là đảm bảo rằng tất cả các lỗi được cấu hình để trả về cùng một trang lỗi. Điều này đòi hỏi bạn phải thiết lập rõ ràng defaultRedirectthuộc tính trên <customErrors>phần và đảm bảo rằng không có mã theo trạng thái nào được đặt.

Những gì bị đe dọa?

Nếu kẻ tấn công quản lý để sử dụng khai thác được đề cập, anh ấy / cô ấy có thể tải xuống các tệp nội bộ từ trong ứng dụng web của bạn. Thông thường web.config là mục tiêu và có thể chứa thông tin nhạy cảm như thông tin đăng nhập trong chuỗi kết nối cơ sở dữ liệu hoặc thậm chí liên kết đến cơ sở dữ liệu sql-express tự động mà bạn không muốn ai đó nắm giữ. Nhưng nếu bạn đang theo cách thực hành tốt nhất, bạn sử dụng Cấu hình được bảo vệ để mã hóa tất cả dữ liệu nhạy cảm trong web.config.

Liên kết đến tài liệu tham khảo

Đọc bình luận chính thức của Microsoft về lỗ hổng này tại http://www.microsoft.com/technet/security/advisory/2416728.mspx . Cụ thể là phần "Giải pháp" để biết chi tiết thực hiện về vấn đề này.

Ngoài ra một số thông tin trên blog của ScottGu , bao gồm tập lệnh để tìm các ứng dụng ASP.Net dễ bị tổn thương trên máy chủ web của bạn.

Để được giải thích về "Hiểu về tấn công đệm của Oracle", hãy đọc câu trả lời của @ sri .

Bình luận cho bài viết:

Cuộc tấn công mà Rizzo và Duong đã thực hiện đối với các ứng dụng ASP.NET yêu cầu việc triển khai tiền điện tử trên trang web có một lời tiên tri rằng, khi gửi bản mã, sẽ không chỉ giải mã văn bản mà còn gửi cho người gửi thông báo về việc liệu phần đệm trong bản mã là hợp lệ .

Nếu phần đệm không hợp lệ, thông báo lỗi mà người gửi nhận được sẽ cung cấp cho anh ta một số thông tin về cách thức hoạt động của quá trình giải mã.

Để cuộc tấn công hoạt động như sau phải đúng:

• Ứng dụng của bạn phải đưa ra thông báo lỗi về phần đệm không hợp lệ.
• Ai đó phải can thiệp vào cookie được mã hóa hoặc viewstate của bạn

Vì vậy, nếu bạn trả lại các thông báo lỗi có thể đọc được của con người trong ứng dụng của bạn như "Đã xảy ra lỗi, vui lòng thử lại" thì bạn sẽ khá an toàn. Đọc một chút về các ý kiến ​​về bài viết cũng cung cấp thông tin có giá trị.

• Lưu trữ id phiên trong cookie được mã hóa
• Lưu trữ dữ liệu thực ở trạng thái phiên (vẫn tồn tại trong db)
• Thêm một sự chờ đợi ngẫu nhiên khi thông tin người dùng bị sai trước khi trả lại lỗi, vì vậy bạn không thể đặt thời gian cho nó

Bằng cách đó, cookie bị tấn công chỉ có thể được sử dụng để truy xuất phiên mà rất có thể không còn tồn tại hoặc bị vô hiệu.

Sẽ rất thú vị khi xem những gì thực sự được trình bày tại hội nghị Ekoparty, nhưng ngay bây giờ tôi không quá lo lắng về lỗ hổng này.

Hiểu về tấn công đệm của Oracle

Giả sử ứng dụng của bạn chấp nhận một chuỗi được mã hóa dưới dạng tham số - cho dù tham số đó là cookie, tham số url hay thứ gì khác là không quan trọng. Khi ứng dụng cố gắng giải mã nó, có 3 kết quả có thể xảy ra -

1. Kết quả 1 : Chuỗi được mã hóa được giải mã đúng cách và ứng dụng có thể hiểu ý nghĩa của nó. Có nghĩa là, nếu chuỗi được mã hóa là số tài khoản gồm 10 chữ số, sau khi giải mã, ứng dụng đã tìm thấy một cái gì đó như "1234567890" chứ không phải "abcd1213ef"

2. Kết quả 2 : Phần đệm là chính xác, nhưng sau khi giải mã, chuỗi thu được là vô nghĩa mà ứng dụng không thể hiểu được. Ví dụ: chuỗi được giải mã thành "abcd1213ef", nhưng ứng dụng chỉ mong đợi các số. Hầu hết các ứng dụng sẽ hiển thị một thông báo như "Số tài khoản không hợp lệ".

3. Kết quả 3 : Phần đệm không chính xác và ứng dụng đã ném một số loại thông báo lỗi. Hầu hết các ứng dụng sẽ hiển thị một thông báo chung chung như "Một số lỗi xảy ra".

Để cuộc tấn công Padding Oracle thành công, kẻ tấn công phải có thể thực hiện hàng ngàn yêu cầu, và phải có thể phân loại phản hồi thành một trong 3 nhóm trên mà không gặp lỗi.

Nếu hai điều kiện này được đáp ứng, kẻ tấn công cuối cùng có thể giải mã tin nhắn, và sau đó mã hóa lại nó với bất cứ điều gì anh ta muốn. Nó chỉ là một câu hỏi về thời gian.

Có thể làm gì để ngăn chặn nó?

1. Điều đơn giản nhất - mọi thứ nhạy cảm không bao giờ được gửi đến máy khách, được mã hóa hoặc không được mã hóa. Giữ nó trên máy chủ.

2. Đảm bảo rằng kết quả 2 và kết quả 3 trong danh sách trên xuất hiện giống hệt với kẻ tấn công. Không nên có cách nào để tìm ra cái này từ cái kia. Tuy nhiên, đây không phải là điều dễ dàng - kẻ tấn công có thể phân biệt đối xử bằng cách sử dụng một số loại tấn công thời gian.

3. Là một tuyến phòng thủ cuối cùng, có Tường lửa ứng dụng Web. Cuộc tấn công sấm sét cần phải thực hiện một số yêu cầu trông gần giống nhau (thay đổi từng bit một), do đó, WAF có thể bắt và chặn các yêu cầu đó.

PS Một lời giải thích tốt về Padding Oracle Attacks có thể được tìm thấy trong bài đăng trên blog này . Tuyên bố từ chối trách nhiệm: KHÔNG phải blog của tôi.

Từ những gì tôi đọc cho đến bây giờ ...

Cuộc tấn công cho phép ai đó giải mã các cookie đánh hơi, có thể chứa dữ liệu có giá trị như số dư ngân hàng

Họ cần cookie được mã hóa của người dùng đã đăng nhập, trên bất kỳ tài khoản nào. Họ cũng cần tìm dữ liệu trong cookie - Tôi hy vọng rằng các nhà phát triển không lưu trữ dữ liệu quan trọng trong cookie :). Và có một cách mà tôi có dưới đây là không để asp.net lưu trữ dữ liệu trong cookie đăng nhập.

Làm thế nào một người nào đó có thể lấy cookie của người dùng đang trực tuyến nếu anh ta không nhúng tay vào dữ liệu trình duyệt? Hoặc đánh hơi gói IP?

Một cách để ngăn chặn điều đó là không cho phép cookie vận chuyển mà không mã hóa ssl.

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

Ngoài ra, một biện pháp nữa là ngăn chặn lưu trữ Vai trò trong cookie.

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

Bây giờ về các cookie không an toàn cho các trang thông thường, điều này cần suy nghĩ thêm về những gì bạn đã để người dùng của bạn làm gì và không, bạn tin tưởng anh ta như thế nào, bạn có thể kiểm tra thêm gì (ví dụ: nếu bạn thấy thay đổi trên ip , có thể ngừng tin tưởng anh ta cho đến khi đăng lại từ trang bảo mật).

Tham khảo:
Một số hacker có thể đánh cắp cookie từ người dùng và đăng nhập bằng tên đó trên một trang web không?

Làm thế nào để kiểm tra từ nơi các cuộc tấn công đến và không cung cấp thông tin trở lại. Tôi đã viết ở đây một cách đơn giản để ngăn chặn phần đệm không hợp lệ và đăng nhập cùng lúc để theo dõi những kẻ tấn công: CryptographicException: Padding không hợp lệ và không thể xóa và Xác thực MAC của viewstate không thành công

Cách để theo dõi kẻ tấn công là kiểm tra phần đệm không hợp lệ. Với một thủ tục đơn giản, bạn có thể theo dõi chúng và chặn chúng - chúng cần hàng ngàn cuộc gọi trên trang của bạn để tìm khóa!

Cập nhật 1.

Tôi đã tải xuống công cụ giả sử rằng nó tìm thấy KEY và giải mã dữ liệu, và như tôi nói cái bẫy của nó trên đoạn mã trên đó là kiểm tra viewstate . Từ các thử nghiệm của tôi, công cụ này có nhiều cách khắc phục hơn, ví dụ không thể quét trạng thái xem nén như hiện tại và sự cố của nó đối với các thử nghiệm của tôi.

Nếu ai đó cố gắng sử dụng công cụ này hoặc phương pháp này, đoạn mã trên có thể theo dõi chúng và bạn có thể chặn chúng ra khỏi trang của mình bằng mã đơn giản như "Ngăn chặn từ chối dịch vụ (DOS)" hoặc thích mã này để ngăn chặn từ chối của dịch vụ .

Cập nhật 2

Dường như từ những gì tôi đọc cho đến bây giờ chỉ nghĩ rằng thực sự cần nó để không cung cấp thông tin về lỗi và chỉ cần đặt một trang lỗi tùy chỉnh và nếu bạn thích bạn chỉ có thể tạo và trì hoãn ngẫu nhiên cho trang này.

một video rất thú vị về vấn đề này.

Vì vậy, tất cả các biện pháp trên của nó để bảo vệ nhiều hơn nhưng không cần thiết 100% cho vấn đề cụ thể này. Ví dụ, để sử dụng cookie ssl là giải quyết vấn đề snif, không lưu trữ các Vai trò trong cookie, không nên gửi và lấy lại các cookie lớn và để tránh một số lỗi đã sẵn sàng bẻ khóa mã, chỉ cần đặt vai trò quản trị viên cái bánh quy của anh.

Khung nhìn theo dõi chỉ là một biện pháp nữa để tìm ra cuộc tấn công.

Đây là phản hồi của MS. Tất cả tập trung vào "sử dụng một trang lỗi tùy chỉnh" và bạn sẽ không đưa ra bất kỳ manh mối nào.

EDIT
Đây là một số thông tin chi tiết hơn từ scottgu.

Thêm phản hồi của ScottGu được lấy từ cuộc thảo luận tại http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

IHttpModule tùy chỉnh thay vì customErrors có bị ảnh hưởng không?

H: Tôi không có phần tử được khai báo trong web.config, thay vào đó tôi có một phần tử IHttpModule bên trong phần. Mô-đun này ghi lại lỗi và chuyển hướng đến một trang tìm kiếm (cho 404) hoặc đến một trang lỗi (cho 500 giây). Tôi có dễ bị tổn thương không?

Trả lời: Tôi khuyên bạn nên cập nhật tạm thời mô-đun để luôn chuyển hướng đến trang tìm kiếm. Một trong những cách mà cuộc tấn công này hoạt động là tìm kiếm sự khác biệt giữa 404 và 500 lỗi. Luôn trả lại cùng một mã HTTP và gửi chúng đến cùng một vị trí là một cách để giúp chặn mã đó.

Lưu ý rằng khi bản vá xuất hiện để sửa lỗi này, bạn sẽ không cần phải làm điều này (và có thể quay lại hành vi cũ). Nhưng hiện tại tôi khuyên bạn không nên phân biệt giữa 404 và 500 cho khách hàng.

Tôi có thể tiếp tục sử dụng các lỗi khác nhau cho lỗi 404 và 500 không?

H: Tôi cho rằng chúng ta vẫn có thể có một trang 404 tùy chỉnh được xác định ngoài lỗi chuyển hướng mặc định do lỗi, mà không vi phạm các nguyên tắc được mô tả ở trên?

Trả lời: Không - cho đến khi chúng tôi phát hành một bản vá cho bản sửa lỗi thực sự, chúng tôi khuyên bạn nên giải quyết vấn đề trên đồng nhất hóa tất cả các lỗi. Một trong những cách mà cuộc tấn công này hoạt động là tìm kiếm sự khác biệt giữa 404 và 500 lỗi. Luôn trả lại cùng một mã HTTP và gửi chúng đến cùng một vị trí là một cách để giúp chặn mã đó.

Lưu ý rằng khi bản vá xuất hiện để sửa lỗi này, bạn sẽ không cần phải làm điều này (và có thể quay lại hành vi cũ). Nhưng hiện tại bạn không nên phân biệt giữa 404 và 500 cho khách hàng.

Làm thế nào điều này cho phép tiếp xúc với web.config?

Q: Làm thế nào điều này cho phép tiếp xúc với web.config? Điều này dường như chỉ cho phép giải mã ViewState, có lỗ hổng liên quan nào khác cũng cho phép tiết lộ thông tin không? Có một whitepaper chi tiết cuộc tấn công để giải thích rõ hơn về những gì đang xảy ra?

Trả lời: Cuộc tấn công được hiển thị trong cộng đồng phụ thuộc vào một tính năng trong ASP.NET cho phép các tệp (thường là javascript và css) được tải xuống và được bảo mật bằng một khóa được gửi như một phần của yêu cầu. Thật không may nếu bạn có thể giả mạo một khóa, bạn có thể sử dụng tính năng này để tải xuống tệp web.config của một ứng dụng (nhưng không phải các tệp bên ngoài ứng dụng). Chúng tôi rõ ràng sẽ phát hành một bản vá cho điều này - cho đến khi đó cách giải quyết trên đóng lại vectơ tấn công.

EDIT: Câu hỏi thường gặp bổ sung có sẵn trong blogpost thứ hai tại http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

IMO, không có biện pháp phòng ngừa nào cho vấn đề này, nó cần được xử lý theo từng trường hợp cụ thể:

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

Một vài liên kết quan trọng:

• Tư vấn bảo mật của MS '2416728 (đây là thông tin chính thức)
• Thông tin bổ sung từ nhóm Bảo vệ & Nghiên cứu Bảo mật của MS
  • "Hiểu lỗ hổng ASP.NET" (2010-09-17)
  • "Thông tin bổ sung về lỗ hổng ASP.NET" (2010-09-20)
• Scott Gu: "Quan trọng: Lỗ hổng bảo mật ASP.NET" (2010-09-18)

[Để trả lời khía cạnh nghiêm trọng của điều này (những gì đã được công bố và cách giải quyết được bao phủ bởi các câu trả lời khác).]

Khóa bị tấn công được sử dụng để bảo vệ cả cookie trạng thái và phiên. Thông thường khóa này được tạo ra bởi ASP.NET với mỗi phiên bản mới của ứng dụng web. Điều này sẽ giới hạn phạm vi thiệt hại trong suốt vòng đời của quy trình công nhân, tất nhiên đối với một ứng dụng bận rộn thì đây có thể là ngày (tức là không có nhiều giới hạn). Trong thời gian này, kẻ tấn công có thể thay đổi (hoặc tiêm) các giá trị vào ViewState và thay đổi phiên của chúng.

Thậm chí nghiêm trọng hơn nếu bạn muốn các phiên có thể kéo dài thời gian xử lý của công nhân hoặc cho phép các trang trại web (tức là tất cả các phiên bản trong trang trại có thể xử lý bất kỳ phiên người dùng nào), khóa cần được mã hóa cứng, điều này được thực hiện trong web.config:

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

Tất nhiên, đó là các khóa mới được tạo, tôi sử dụng PowerShell sau để truy cập trình tạo số ngẫu nhiên mã hóa của 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}

(Sử dụng độ dài mảng 20 cho xác thực và 16 cho các khóa giải mã.)

Cũng như sửa đổi các trang lỗi công khai để không rò rỉ lỗi cụ thể, có vẻ là thời điểm tốt để thay đổi các khóa trên (hoặc xử lý công nhân chu trình nếu chúng đã chạy được một lúc).

[Chỉnh sửa 2010-09-21: Đã thêm liên kết lên đầu]

Tôi vừa đăng đầy đủ của tôi về điều này trong blog của tôi , sau khi nghiên cứu thêm về vấn đề này. Tôi nghĩ rằng điều quan trọng của nó là làm rõ lý do tại sao họ đang tiến xa đến mức giả mạo một cookie xác thực.

Chỉ muốn nhận được một số sự thật thẳng:

1. Tấn công không cho phép bạn lấy chìa khóa máy trực tiếp. Điều đó nói rằng, nó khá giống như nó đã có, vì nó cho phép giải mã các tin nhắn và sửa đổi lại / mã hóa lại những tin nhắn mới.
2. cách lấy các khóa thực tế bằng cách sử dụng khả năng của họ để sửa đổi lại / mã hóa như trong 1 và lấy web.config. Thật không may, có một số lý do tại sao một số đặt các khóa này trong web.config ở cấp trang web (thảo luận khác nhau) và trong video mẫu mà chúng được hưởng lợi từ đó là mặc định của DotnetNuke.
3. để có được web.config, tất cả đều chỉ ra rằng họ đang sử dụng webresource.axd và / hoặc scriptresource.axd. Tôi nghĩ rằng chúng chỉ hoạt động với các tài nguyên nhúng, nhưng có vẻ như đó không phải là trường hợp.
4. nếu ứng dụng là asp.net MVC, chúng tôi không thực sự cần webresource.axd và / hoặc scriptresource.axd, vì vậy những ứng dụng này có thể bị tắt. Chúng tôi cũng không sử dụng viewstate. Điều đó nói rằng, tôi không rõ nếu có bất kỳ tính năng nào khác của asp.net cung cấp thông tin khác với cách khắc phục, tức là tôi không biết liệu đệm có cho kết quả không hợp lệ trong khi đệm kết quả hợp lệ trong vé xác thực bị bỏ qua (không biết nếu đúng hay không) ... phân tích tương tự sẽ được áp dụng cho cookie phiên.
5. Vai trò của nhà cung cấp thành viên asp.net 'lưu trữ' trong cookie, tắt nó đi.

Khoảng 1, vì các tin nhắn được mã hóa không thể tùy ý 100% để dung nạp một mẩu rác nhỏ ở đâu đó trong tin nhắn, vì có 1 khối trong tin nhắn giải mã giá trị không thể kiểm soát được.

Cuối cùng tôi muốn nói rằng vấn đề này là kết quả của việc ms không tuân theo hướng dẫn riêng của mình trong trường hợp này: một tính năng dựa trên một cái gì đó được gửi cho khách hàng là bằng chứng giả mạo.

Thêm về:

Tôi không biết liệu phần đệm có cho kết quả không hợp lệ do lỗi trong khi phần đệm có kết quả hợp lệ trong vé xác thực bị bỏ qua (không biết có phải hay không) ... phân tích tương tự sẽ được áp dụng cho cookie phiên.

Cookie auth đã được ký và từ thông tin trong bài báo, họ không thể tạo cookie đã ký nếu họ không nhận được các khóa thực tế (như họ đã làm trong video trước khi giả mạo cookie auth).

Như Aristos đã đề cập, đối với id phiên trong cookie, đó là ngẫu nhiên cho phiên người dùng, do đó, nó phải được đánh hơi từ người dùng có mức bảo mật mục tiêu và bị bẻ khóa trong khi phiên đó đang hoạt động. Ngay cả sau đó nếu bạn đang dựa vào xác thực để gán / ủy quyền cho các hoạt động của người dùng, thì tác động sẽ rất nhỏ / nó phụ thuộc rất nhiều vào Phiên nào được sử dụng cho ứng dụng đó.

Một bản vá cho lỗi này đã được phát hành trên Windows Update: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Asp.Net MVC cũng bị ảnh hưởng bởi vấn đề này (cũng như Sharepoint, ...)

Tôi đã trình bày bản sửa lỗi cho MVC ở đây: ASP.NET MVC có dễ bị tấn công bởi phần đệm không?