Все говорят о ASP.NET Padding Oracle уязвимости, выпущенном два года назад на конференции по безопасности. Тем не менее, до сих пор не было достаточно информации о том, как проверить, уязвимо ваше приложение или нет. Если вы не хотите делать это самостоятельно, то к вашим услугам поиск уязвимостей сайта от Defense Laboratory, которая предлагает web-аудит, а также защиту от DDoS атак. Если хотите делать все самостоятельно, то на форумах Duncan Smart с ASP.NET опубликована некоторая очень полезная информация, которая позволяет нам делать это. Приложение уязвимы для атак, если оно по-разному реагирует в следующих трех случаях:
1. Когда получается действительный зашифрованный текст (тот, который правильно заполняется и содержит достоверные данные).
2. Когда получает поврежденный зашифрованный текст (тот, который должным образом не заполняется).
3. Когда действительный зашифрованный текст получается (правильно заполняется), но расшифрованное значение недопустимо для приложений.
Как мы можем применить это к ASP.NET?
Ключом к атаке ASP.NET является файл WebResource.axd. Этот файл используется также в видео, выпущенном Джулиано Риццо. Этот файл может быть использован в качестве Padding Oracle, потому что он реагирует по-разному во всех трех случаях.
Вот три случая.
1. действительный зашифрованный текст
Сделать запрос как http://website.com/application/WebResource.axd?d=jzjghMVYzFihd9Uhe_arpA2
Ответ статуса 200 OK и ответ является контентом веб-ресурса, который вы запрашиваете (код JavaScript в моем случае).
2. недействительный зашифрованный текст
Сделать запрос как http://website.com/application/WebResource.axd?d=acunetix
Ответ статус 500 Internal Server Error и в ответе будет некоторое сообщение об ошибке.
3.valid зашифрованный текст, но неверные данные
Сделать запрос как http://website.com/application/WebResource.axd?d =
Ответ статуса 404 Not Found и в ответе будет некоторое сообщение об ошибке.
Это заполнение Oracle, которое позволяет злоумышленнику использовать эту уязвимость. Если ваше приложение реагирует по-разному в каждом из этих трех случаев, то они уязвимы.
Очень важно: Установка CustomErrors на «On» или «удаленно» (в web.config) не решает эту проблему, потому что заполнение Oracle по-прежнему существует (сообщение об ошибке отображается на ошибку 500 страница не является важной для этой уязвимости). Таким образом, единственным решением является одно из предложенных Гарри Скоттом. Отредактируйте файл web.config, установите набор redirectMode для ResponseRewrite и defaultRedirect на страницу, где вами определена ошибка.
Как только это временное решение применяется, приложение будет возвращать тот же код состояния и ответ во всех трех случаях. Если вы используете NET Framework 3.5 SP1 или 4.0, то это еще лучше.
Если вы используете. NET Framework 3.5 SP1 или 4.0, обходной путь предоставляет собой дополнительную защиту, которая также помогает смягчить урон от потенциальных атак. Решение использует redirectMode="ResponseRewrite" вариант в customErrors функции, и вводит случайные задержки в странице, на которой ошибка. Эти подходы работают вместе, чтобы сделать его более трудным для злоумышленника для установления типа ошибки, которые произошли на сервере.
Кстати, есть уже обновление для Acunetix WVS, которое автоматически проверяет, является ли ваше приложение уязвимым или нет.
