Я только что прочитал в сети о недавно обнаруженной уязвимости безопасности в ASP.NET.Вы можете прочитать подробности здесь.

Проблема заключается в том, что ASP.NET реализует алгоритм шифрования AES для защиты целостности файлов cookie, которые эти приложения генерируют для хранения информации во время пользовательских сессий.

Это немного расплывчато, но здесь есть более пугающая часть:

На первом этапе атаки требуется несколько тысяч запросов, но, как только он добивается успеха, и злоумышленник получает секретные ключи, он полностью скрыт. Требуемые криптографические знания очень просты.

В общем, я недостаточно знаком с предметом безопасности / криптографии, чтобы знать, действительно ли это так серьезно.

Таким образом, все разработчики ASP.NET должны бояться этой техники, котораяможет владеть любым сайтом ASP.NET за считанные секунды или что?

Как эта проблема влияет на среднего разработчика ASP.NET? Влияет ли это на нас вообще? Каковы последствия этой уязвимости в реальной жизни? И, наконец: есть ли обходной путь, который предотвращает эту уязвимость?

Спасибо за ваши ответы!

РЕДАКТИРОВАТЬ: Позвольте мне обобщить ответы, которые я получил

Таким образом, это в основном тип атаки «оракулом отступника».@Sri предоставил отличное объяснение того, что означает этот тип атаки.Вот шокирующее видео о проблеме!

О серьезности этой уязвимости: Да, это действительно серьезно.Это позволяет злоумышленнику узнать машинный ключ приложения. Таким образом, он может сделать некоторыеочень нежелательные вещи

При наличии машинного ключа приложения злоумышленник может расшифровать куки-файлы аутентификации.Даже хуже, он можетгенерировать куки аутентификации с именем любого пользователя. Таким образом, он может появиться как любой на сайте. Приложение не может различить вас или хакера, который сгенерировал cookie для аутентификации с вашим именем для себя.Это также позволяет ему расшифровывать (и также генерировать)сеансовые кукиХотя это не так опасно, как предыдущий.Не так серьезно: он может расшифровать зашифрованный ViewState страниц. (Если вы используете ViewState для хранения конфиденциальных данных, вы не должны этого делать!)Совершенно неожиданно: Со знанием ключа машины, злоумышленникможно скачать любой произвольный файл из вашего веб-приложения, даже те, которые обычно не могут быть загружены! (В том числеWeb.Config, так далее.)

Вот куча хороших практик, которые я получил,не решить проблему, но помочь улучшить общую безопасность веб-приложения.

Вы можете зашифровать конфиденциальные данные с помощью защищенной конфигурацииИспользовать только куки HTTPПредотвратить DoS-атаки

Теперь давайте сосредоточимся на этом вопросе.

Скотт Гатри опубликовал запись об этом в своем блогеСообщение в блоге ScottGu об уязвимостиОбновление ScottGu об уязвимостиУ Microsoft есть совет по безопасности об этомПонимание уязвимостиДополнительная информация об уязвимости

Решение

Включите customErrors и создайте одну страницу ошибок, к которойвсе ошибки перенаправлены. Да,даже 404, (ScottGu сказал, что для этой атаки важно различать 404 и 500.) Кроме того, в вашApplication_Error или жеError.aspx поставить код, который делает случайную задержку. (Создайте случайное число и используйте Thread.Sleep, чтобы спать так долго.) Это сделает невозможным для злоумышленника решить, что именно произошло на вашем сервере.Некоторые люди рекомендовали вернуться к 3DES. Теоретически, если вы не используете AES, вы не столкнетесь со слабостью безопасности в реализации AES. Оказывается, этовообще не рекомендуется.

Некоторые другие мысли

Кажется, чтоне каждый считает, что обходной путь достаточно хорош.

Спасибо всем, кто ответил на мой вопрос. Я многое узнал не только об этой проблеме, но и о веб-безопасности в целом. Я отметил ответ @ Микаэля как принятый, но другие ответы также очень полезны.