Создание собственного httphandler в web.config: Могу ли я подвергнуться уязвимости «Padding Oracle»?

Question

Учитывая недавнюю уязвимость ASP.NET, что мне следует искать в моих http-обработчиках, которые могли бы вызвать такую ​​уязвимость Oracle Padding?

По-другому спросили ... что MSFT сделала неправильно и что они сделалиисправить в своих обработчиках?

Answer 1

Было 3 проблемы с WebResource.axd и ScriptResource.axd:

1. Работая как набивочный оракул. Это связано с тем, что эти расшифрованные данные отправляются в строке запроса и ведут себя по-разному, когда дешифрованная строка имеет недопустимые значения по сравнению с допустимым заполнением - потому что она была подделана. Исправление, сделанное Microsoft, включало использование HMAC для предотвращения подделки данных - это проверяется перед любой проверкой заполнения, поэтому оно не предоставляет информацию о заполнении
2. Полагается на обычное шифрование / дешифрование для получения запроса на ресурс / файл. Для этого не нужен механизм защиты от несанкционированного доступа.
3. Предоставление доступа к любым файлам, не только к файлам JavaScript

Итог, не позволяйте больше доступа, чем необходимо, и только если вам действительно нужно шифрование / дешифрование, проверьте его.

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

Answer 2

Я думаю, что проблема в том, что они дают «слишком много» информации об ошибке.

@ Шри здесь очень хорошо ее анализирует
Насколько серьезна эта новая уязвимость безопасности ASP.NET икак я могу обойти это?