Шутько Н.А.
ТЕОРЕТИЧЕСКИЕ ПОНЯТИЯ ЗАЩИТЫ WEB-ПРИЛОЖЕНИЙ ОТ УЯЗВИМОСТЕЙ *
Аннотация:
в работе рассмотрены базовые фундаментальные основы построения архитектуры веб-приложения. Предоставлены характеристики вероятных угроз, рассчитана статистика использования той или иной методологии
Ключевые слова:
веб-приложения, компьютерные уязвимости, архитектура приложения
УДК 004.056.57
Шутько Н.А.
студент кафедры ERP-систем
Воронежский государственный университет
(г. Воронеж, Россия)
ТЕОРЕТИЧЕСКИЕ ПОНЯТИЯ ЗАЩИТЫ WEB-ПРИЛОЖЕНИЙ ОТ УЯЗВИМОСТЕЙ
Аннотация: в работе рассмотрены базовые фундаментальные основы построения архитектуры веб-приложения. Предоставлены характеристики вероятных угроз, рассчитана статистика использования той или иной методологии.
Ключевые слова: веб-приложения, компьютерные уязвимости, архитектура приложения.
Веб-приложение — комплекс программ, осуществляющих обработку информации в определенной области использования в сфере Веб.
Веб-приложение – это дополнительные программные средства, которые предназначаются для автоматизированного выполнения некоторых манипуляций на Web-серверах. Вместе с тем, они используют как пользовательский интерфейс Web-браузеры. Зачастую Web-приложения формируются в различных вариациях архитектуры клиент-сервер.
Веб-приложение – это приложение, производящееся на сервере, доступ к которому реализуется посредством передачи-получения пакетов через протокол HTTP.
Совокупная архитектура Web-приложения – модель клиент-сервер, где элементы приложения делятся на пользовательские и серверные, объединяются посредством передачи -получения пакетов через протокол HTTP. Как клиент выступает Web-браузер, а как сервер – Web-сервер (рисунок 1).
Рис. 1. Совокупная архитектура Web-приложения
Цели Web-сервера – выполнить определенные функции по обработке информации и предоставить интерфейс (программный или пользовательский) через протокол HTTP для доступа к данным функциям. Серверный элемент Web-приложения принимает запрос от клиента, производит обработку информации, затем создает ответ и/или Web-страницу и пересылает пакет данных пользователю по сети через протокол HTTP. Серверные элементы Web-приложения могут проявляться в качестве клиента прочих служб (сервисов), к примеру, информационной базы либо иного Web-приложения, которое расположено на другом сервере.
Одной из положительных сторон данного подхода считается то, что клиенты не зависимы от определенной пользовательской операционной системы, и Web-приложения, следовательно, являются межплатформенными сервисами.
Динамичные приложения содержат меняющееся значимо-информационное содержание (контент), а постоянное Web-приложение неменяющееся содержание.
Качество создаваемого приложения устанавливается соответствием требованиям, заложенным на этапе проектирования системы. Все условия к приложениям делятся на функционирующие и нефункционирующие. Функциональные условия определяют ту работу системы, которую авторы должны создать, для того, чтобы пользователи могли выполнять задачи в пределах своих бизнес-процессов. Нефункциональные условия к системе задают свойства надежности, скорости работы приложения, безопасности и масштабируемости.
Самым надежным на данный момент является рейтинг топ 10 уязвимостей от проекта OWASP.
OWASP является открытым проектом по обеспечению безопасности приложений. Опубликованный OWASP топ-10 уязвимостей считается перечнем самых критичных рисков безопасности приложений, отображающим текущие проблемы в сфере ИБ.
Одно из ключевых направлений жизнедеятельности A1QA состоит в тестировании безопасности программных продуктов. В данной компании работает центр компетенции по тестированию безопасности и лаборатория, проводящая тесты на проникновение и аудит безопасности ПО. Инженерами компании учитывался обновлённый топ OWASP. В предоставленной работе буду рассмотрены изменения Топ-10 в сравнении с предшествующей версией. Рассмотрим, какие из уязвимостей были добавлены, какие исключены из перечня, о чём свидетельствуют такие изменения
Безусловно, имеется значительно больше уязвимостей приложений, которые способны обеспечить злоумышленникам получение доступа к веб сайту и похищение ценной информации. Впрочем, проверка на уязвимости OWASP Toп-10 считается верным шагом по обеспечению защищённости и безопасности данных.
Рассмотрим подробнее данные уязвимости.
Инъекции. В качестве инъекций подразумевают уязвимости, возникающие вследствие передачи не проверенных данных, которые пользователь ввёл интерпретатору в целях выполнения. Следовательно, каждый из пользователей имеет возможность выполнения в интерпретаторе произвольного кода. Наиболее распространёнными типами инъекций считаются LDAP, XXE, OS и SQL.
Если 3 первые считаются мало известными, то SQL инъекции знакомы многим. С их помощью у злоумышленника появляется возможность доступа к БД; он может прочитать из БД секретные данные либо даже записать собственные значения. Возникают инъекции, когда данные, которые передаются интерпретатору не подвергаются проверке на наличие управляющих последовательностей, а также таких команд, как кавычки в SQL.
Вопросы аутентификации и проверки сессий. Большинство приложений запрашивает идентификацию пользователей, чтобы работать с ними. Зачастую функции проверки достоверности и управления сессиями реализовываются неправильно, что даёт злоумышленникам возможность доступа к учётным пользовательским записям в обход паролей. Также злоумышленники имеют возможность каким-либо способом осуществить перехват ключей либо токенов сеанса, выступающих как идентификаторы пользователей и применять их постоянно или временно.
XSS. Две рассмотренные выше уязвимости представляли гораздо больше опасностей для веб-сайта и его сервера. Уязвимость XSS считается не опасной для сервера, однако представляет опасность для пользователя. Работает она в пользовательском браузере, и поэтому создаёт условия только для кражи пользовательских данных. Cross-Site Scripting или XSS функционирует в JavaScript. Принцип такой же, как и в инъекциях. Злоумышленник осуществляет передачу специальной строке в каком-нибудь поле, строка содержит JS код, дальше браузер считает, что данный код направлен сайтом и реализовывает его, хотя код может быть любым. Чтобы противодействовать подобным атакам требуется экранирование всех специальных символов посредством функции htmlspecialchars либо ее аналогов.
Вопросы контроля доступа. Зачастую в связи с недосмотром администраторов простым пользователям становятся доступными данные, которые обязаны быть закрыты. Данной проблеме могут подвергаться даже самые популярные движки. Примером могут послужить файлы в корне веб-сайта. К примеру, файл wp-config.php с паролями доступа к БД недоступен, так как имеет расширение php. Однако если его редактировать в Vim и сохранить неправильно, то формируется резервная копия с расширением .swp, которую можно уже без препятствий открыть в браузере.
В качестве проблемы контроля доступа также можно подразумевать ошибки в коде пользовательского приложения, которые могут открыть для не авторизованных пользователей доступ к засекреченным данным.
Неправильная конфигурация. Для безупречной безопасности приложение запрашивает безопасную конфигурацию не только спланированной и разработанной на уровне фреймворка и веб-приложения, а и правильно настроенных серверов. Настройки безопасности обязаны разрабатываться, осуществляться и стабильно поддерживаться. По умолчанию конфигурация большинства сервисов считается не безопасной. Помимо этого, ПО должно поддерживаться в актуальном состоянии.
Незащищенные конфиденциальные данные. Большинство веб-приложений, сайтов и API не обеспечивают защиту пользовательских конфиденциальных данных и осуществляют их передачу в открытом виде. Такими данными могут считаться не только ключи, токены и пароли, а и финансовая и медицинская информация. Применяя атаку «Человек посередине» у злоумышленников появляется возможность кражи или даже модифицирования важных данных. Конфиденциальные данные обязаны быть защищены, к примеру, посредством шифрования https либо при помощи других способов.
Недостаточная защита от атак. Большая часть API и приложений не располагают базовыми возможностями по выявлению, предотвращению и реакцией на автоматические и ручные атаки. Защитой от атак считается нечто большее, нежели базовая проверка соответствия пароля и логина. Также она должна содержать в себе выявление, документирование и даже блокировку действий по неверному входу и прочих несанкционированных действий. У разработчиков приложений также должна иметься возможность быстрого развёртывания исправлений, чтобы обеспечить защиту от новых атак.
Уязвимости CSRF. Атака Cross-Site Request Forgery или CSRF предоставляет злоумышленнику возможность вынудить браузер жертвы осуществить отправку в уязвимое приложение определённого HTTP запроса, включая файлы сеанса, куки и различную остальную, в автоматическом режиме включаемую информацию.
Таким способом, у злоумышленника появляется возможность генерации запросов из браузера пострадавшего, которые приложение принимает как правильные и отправленные самим пострадавшим. К примеру, пользователь просто открывает ссылку, а веб-сайт уже осуществляет отправку его друзьям сообщения, содержащего рекламное содержание без его ведома либо удаляет его аккаунт.
Применение элементов с уязвимостями. Такие элементы, как фреймворки, библиотеки и прочие программные модули функционируют с такими же полномочиями, как и приложение. Когда в одном из элементов имеется уязвимость, то вследствие атаки на неё у злоумышленника появляется возможность кражи важных данных или даже получения управления над сервером. API и приложения, применяющие элементы с уязвимостями могут ослабить защиту веб-приложений и сделать потенциальными различные атаки. Могут быть различные типы уязвимостей веб-сайтов, которые могут открывать доступ к всевозможным данным.
Незащищенные API. Большая часть современных приложений зачастую содержат в себе веб-приложения клиентов, а также богатые API интерфейсы, которые доступны из мобильных приложений и через JavaScript в браузере. Они работают по протоколам GWT, RPC, REST/JSON, SOAP/XML и др. Такие API очень часто являются не защищёнными и также содержат большое количество ошибок, приводящих к уязвимостям.
По результатам анализа установлено, что 25% веб-приложений подвергаются 8-ми уязвимостям из перечня OWASP TOP-10. Кроме указанных выше, в число самых распространённых вошли:
Также исследователями обнаружено, что все из изученных веб-приложений имеют как минимум одну уязвимость (на одно веб-приложение приходится в среднем 45 проблем).
Помимо этого, специалистами проведён сравнительный анализ веб-приложений, которые разработаны по технологиям .NET и Java. Оказалось, что Java-приложения в основном могут подвергаться уязвимостям, которые позволят внедрение SQL-кода и CSRF-уязвимостям (соответственно 38% и 69% решений) и в меньшей степени проблемам, которые относятся к небезопасной конфигурации (14%) в сравнении с .NET-приложениями.
Соучредитель и технический директор Contrast Security Джефф Уильямс (Jeff Williams) констатирует, что результаты исследования пробуждают глубокое беспокойство. Абсолютно все выявленные уязвимости находятся в перечне OWASP более десяти лет, однако до сих пор продолжают оставаться серьёзной проблемой. Принимая во внимание возрастающие угрозы и уровень уязвимости, предприятиям необходимо осуществлять контроль безопасности своих приложений, заметил Уильямс.
В данной главе были рассмотрены виды уязвимостей веб-сайта, которые по версии ресурса OWASP, встречаются больше всего. Установлено, что среди таких программных проблем, как СSRF, XSS или SQL инъекции, существуют и проблемы, затрагивающие настройку серверов, которые также часто приводят к проблемам. Зная, какие уязвимости сайтов существуют, можно любой ресурс сделать более безопасным.
В предоставленной работе будут рассматриваться некоторые вопросы, касающиеся анализа средства тестирования уязвимостей веб-приложений в качестве программных продуктов. Современные средства тестирования уязвимостей считаются многофункциональным и весьма сложным продуктом, поэтому их анализ и сравнение с похожими решениями имеет некоторые особенности.
В научной статье «Building a Test Suite for Web Application Scanners» раскрыты общие принципы анализа средств тестирования уязвимостей, на которых будем основываться дальше. Один из таких принципов состоит впроцедуре анализа в целях сравнения работы всевозможных средств тестирования уязвимостей веб-приложений. Немного видоизменённый вариант этой процедуры выглядит таким образом:
Изменения после любой из итераций необходимо вносить в составленную таблицу итогов детектирования объектов. Таблица должна примерно иметь такой вид, как представлено на рисунке.
Разумеется, что отнюдь не все средства тестирования уязвимостей веб-приложений имеют одинаковый набор сканирующих модулей, впрочем, подобную таблицу можно все равно применять, уменьшая рейтинг средства тестирования уязвимостей в случае отсутствия тех либо других модулей, той либо другой функциональности.
Подготовить для анализа приложение с заранее известным количеством уязвимостей конкретного типа невозможно. Вследствие этого, составляя подобную таблицу мы неизбежно столкнемся с проблемами определения числа действительных объектов для поиска. Данная проблема может решаться таким образом.
Рассматривать в качестве одной уязвимости класс эквивалентных уязвимостей, которые могут быть выявлены в анализируемом приложении. К примеру, для SQL-инъекций классом эквивалентных уязвимостей могут считаться все уязвимости, которые найдены для одного и того же самого параметра GET-запроса к веб-приложению.
Осуществить для анализа разработку простейших приложений, реализующих или моделирующих некую уязвимость, однако используют различные фреймворки и разворачивая их на большом количестве вариантов ОС, всевозможных веб-серверах, с применением различных БД, с доступом по разнообразным сетевым протоколам, а также посредством различных цепочек прокси.
На стендах для анализа развернуть большое количество разнообразных CMS, уязвимых приложений (OWASP Site Generator, Gruyere, DVWA и др.) и сканировать их разными средствами тестирования уязвимостей. Общее количество уязвимостей, которые найдены всеми средствами тестирования уязвимостей, принять за эталон и применить в дальнейших анализах.
Конфигурировать приложение для анализа и осуществлять управление им, устанавливая необходимый уровень защиты, возможно, например, посредством инструмента OWASP Site Generator, конфигурация которого может храниться и редактироваться в простом XML-файле. К огорчению, сегодня этот инструмент уже считается устаревшим, поэтому для эмуляции современных уязвимостей рекомендовано создавать веб-приложения собственными силами.
Виды уязвимостей для осуществления в контенте анализа проверки средств тестирования уязвимостей перечислены в классификаторе WASC Threat Classification.
Ожидаемое количество запусков процедуры анализа для всех без исключения потенциальных комбинаций установленных веб-приложений будет чрезвычайно большим. Уменьшить это количество можно при помощи использования техники тестирования pairwise analysis.
По итогам сканирования приобретаем числовые векторы вида как представлено в таблице 1.1.
Потом следует ввести метрику качества сканирования, которая может использоваться, чтобы сравнить показатели и средства тестирования уязвимостей между собой.
В процессе анализа средств тестирования уязвимостей веб-приложений можно опираться ещё на одну статью, которая получила название «Analyzing the Accuracy and Time Costs of Web Application Security Scanners». Данная статья описывает проведение испытаний всевозможных средств тестирования уязвимостей (Acunetix, Hailstorm, Appscan, NTOSpider, WebInspect, Qualys, BurpSuitePro) и для каждого определённого инструмента было предложено провести 4 типа испытаний:
Режим PaS считается запуском сканирования с типовыми параметрами средства тестирования уязвимостей. Реализовывается согласно схеме: «постановка цели — сканирование — получение результата».
Обучение содержит в себя различные конфигурации настроек, связь с поставщиками средств тестирования уязвимостей, изменение скриптов и пр.
Чтобы определить количество времени, затраченное специалистами для получения качественного результата, в работе предлагается использовать простую формулу:
Общее время = Время обучения + #False Positive * 15 мин. + #False Negative * 15 мин.
При каждом испытании необходимо использовать процедуру анализа, которая была описана раньше.
Авторами ещё одной статьи «Top 10: The Web Application Vulnerability Scanners Benchmark» предложен единый поход к сравнению характеристик средств тестирования уязвимостей и набор этих характеристик с примерами. В данной работе предлагается задавать оценку возможностей средств тестирования уязвимостей веб-приложений в виде таблицы, используя такие критерии:
Отдельные из перечисленных выше пунктов входят в обобщённую таблицу детектирования объектов. Помимо этого, можно отметить, что для большей части критериев необходимы экспертные оценки, что затрудняет сравнение средств тестирования уязвимостей и автоматизированный анализ. По причине предлагаемые критерии оценок могут использоваться, например, как разделы для наиболее общего отчета по изучению характеристик средств тестирования уязвимостей, в котором имеются все результаты тестирования и сравнения определённого средства тестирования уязвимостей с конкурентами.
Основываясь на материалах, представленных выше, была разработана классификация типов анализов, которые можно применять в процедуре анализа.
Базовые функциональные (smoke) анализы должны осуществлять проверку работоспособности ключевых низкоуровневых узлов средства тестирования уязвимостей: работу подсистемы конфигурации, транспортной подсистемы, подсистемы логирования и др. В процессе сканирования простейших целей анализа сообщений об ошибках быть не должно: traceback и exceptions в логах, средство тестирования уязвимостей не должно зависать в процессе использования разных транспортов, прокси-серверов, редиректов и пр.
Функциональные (functional) анализы обязаны осуществлять проверку ключевых сценариев, чтобы проверить технические требования. Необходимо выполнять проверку работоспособности каждого из сканирующих модулей последовательно при разных настройках тестового окружения и модуля. Выполняются негативные и позитивные сценарии анализа, разнообразные стресс-анализы с применением больших массивов некорректных и корректных данных, которые оправляются от веб-приложения в ответ средству тестирования уязвимостей.
Анализы на сравнение (compare) функциональности, в процессе которых производится сопоставление качества и средней скорости нахождения объектов избранным модулем средства тестирования уязвимостей с похожими по функционалу модулями в продуктах конкурентов. Для каждого определённого сканирующего модуля обязаны предоставляться определения, что подразумевается в качестве объектов для него и качеством их нахождения.
Анализы на сопоставление показателей оценочных критериев (criteria), в процессе которых выполняется проверка того, что бы качество и скорость нахождения объектов каждым из сканирующих модулей в каждой из новых версий анализируемого средства тестирования уязвимостей не ухудшились в сравнении с предшествующей версией. Определения качества и скорости должны задаваться аналогично анализам на сопоставление функциональности: за исключением, что в этом типе анализов в роли конкурента для анализируемого средства тестирования уязвимостей выступает его предшествующая версия.
Применять описанную в предоставленной работе процедуру анализа можно для интегрированных сре6дств тестирования уязвимостей безопасности веб-приложений, а используя метрику качества сканирования, можно получить инструмент для качественного сопоставления средств тестирования уязвимостей через сравнение их метрик. При развитии данной идеи можно применять нечёткие показатели, метрики и шкалы, чтобы упростить работы по сравнению средств тестирования уязвимостей.
Современный рынок сегодня предоставляет всевозможные решения в сфере статического анализа. Рассмотрим основные технологии тестирования веб-уязвимостей.
Referrer Policy Cont представляет собой технологию для сканирования слабых и уязвимых мест, которые созданы на Java. Технология используется для включения и выключения прокси процессов и автоматизированного сканера. Усовершенствованная версия технологии способствует нахождению и фиксированию XSS (сценариев перекрестного веб-сайта), SQL-инъекций и др. Технологию можно расширить мощным API на языке Javascript.
Fetch считается довольно простой в применении технологией нахождения и тестирования уязвимостей в приложениях. Ее можно использовать в качестве сканера или для прерывания прокси в целях ручного тестирования веб-страницы. Основные особенности: пауки Fuzzer, AJAX, REST базирование API и веб-поддержка сокета.
Wapiti представляет собой технологию, предоставляющую возможность сканирования веб-страниц в функционирующем приложении, выполнения «чёрного ящика» и введения нагрузки на веб-приложение для проверки уязвимости сценария. Wapiti находит уязвимости в процессах, таких как: раскрытие файла и его включение, обнаруживает слабые htaccess конфигурации и XSS сценарии пр. Располагает большой базой данных инъекций (XPath-инъекций и PHP/JSP/ASP SQL-инъекций).
Content Security Policy (CSP) представляет собой платформу аудита атак приложения, которая считается эффективной против большого количества уязвимостей. Данную технологию можно использовать для отправки запроса на HTTP и получения кластерных ответов HTTP. Если сайт считается защищённым, то с помощью технологии можно применять модули аутентификации для их сканирования.
SQLCo является технологией для выявления SQL-инъекции в БД веб-сайта, что может применяться на обширном диапазоне БД, поддерживает шесть видов способов инжекции SQL.
Secure contexts является технологией анализа безопасности сетевого трафика. Данный инструмент выполняет проверку приложения на неверные конфигурации и известные уязвимости TLS/SSL, осуществляет сканирование зашифрованных соединений и проверки SSL/TLS на уязвимость для атак в середине (MiTM).
Cross-Origin Resource Sharing является приложением, способным выявить «прорехи» веб-сайта применяя слабости веб-браузера. В противоположность другим технологиям безопасности Cross-Origin Resource Sharing может отслеживать атаки с клиентской стороны в пределах браузера. Эта технология разработана для функционирования с рядом веб-браузеров, чтобы контролировать изменения на веб-сайте.
Для проверки способности описанных выше технологий анализа исходного кода обнаруживать дефекты безопасности, требуется написать тест, содержащий в себе самые распространённые ошибки программистов. Для этой цели с официального веб-сайта Oracle был взят документ «Secure Coding Guidelines for Java SE», описывающий распространённые ошибки программирования, способные оказать влияние на безопасность программного продукта. Опираясь на этот документ, выполнено написание тестовых классов и проведение анализа (таблица 1.1).
В таблице представлен результат анализа. Из таблицы можно увидеть, что перечисленные выше технологии не смогли показать стопроцентный результат. По этим результатам технологию Cross-Origin Resource Sharing можно считать самой лучшей.
Таблица 1 — Итоги тестирования имеющихся технологий
|
Технология
Критерий |
SQL-инъекция |
Незакрытый ресурс |
Переполнение |
Вызов нативного метода |
Отсутствие обработки исключений |
Результат |
|
Referrer Policy Cont |
1 |
1 |
0 |
0 |
1 |
3/5 |
|
Fetch |
0 |
1 |
1 |
0 |
1 |
3/5 |
|
Wapiti |
0 |
0 |
0 |
1 |
1 |
2/5 |
|
Content Security Policy (CSP) |
0 |
1 |
1 |
0 |
0 |
2/5 |
|
SQLCo |
1 |
0 |
0 |
1 |
0 |
2/5 |
|
Secure contexts |
0 |
1 |
1 |
0 |
1 |
3/5 |
|
Cross-Origin Resource Sharing |
0 |
1 |
1 |
1 |
1 |
4/5 |
Вывод заключается в том, что сегодня имеется большое количество средств и технологий, решающих общие вопросы кодирования. Практически не существует средств, которые непосредственно направлены на безопасности исходного кода, и, по всей вероятности, они не считаются открытыми и имеет большую стоимость, поэтому выполненное тестирование доказывает актуальность разработки.
СПИСОК ЛИТЕРАТУРЫ:
Shutko N.A.
student of the Department of ERP Systems
Voronezh State University
(Voronezh, Russia)
THEORETICAL CONCEPTS OF PROTECTING
WEB APPLICATIONS FROM VULNERABILITIES
Abstract: the paper considers the basic fundamentals of building the architecture of a web application. Characteristics of probable threats are provided, statistics on the use of a particular methodology are calculated.
Keywords: web applications, computer vulnerabilities, application architecture.
Номер журнала Вестник науки №11 (56) том 4
Ссылка для цитирования:
Шутько Н.А. ТЕОРЕТИЧЕСКИЕ ПОНЯТИЯ ЗАЩИТЫ WEB-ПРИЛОЖЕНИЙ ОТ УЯЗВИМОСТЕЙ // Вестник науки №11 (56) том 4. С. 253 - 269. 2022 г. ISSN 2712-8849 // Электронный ресурс: https://www.вестник-науки.рф/article/6563 (дата обращения: 20.04.2024 г.)
Вестник науки СМИ ЭЛ № ФС 77 - 84401 © 2022. 16+