СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1.ТЕОРЕТИЧЕСКИЕ ПОНЯТИЯ ЗАЩИТЫ WEB-ПРИЛОЖЕНИЙ ОТ УЯЗВИМОСТЕЙ
1.1. Определение, виды и структура web-приложений
1.2. Понятие и классификация уязвимостей web-приложений
1.3. Методы защиты web-приложения
2. ПРИМЕНЕНИЕ JAVA-ТЕХНОЛОГИИ ДЛЯ ЗАЩИТЫ WEB-ПРИЛОЖЕНИЙ ОТ УЯЗВИМОСТЕЙ НА ПРИМЕРЕ ОРГАНИЗАЦИИ
2.1. Характеристика и направление деятельности организации. Описание аппаратного и программного обеспечения
2.2. Анализ уязвимостей web-приложений на примере организации
2.3.Мероприятия по обеспечению защиты web-приложений с использованием Java-технологий в организации
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
ВВЕДЕНИЕ
В наше время, общество не может обойтись без разнообразных компьютерных систем и их программного обеспечения. Их можно встретить почти во всех сферах жизнедеятельности человека. Они делают жизнь человека гораздо комфортнее. Собственно, программное обеспечения и предоставляет человеку возможность решать огромный диапазон всевозможных задач, начиная с общения в социальных сетях в Глобальной сети, заканчивая проведением банковских операций.
Информационные технологии с каждым днём все больше входят в ответственные сферы жизнедеятельности человека. Люди совершают покупки в Интернет магазинах, свои деньги мы сохраняем в банках в электронном виде, все больше документов заполняется с компьютера, огромное количество личных данных сохраняется на разнообразных веб-ресурсах и в удалённых источниках. Чрезвычайно важным становится вопрос защиты такой информации от вредоносного влияния. Решение данной задачи считается совокупным походом и имеет довольно развитую научно-методическую основу.
В международной практике, вопрос обеспечения информационной безопасности рассматривают на разных уровнях и с разных сторон, начиная с аудита безопасности функционирующей компьютерной системы и заканчивая проверкой надёжности ПО на стадии планирования. По мнению российских и зарубежных учёных многофункциональные характеристики информационно- компьютерной системы, именно, определяются надёжностью и качеством ПО. Чем сложнее считается информационная система, тем более актуальным и критичным становится вопрос обеспечения надёжности безопасности информации. Вследствие этого обеспечение безопасности технологий по созданию ПО информационных систем становится важнейшей задачей, а обеспечение контроля на стадиях разработки ПО становится все более актуальным.
Одно из направлений по обеспечению контроля разработки заключается в анализе исходного кода ПО. В этом направлении выделяют 2 главных подхода к аудиту: динамическое тестирование и статический анализ. Динамические методы используются, когда имеется доступ исключительно к интерфейсу ПО, то есть, это тестирование способом чёрного ящика. Такой подход считается эффективным только при тестировании стабильной работы веб-приложения и корректности данных, но даёт низкий результат при нахождении ошибок, которые связаны с намеренно привнесёнными ошибками во входные данные.
Если к программе имеется абсолютный доступ, а вернее к ее исходному коду, то гораздо лучше использовать способы статического анализа. Эти способы применяют исходные тексты программы и разнообразную добавочную информацию, к примеру, связанную со сферой выполнения. Большим достоинством статического анализа кода считается отсутствие необходимости в прогоне программы при всевозможных условиях работы в стремлении достичь большей автоматизацией проверок. Достичь этого можно анализом конструктивных свойств исходного кода.
Следовательно, острой проблемой считается необходимость введения в разработку ПО процессов, предоставляющих возможность обеспечения надёжности и качества исходного кода в течении жизненного цикла разработки ПО.
Целью данной работы является анализ уязвимостей web-приложений и способы защиты с использованием Java-технологий на примере организации.
Для достижения заданной цели в работе необходимо выполнить ряд задач:
- разработать критерии для сравнения технологий поиска веб-уязвимостей, критерии сравнения обеспечения безопасности интегрированных средств тестирования;
- провести обзор и анализ современных технологий тестирования веб-уязвимостей;
- провести анализ современных веб-уязвимостей и рассмотреть варианты их реализации и способы защиты;
- провести сравнение интегрированных сред тестирования веб-уязвимостей;
- усовершенствовать интегрированное средство тестирования веб-уязвимостей путем разработки нового сценария тестирования.
При написании работы были применены такие методы теоретико-методологической базы, как изучение научной литературы по теме исследования, нормативно-правовой базы, аналитический и сравнительный методы.
Эмпирической базой исследования стало изучение основных принципов изучения методов изучения определения уязвимостей и угроз веб-приложения для защиты информации от несанкционированного доступа.
Основой работы послужили различные источники информации по защите веб-приложений. Это нормативные документы, периодические издания, электронные ресурсы, научная и учебная литература как отечественных, так и иностранных авторов.
1.ТЕОРЕТИЧЕСКИЕ ПОНЯТИЯ ЗАЩИТЫ WEB-ПРИЛОЖЕНИЙ ОТ УЯЗВИМОСТЕЙ
1.1. Определение, виды и структура web-приложений
Веб-приложение — комплекс программ, осуществляющих обработку информации в определенной области использования в сфере Веб.
Веб-приложение – это дополнительные программные средства, которые предназначаются для автоматизированного выполнения некоторых манипуляций на Web-серверах. Вместе с тем, они используют как пользовательский интерфейс Web-браузеры. Зачастую Web-приложения формируются в различных вариациях архитектуры клиент-сервер.
Веб-приложение – это приложение производящееся на сервере, доступ к которому реализуется посредством передачи-получения пакетов через протокол HTTP.
Совокупная архитектура Web-приложения – модель клиент-сервер, где элементы приложения делятся на пользовательские и серверные, объединяются посредством передачи -получения пакетов через протокол HTTP. Как клиент выступает Web-браузер, а как сервер – Web-сервер (рисунок 1.1).
Цели Web-сервера – выполнить определенные функции по обработке информации и предоставить интерфейс (программный или пользовательский) через протокол HTTP для доступа к данным функциям. Серверный элемент Web-приложения принимает запрос от клиента, производит обработку информации, затем создает ответ и/или Web-страницу и пересылает пакет данных пользователю по сети через протокол HTTP. Серверные элементы Web-приложения могут проявляться в качестве клиента прочих служб (сервисов), к примеру, информационной базы либо иного Web-приложения, которое расположено на другом сервере.
Одной из положительных сторон данного подхода считается то, что клиенты не зависимы от определенной пользовательской операционной системы, и Web-приложения, следовательно, являются межплатформенными сервисами.
Динамичные приложения содержат меняющееся значимо-информационное содержание (контент), а постоянное Web-приложение неменяющееся содержание.
Качество создаваемого приложения устанавливается соответствием требованиям, заложенным на этапе проектирования системы. Все условия к приложениям делятся на функционирующие и нефункционирующие. Функциональные условия определяют ту работу системы, которую авторы должны создать, для того, чтобы пользователи могли выполнять задачи в пределах своих бизнес-процессов. Нефункциональные условия к системе задают свойства надежности, скорости работы приложения, безопасности и масштабируемости.
1.2. Понятие и классификация уязвимостей web-приложений
Самым надежным на данный момент является рейтинг топ 10 уязвимостей от проекта OWASP.
OWASP является открытым проектом по обеспечению безопасности приложений. Опубликованный OWASP топ-10 уязвимостей считается перечнем самых критичных рисков безопасности приложений, отображающим текущие проблемы в сфере ИБ.
Одно из ключевых направлений жизнедеятельности A1QA состоит в тестировании безопасности программных продуктов. В данной компании работает центр компетенции по тестированию безопасности и лаборатория, проводящая тесты на проникновение и аудит безопасности ПО. Инженерами компании учитывался обновлённый топ OWASP. В предоставленной работе буду рассмотрены изменения Топ-10 в сравнении с предшествующей версией. Рассмотрим, какие из уязвимостей были добавлены, какие исключены из перечня, о чём свидетельствуют такие изменения – рисунок 1.2.
Рисунок 1.2 – Рейтинг веб-уязвимостей топ 10 от проекта OWASP – сравнение
Безусловно, имеется значительно больше уязвимостей приложений, которые способны обеспечить злоумышленникам получение доступа к веб сайту и похищение ценной информации. Впрочем, проверка на уязвимости 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. Кроме указанных выше, в число самых распространённых вошли:
- отсутствие функций контроля доступа (33%);
- небезопасная конфигурация (37%);
- недочёты системы аутентификации и сохранения сессий (41% веб-приложений).
Также исследователями обнаружено, что все из изученных веб-приложений имеют как минимум одну уязвимость (на одно веб-приложение приходится в среднем 45 проблем).
Помимо этого, специалистами проведён сравнительный анализ веб-приложений, которые разработаны по технологиям .NET и Java. Оказалось, что Java-приложения в основном могут подвергаться уязвимостям, которые позволят внедрение SQL-кода и CSRF-уязвимостям (соответственно 38% и 69% решений) и в меньшей степени проблемам, которые относятся к небезопасной конфигурации (14%) в сравнении с .NET-приложениями.
Соучредитель и технический директор Contrast Security Джефф Уильямс (Jeff Williams) констатирует, что результаты исследования пробуждают глубокое беспокойство. Абсолютно все выявленные уязвимости находятся в перечне OWASP более десяти лет, однако до сих пор продолжают оставаться серьёзной проблемой. Принимая во внимание возрастающие угрозы и уровень уязвимости, предприятиям необходимо осуществлять контроль безопасности своих приложений, заметил Уильямс.
В данной главе были рассмотрены виды уязвимостей веб-сайта, которые по версии ресурса OWASP, встречаются больше всего. Установлено, что среди таких программных проблем, как СSRF, XSS или SQL инъекции, существуют и проблемы, затрагивающие настройку серверов, которые также часто приводят к проблемам. Зная, какие уязвимости сайтов существуют, можно любой ресурс сделать более безопасным.
1.3. Методы защиты web-приложений
В предоставленной работе будут рассматриваться некоторые вопросы, касающиеся анализа средства тестирования уязвимостей веб-приложений в качестве программных продуктов. Современные средства тестирования уязвимостей считаются многофункциональным и весьма сложным продуктом, поэтому их анализ и сравнение с похожими решениями имеет некоторые особенности.
В научной статье «Building a Test Suite for Web Application Scanners» раскрыты общие принципы анализа средств тестирования уязвимостей, на которых будем основываться дальше. Один из таких принципов состоит впроцедуре анализа в целях сравнения работы всевозможных средств тестирования уязвимостей веб-приложений. Немного видоизменённый вариант этой процедуры выглядит таким образом:
- Выполнить подготовку необходимого контента анализа для функциональной проверки абсолютно всех технических требований, а также развернуть стенды для анализа.
- Инициализировать анализ, получить все требуемые настройки для анализа.
- Сконфигурировать анализируемое веб-приложение и избрать для него уровень защиты и тип уязвимости.
- Запустить средство тестирования уязвимостей с подобранными настройками на анализируемом веб-приложении и пройти комплект функциональных анализов.
- Осуществить подсчёт и классификацию найденных средством тестирования уязвимостей веб-объекты (векторы атаки, уязвимости, уникальные ссылки и пр.).
- Шаги 2—5 повторить для каждого уровня защиты и типа уязвимостей.
Изменения после любой из итераций необходимо вносить в составленную таблицу итогов детектирования объектов. Таблица должна примерно иметь такой вид, как представлено на рисунке 1.3.
Рисунок 1.3 – Пример таблицы итогов детектирования объектов
Разумеется, что отнюдь не все средства тестирования уязвимостей веб-приложений имеют одинаковый набор сканирующих модулей, впрочем, подобную таблицу можно все равно применять уменьшая рейтинг средства тестирования уязвимостей с случае отсутствия тех либо других модулей, той либо другой функциональности.
Подготовить для анализа приложение с заранее известным количеством уязвимостей конкретного типа невозможно. Вследствие этого, составляя подобную таблицу мы неизбежно столкнемся с проблемами определения числа действительных объектов для поиска. Данная проблема может решаться таким образом.
Рассматривать в качестве одной уязвимости класс эквивалентных уязвимостей, которые могут быть выявлены в анализируемом приложении. К примеру, для 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 типа испытаний:
- Провести анализ веб-приложения в режиме Point and Shoot (PaS) и установить количество обнаруженных и подтвержденных уязвимостей.
- Провести повторный анализ после предварительного «обучения» и настройки средства тестирования уязвимостей на работу с данным типом веб-приложений, определить количество обнаруженных и подтверждённых уязвимостей в данном случае.
- Дать оценку полноте и точности описания обнаруженных уязвимостей.
- Дать оценку общему времени, которое специалисты потратили на подготовку и выполнение анализа, тестирование и обеспечение качества итогов анализа.
Режим PaS считается запуском сканирования с типовыми параметрами средства тестирования уязвимостей. Реализовывается согласно схеме: «постановка цели — сканирование — получение результата».
Обучение содержит в себя различные конфигурации настроек, связь с поставщиками средств тестирования уязвимостей, изменение скриптов и пр.
Чтобы определить количество времени, затраченное специалистами для получения качественного результата, в работе предлагается использовать простую формулу:
Общее время = Время обучения + #False Positive * 15 мин. + #False Negative * 15 мин.
При каждом испытании необходимо использовать процедуру анализа, которая была описана раньше.
Авторами ещё одной статьи «Top 10: The Web Application Vulnerability Scanners Benchmark» предложен единый поход к сравнению характеристик средств тестирования уязвимостей и набор этих характеристик с примерами. В данной работе предлагается задавать оценку возможностей средств тестирования уязвимостей веб-приложений в виде таблицы, используя такие критерии:
- Сопоставление стоимости продукта относительно оценкам критериев.
- Универсальность использования средств тестирования уязвимостей — это количество поддерживаемых протоколов и векторов доставки — способов доставки данных к серверу. Векторы доставки содержат в себе способы доставки данных к серверу, такие как HTTP-параметры строк запроса, параметры XML, JSON, HTTP-body, двоичные способы для таких определённых технологий, как Java-сериализованные объекты, AMF и WCF.
- Число поддерживаемых векторов атаки: тип и число активных плагинов средства тестирования уязвимостей.
- Точность выявления CSS.
- Точность выявления SQL-инъекций (SQL Injection Detection Accuracy).
- Точность обхода структуры веб-приложения и выявления локальных файлов.
- Удаленное применение файлов, XSS, фишинг посредством RFI.
- WIVET-сравнение: автоматизированный краулинг и получение входных векторов для атаки.
- Адаптивность технологии: число дополнительных возможностей средства тестирования уязвимостей с целью преодолеть защитные барьеры.
- Сопоставление особенностей аутентификации: тип и количество поддерживаемых способов аутентификации и авторизации.
- Число дополнительных возможностей сканирования и интегрированных механизмов.
- Общее представление о работе ключевой функции сканирования.
Отдельные из перечисленных выше пунктов входят в обобщённую таблицу детектирования объектов. Помимо этого, можно отметить, что для большей части критериев необходимы экспертные оценки, что затрудняет сравнение средств тестирования уязвимостей и автоматизированный анализ. По причине предлагаемые критерии оценок могут использоваться, например, как разделы для наиболее общего отчета по изучению характеристик средств тестирования уязвимостей, в котором имеются все результаты тестирования и сравнения определённого средства тестирования уязвимостей с конкурентами.
Основываясь на материалах, представленных выше, была разработана классификация типов анализов, которые можно применять в процедуре анализа.
Базовые функциональные (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.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 |
Вывод заключается в том, что сегодня имеется большое количество средств и технологий, решающих общие вопросы кодирования. Практически не существует средств, которые непосредственно направлены на безопасности исходного кода, и, по всей вероятности, они не считаются открытыми и имеет большую стоимость, поэтому выполненное тестирование доказывает актуальность разработки.