Необходимо ли вам знать об уязвимостях в .NET? Возможно, вы по-новому взглянете на код, а может, и на свою жизнь. А вдруг вам захочется сменить квалификацию и уйти в research новых видов атак? Кто знает. Но если вы задались вопросом об уязвимости, то вы наверняка интересуетесь тем, как разрабатывать надёжные и защищённые приложения.
Итак, давайте поговорим об уязвимостях, которые находят в .NET Framework.
DoS (Denial of service) – атака на ASP .NET MVC приложение. Эта атака способна серьезно нарушить работу вашего сайта, например, замедлить его, а в отдельных случаях и вовсе его заблокировать.
Как работает
На сервер производятся запросы, которые он не может обработать, в результате чего сервер не успевает обрабатывать запросы обычных посетителей и выглядит для них как неработающий.
Как исправлять
- Упростить регулярное выражение
- Заменить регулярное выражение на custom алгоритм
- Задать timeout для обработки любого регулярного выражения, используя конструктор, или для всех регулярных выражений, используя AppDomain.
Это отличные примитивные меры, когда вам не очень хочется разбираться в том, какие у вас регулярные выражения и насколько они сложные. Тем более, что такие решения вам ничего не стоят, но дают результат.
Атака повышения привилегий (ЕоР) на SQL-сервер. В данном случае это luring атака, которая может скомпрометировать все данные на сервере.
Атака повышения привилегий (ЕоР) в ASP .NET Core 1.0. Эта уязвимость была зафиксирована как ошибка бизнес-логики, но позже выяснилось, что она может привести к раскрытию данных и повышению привилегий пользователя.
Как работает
Атакующий «заманивает» более привилегированный компонент, чтобы что-то сделать от его имени. Самый простой способ осуществить такую атаку – убедить цель запустить код атакующего в более привилегированном контексте безопасности.
Как исправлять
Единого сюжета, как избежать этих уязвимостей, к сожалению, нет. Можно дать лишь общие рекомендации. Например:
- Зарегистрировать request-сервис в контексте синглтона
- Дважды проверять любой код, работающий с security sensitive, c sandboxing и с модификацией данных
- Runtime check – ещё один хороший способ защиты от подобных вещей
- Минимум привилегий везде
Раскрытие информации ХХЕ - это уязвимость к XML-инъекциям, которая приводит к чтению произвольных файлов на атакуемом сервере.
Как работает
Чтобы понять суть ХХЕ, давайте сначала разберёмся с ХМL форматом. ХМL формат может содержать описание своей структуры в теге DOCTYPE. В этом же теге могут содержаться и некоторые Entity. Если говорить по-простому, то это аналог константы, который дальше может использоваться в ХМL коде и, при парсинге этого кода, будет автоматически раскрываться. Уже это обстоятельство может привести к DoS атаке, если вы добавите Entity, которые рекурсивно раскрываются, и не зададите timeout. Парсер начнёт их раскрывать бесконечно долго.
Видео курсы по схожей тематике:
Классическая ХХЕ атака проходит следующим образом. Атакующий отправляет скомпрометированный ХМL файл на сервер, где этот файл парсится, после чего из сервера возвращается ответ. Ответ может быть совершенно любого типа, хотя существует вероятность, что злоумышленник получит именно тот локальный файл, который ему нужен.
Как исправлять
- Запретить использование DTD файлов и External Entity
- Занулить resolver
- Ввести ограничение на размер и установку timeout
Одной из причин появления уязвимостей может быть десериализация бинарных данных. Десериализация данных – это обратный процесс сериализации. То есть если при сериализации мы переводим какую-либо структуру данных в последовательность битов, то при десериализации мы восстанавливаем начальное состояние этой структуры.
Как при этом процессе может возникнуть уязвимость? Допустим, у вас есть класс, реализующий команду, который запускает какой-то конвертор. Вы через конструктор передаете ему параметры этого конвертора и они валидируются в конструкторе. При этом использовать можно не каждый, а только ваш локальный конструктор.
В чём же проблема? А проблема состоит в том, что при десериализации данных конструктор не будет запущен. То есть ваши данные будут десериализованы так, как они есть, включая приватные поля.
Как исправлять
- Использовать кастомный сериализатор
- Использовать минимум привилегий в процессе десериализации
О возможных способах десериализации вы можете узнать больше в статье Джеймса Форшав «Are you my Type? Breaking .NET Trough Serialization».
Вывод
К всеобщему сожалению, сейчас не существует ни одного полностью защищённого веб-приложения. Поэтому проблема уязвимостей остаётся актуальной. Злоумышленники находят всё новые и новые способы взлома серверов и нанесения всяческого вреда компаниям или обычным людям. Следовательно, для гарантии безопасности вашего приложения вам необходимо знать, как устранять уязвимости и препятствовать их появлению.
Бесплатные вебинары по схожей тематике:
Материал подготовлен на основе выступления Михаила Щербакова, Independent Consultant, на конференции по .NET-технологиям DotNext 2016 Moscow.
Статьи по схожей тематике
