CC BY
75УДК 004.056
Информационные технологии
Нелюбов Ростислав Павлович, студент магистратуры 2 курс, МИРЭА-Российский технологический университет (РТУ МИРЭА), Россия, г. Москва, Институт комплексной безопасности и специального приборостроения
Россия, г. Москва
БЕЗОПАСНОСТЬ В ВЕБ-ПРИЛОЖЕНИЯХ ASP.NET CORE
Аннотация: В данной статье рассматривается вопрос безопасности в веб-приложениях ASP.NET Core. В ходе исследования произведено сравнение различных инструментов обеспечения безопасности, сделаны выводы об их эффективности. Также был произведен анализ наиболее существенных уязвимостей веб-приложений и даны рекомендации по их устранению.
Ключевые слова: ASP.NET Core, безопасность, веб-приложение.
Abstract: This article discusses the issue of security in web applications of ASP.NET Core. In the course of the study was made a comparison of various security tools, were drawn conclusions about their effectiveness. The analysis of the most significant vulnerabilities of web applications was also carried out and recommendations for their elimination were given.
Keywords: ASP.NET Core, security, web-application.
Введение
С каждым днем количество веб-приложений увеличивается. С развитием сервисов, всё больше встает вопрос об обеспечении безопасности. В зависимости от используемой технологии будет меняться характер уязвимостей и способы борьбы с ними. Согласно статистике [1], чуть менее трети всех веб-приложений используют в качестве основы фреймворк ASP.NET.
Во многих случаях безопасность веб-приложений становится критически
важной. От того, насколько тщательно проработана система безопасности зависит сохранности данных клиентов. Поэтому данному вопросу следует уделять особое внимание.
Целью данного исследования является повышение безопасности веб-приложений, и разработка комплекса мер для борьбы с наиболее частыми и критичными угрозами.
Статистика по уязвимостям в веб-приложениях
Для построения безопасного веб-приложения, сначала необходимо изучить, какие угрозы наиболее распространены.
Изучив современные исследования [2], посвященные защищенности веб-приложений, можно сделать неутешительные выводы:
- в 9 из 10 веб-приложений преступники могут проводить атаки на пользователей. В том числе - перенаправлять клиентов на подконтрольный им ресурс, похищать учетные данные с помощью фишинговых атак, заражать компьютер вредоносным ПО;
- несанкционированный доступ к приложению возможен на 39% сайтов. Кроме того, в 2019 году полный контроль над системой был получен в 16% веб-приложений, а в 8% систем полный контроль над сервером веб-приложения позволял проводить атаки на локальную сеть организации;
- угроза утечки важных данных присутствует в 68% веб-приложений. Среди «утекших» данных на первом месте персональные (47% утечек), а на втором - учетные (31%).
По самим уязвимостям можно выделить следующее:
- 82% уязвимостей содержатся в коде приложения;
- каждая пятая уязвимость — высокого уровня риска;
- только 17% уязвимостей могут устраняться одними лишь изменениями в конфигурации, причем большинство из этих уязвимостей имеют низкий уровень риска.
Также имеется возможность выделить основные тенденции. В 2019 году значительно снизилось количество веб-приложений, которые содержат
уязвимости высокого уровня риска. Также по отношению с 2018 годом снизилось среднее число критически опасных уязвимостей на одно приложение - почти в полтора раза.
Наиболее распространенные угрозы
Самой распространенной уязвимостью является некорректная настройка параметров безопасности. На втором месте по распространенности находится межсайтовое выполнение сценариев (XSS), затем идут проблемы, связанные с недостатком аутентификации. Также имеют место проблемы, связанные с недостатком контроля доступа, SQL-инъекции, межсайтовые подделки запроса (CSRF-атаки).
Отдельно стоит упомянуть проблему нарушения аутентификации, а также угрозы, связанные с использованием внешних объектов XML.
Устранение угроз и рекомендации для обеспечения безопасности
Первое, о чем необходимо задуматься при разработке веб-приложения -это процесс аутентификации. Аутентификация это одна из важнейших частей веб-приложения. Среди множества способов реализации аутентификации одним из самых безопасных и популярных является JWT (JSON Web Token) [3].
Алгоритм аутентификации основанный на JWT заключается в следующем:
1. Пользователь совершает отправку к серверу с данными для аутентификации.
2. Сервер проводит проверку данных и возвращает токен (условный пропуск для получения доступа к данным), который чаще всего содержит данные о дате создания токена, идентификационном номере пользователя, и т. д.
3. Токен хранится в браузере пользователя, то есть на клиентской стороне. Иногда для хранения используют в локальное хранилище, то есть обычную папку на жёстком диске, но чаще токен лежит и в хранилище сессий или куки (cookie).
4. Все последующие запросы к серверу, для которых необходимо
произвести аутентификацию должны содержать этот токен. Он указывается в виде дополнительного заголовка авторизации «Authorization: Bearer [код токена]». Также токен может пересылаться другими способами, например, в теле запроса, либо как параметр запроса.
5. Сервер производит расшифровку JWT, если токен валидный, сервер начинает обработку запроса.
6. В момент выхода пользователя из системы, токен удаляется на клиентской стороне. Это не требует взаимодействия с сервером.
Конечно, корректно разработанный механизм авторизации - это только начало построения защиты веб-приложения. Для правильной работы механизма обязательным является настройка политики использования cookie. Cookie - это фрагмент данных, который хранится в браузере пользователя. В каждом запросе полю «MmimumSameSitePoHcy» должно быть присвоено значение «SameSiteMode.Strict», а также должно быть запрещено изменение куков в браузере. Делается это с помощью заголовка «HttpOnly».
Следующим этапом защиты является устранение уязвимости XSS. Эта уязвимость позволяет злоумышленнику размещать сценарии на веб-страницах, как правило в JavaScript коде. Когда пользователь заходит на вредоносный сайт, от его имени запускаются вредоносные сценарии, позволяющие украсть токены и файлы куки, либо перенаправить пользователя на другую страницу. Эта атака обычно предотвращается на стороне клиента.
В таких фреймворках для написания клиентской части приложения как React защита от XSS работает по умолчанию. Это происходит из-за того, что React использует специальное расширение JavaScript - JSX. Особенность заключается в том, что после завершения компиляции любое JSX-выражение преобразуется в вызов JavaScript-функции, результат работы которой - объект JavaScript.
Полезной особенностью React является то, что он по умолчанию экранирует все значения, которые были включены в JSX, перед тем как отрисовать их на странице браузера. Это даёт гарантию, что разработчик
никогда не сможет внедрить что-то, что не было написано непосредственно в его приложении. Всё преобразуется в строки кода, перед тем как быть отрисованным.
Ещё одной распространенной атакой на веб-приложения является SQL-инъекция [4]. Это атака, во время которой происходит вставка вредоносного кода в строки, которые позже будут переданы на экземпляр базы данных для выполнения. Основной способ использования атаки SQL Injection заключается во вставке кода напрямую в входные переменные, задаваемые пользователем, который, после объединения с другими SQL командами выполняется базой данных. Более опытный злоумышленник может внедрить небезопасных код в метаданные, либо в строки, которые были предназначены для хранения в таблицах в качестве данных. Такая атака срабатывает при объединении с динамической командой SQL, после чего происходит выполнение нежелательного кода.
Атака проводится посредством присоединения к текстовой строке новой команды и преждевременного завершения этой строки. Чтобы добавление новых команд не нарушило планов злоумышленника, он заканчивает свою строку комментарием «--». Таким образом, всё, что идет после этой метки, не будет учитываться во время выполнения.
Варианты защиты от SQL-инъекций следующие:
- использование параметризированных запросов;
- использование хранимых процедур;
- использование валидации входных данных;
- игнорирование всех пользовательских команд.
Использование ORM помогает автоматизировать защиту от данной уязвимости, так как использует по умолчанию параметризированные запросы и валидацию. ORM - это удобный интерфейс для взаимодействия с БД без использования непосредственно языка SQL. Для работы ORM ей предоставляется сам запрос, и отдельным аргументом список параметров, который подставляется в запрос с предварительными проверками на
безопасность. В некоторых ORM даже не присутствует запроса как такого, а все запросы проводятся через контекст базы данных.
В среде ASP.NET Core можно выделить целый ряд ORM: EF Core, Dapper, Linq2db, NHibernate. Все они обеспечивают достаточную защиту от SQL-инъекций.
Атака типа «clickjackmg» позволяет вредоносному сайту совершить действие на сайте-жертве от имени посетителя. Чтобы устранить эту угрозу, необходимо запретить открытие сайта во фрейме (отдельном HTML-документе внутри другого HTML-документа), разрешить открытие сайта только во фрейме того же домена или внутри конкретно указанного домена. Технически это реализовывается следующим образом. Достаточно добавить заголовки в HTTP запрос:
- «X-FRAME-OPTIONS: DENY» для полного запрета открытия сайта во фрейме;
- «X-FRAME-OPTIONS: SAMEORIGIN» разрешить открытие сайта только во фрейме того же домена
- «X-FRAME-OPTIONS: ALLOW-FROM https://mysite.com» разрешить открытие сайта во фрейме конкретного домена.
Ещё одним важным элементом защиты является обеспечение SSL для веб-приложения. Протокол SSL [5] это стандартный протокол безопасности для установления защищенного соединения между веб-сервером и браузером во время обмена данными. Основное отличие протокола HTTPS от HTTP как раз и заключается в применении SSL в первом протоколе. Использование SSL гарантирует, что вся информация, передающаяся между веб-сервером и браузером, будет зашифрована перед отправкой. Начиная с версии ASP.NET Core 2.1 HTTPS включено по умолчанию. Если используется более ранняя версия фреймворка, то настроить SSL можно в классе «Startup». Это область кода, в которой происходит настройка веб-приложение и подключение служб.
Иногда обычного перенаправления трафика из HTTP в HTTPS недостаточно, поэтому есть необходимость заставить браузер всегда посещать
сайт используя HTTPS. Для того, чтобы весь трафик перенаправлялся в HTTPS нужно добавить в конвейер запросов, через который проходят данные запроса при обработке, компонент «UseHttpsRedirection».
Также полезно настроить HSTS - это механизм безопасности, который помогает противостоять атакам, направленным на понижение защищенности протокола передачи информации и кражи информации из куки. Он позволяет веб-серверу объявить, что браузеры должны посылать к нему запросы только используя защищенное HTTPS соединение и никогда незащищенное HTTP. Настройка HSTS производится в классе «Startup».
Одной из самых распространенных атак на клиента является атака CSRF (межсайтовые подделки запроса). Для устранения уязвимости к этой атаке необходимо внедрить в запрос «Х-CSRF-TOKEN» токен и настроить его валидацию на стороне сервера. На стороне клиента создается токен, как правило, посредством использования фреймворков jQuery или Ajax. В ASP.NET Core настройка происходит в классе «Startup» или для каждого обработчика запросов отдельно.
И завершающим этапом по обеспечению безопасности будет использование технологии CORS[6]. Это W3C стандарт, который позволяет серверу использовать «same-origin» политику. Эта политика содержит определение того, как скрипт или документ, который был загружен из одного произвольного источника, может взаимодействовать с ресурсом из другого источника. Это может помочь для изоляции потенциально вредоносных документов, что снижает количество возможных векторов атак.
CORS работает следующим образом:
1. CORS подразумевает введение новых HTTP заголовков, которые позволяют использовать «cross-origin» запросы, то есть запросы к другим источникам.
2. Если браузер имеет поддержку CORS, он обязан вставлять эти заголовки для «cross-origin» запросов автоматически.
3. «Cross-origin» запросы пересылаются к серверу, с предварительным
добавлением заголовка с информацией о домене.
4. Если не обнаружено ошибок, сервер посылает ответ и добавляет в него «Access-Control-Allow-Origin» заголовок. В том случае, когда значением заголовка является символ «*», это будет означать, что допустимы любые доменные имена для использования. Либо имеется возможность указать вместо этого какое-то конкретное доменное имя.
5. Если при проверке оказывается, что в ответе от сервера нет «Access-Control-Allow-Origin» заголовка, запрос считается неудавшимся.
Можно попробовать дать краткое определение сути технологии. При отправке запроса с использованием стандарта CORS к чужому серверу, браузер обязан добавить в запрос заголовки, содержащие информацию о том, что запрос пришёл с другого домена. На основании заголовков сервер принимает решение, каким образом обрабатывать такой запрос, и в свою очередь добавит особые заголовки в ответ.
Для использования CORS в ASP.NET Core необходимо установить соответствующий пакет библиотек. Затем нужно произвести настройку в классе «Startup».
Заключение
В предоставленной статье был проведен анализ наиболее частых и критичных угроз в веб-приложениях. Результатом данной работы стал комплекс мер по защите веб-приложений, созданных с использованием технологии ASP.NET Core. Следование рекомендациям, приведенным в статье, позволит обеспечить достаточный уровень защиты.
Библиографический список:
1. Framework Usage Distribution on the Entire Internet [Электронный ресурс] - URL: https://trends.builtwith.com/framework/traffic/Entire-Internet. (дата обращения 27.04.2022).
2. Уязвимости и угрозы веб-приложений в 2019 году [Электронный ресурс] - URL: https://www.ptsecurity.com/ru-ru/research/analytics/web-
vulnerabilities-2020/. (дата обращения 28.04.2022).
3. JSON Web Token (JWT) [Электронный ресурс] - URL: https://tools.ietf.org/html/rfc7519 (дата обращения 28.04.2022).
4. SQL Injection [Электронный ресурс] - URL: https://owasp.org/www-community/attacks/SQL_Injection (дата обращения 15.04.2022).
5. Протокол SSL [Электронный ресурс] - URL: https://te-st.ru/2014/12/03/what-is-ssl/ (дата обращения 06.04.2022).
6. CORS [Электронный ресурс] - URL: https://developer.mozilla.org/ru/docs/Web/HTTP/CORS (дата обращения 28.04.2022).
