Тема: ОБНАРУЖЕНИЕ SQL-ИНЪЕКЦИЙ МЕТОДОМ КЛАСТЕРНОГО АНАЛИЗА
Закажите новую по вашим требованиям
Представленный материал является образцом учебного исследования, примером структуры и содержания учебного исследования по заявленной теме. Размещён исключительно в информационных и ознакомительных целях.
Workspay.ru оказывает информационные услуги по сбору, обработке и структурированию материалов в соответствии с требованиями заказчика.
Размещение материала не означает публикацию произведения впервые и не предполагает передачу исключительных авторских прав третьим лицам.
Материал не предназначен для дословной сдачи в образовательные организации и требует самостоятельной переработки с соблюдением законодательства Российской Федерации об авторском праве и принципов академической добросовестности.
Авторские права на исходные материалы принадлежат их законным правообладателям. В случае возникновения вопросов, связанных с размещённым материалом, просим направить обращение через форму обратной связи.
📋 Содержание
1. SQL- ИНЪЕКЦИИ 5
1.1 Основные понятия 5
1.2 Основные виды инъекций 5
1.2.1 UNION SQL-инъекция 5
1.2.2 Error-Based SQL-инъекция 6
1.2.3 Stacked-Based SQL-инъекция 6
1.2.4 Blind SQL-инъекция 6
1.2.5 Time-based SQL-инъекция 7
1.3 Причины появления SQL-инъекций 8
1.4 Подходы к решению задачи обнаружения SQL-инъекций 10
2. СБОР И ПРЕДВАРИТЕЛЬНАЯ ПОДГОТОВКА
ЭКСПЕРИМЕНТАЛЬНЫХ ДАННЫХ 22
2.1 Сбор данных 22
2.2 Подготовка данных к последующей обработке 26
3. АНАЛИЗ ДАННЫХ И ОБНАРУЖЕНИЕ АТАК 28
3.1 Выбор параметров для кластеризации и обучение системы 28
3.1.1 Параметры из SQL Profiler 28
3.1.2 Параметры, описывающие особенности текста запроса 33
3.2 Тестирование и оценка точности обнаружения SQL - инъекций 42
3.2.1 Принятие решения на основе метрики Евклида 43
3.2.2 Принятие решения на основе нормализованного Евклидова
расстояния 45
3.2.3 Принятие решения на основе СКО 46
3.3 Реализация данной системы на практике 46
ЗАКЛЮЧЕНИЕ 49
СПИСОК ЛИТЕРАТУРЫ: 51
ПРИЛОЖЕНИЕ
📖 Введение
Однако, это в свою очередь привело к усложнению web-приложений в плане структуры, архитектуры и реализации, к тому же в них стала использоваться распределенная архитектура. Такое усложнение выдвинуло новые требования к вопросам безопасности web-приложений. Если меры безопасности будут заложены в приложение на раннем этапе разработки, то это значительно сэкономит время и средства, по сравнению с вариантом, когда безопасность будет добавляться в готовое или практически готовое приложение. Вопросы безопасности и надежности являются актуальными на всех этапах разработки.
Пользовательские и иные данные хранятся на сервере в базах данных (БД). Они работают, используя такой язык программирования, как SQL - Structured Query Language - язык структурированных запросов. Благодаря ему, сайты строят запросы к БД и отправляют их на сервера управления базами данных (СУБД). Сервер исполняет полученный запрос, а результат выполнения возвращает обратно пользователю.
Один из типов атак на БД - это SQL-инъекция. На сегодняшний день она встречается как при эксплуатации СУБД, так и в web-программировании. В случае атаки вместо предполагаемого разработчиком запроса, СУБД выполняет несанкционированные команды, введенные злоумышленником через поля, предоставленные, например, для заполнения пользовательских данных. Используя уязвимость, «хакер» может получить конфиденциальную информацию. SQL-инъекция очень проста в реализации. Этот класс атак в случае динамически формируемых запросов использует дополнительный “зловредный” запрос, введенный злоумышленником. Благодаря её использованию, атакующий может получить конфиденциальную информацию или даже получить контроль над сервером. Обозначенные выше обстоятельства делают необходимыми проверку вводимых пользователем данных, дальнейший анализ запроса и внедрение защиты от атак.
Цель настоящей работы: разработка системы обнаружения и
предотвращения атак, основанных на SQL-инъекциях.
Для достижения поставленной цели необходимо выполнить следующие задачи:
• получить набор экспериментальных данных;
• определить параметры, позволяющие идентифицировать в запросе SQL- инъекцию;
• разработать и реализовать метод обнаружения атак класса SQL- инъекций;
• протестировать обнаружитель и оценить точность распознавания атак.
Работа выполнена с использованием учебной БД под управлением СУБД
Microsoft SQL Server 2014 Express. Для тестирования уязвимостей использован сайт - «жертва», специально развернутый на локальном хосте и написанный на ASPX.net. Для генерации SQL-инъекций использовалась программа SQLmap.
✅ Заключение
2. Были проанализированы особенности основных типов SQL-инъекций и определены параметры запросов для эффективного обнаружения атак:
• относительное количество букв в запросе;
• относительное количество спецсимволов в запросе;
• относительное количество цифр в запросе;
• относительное количество символов без учета пробелов.
Важной особенностью этих параметров является то, что они позволяют обнаружить и предотвратить атаку до выполнения запроса.
3. На основе метода кластеризации k-средних реализована система распознавания атак класса SQL-инъекций. Ошибка распознавания атак на обучающей выборке равна 5%;
4. Разработанная система была протестирована на выборке данных не участвующих в обучении с различными критериями принятия решений. Результат тестирования: вероятность ошибки «ложная тревога» стремится к нулю, вероятность ошибки «пропущенная атака» 6% при использовании метрики Евклида. При использовании нормализованного Евклидова расстояния, вероятность ошибки «пропущенная атака» равна 20%, а ошибки «ложная тревога» 7%. Используя СКО, получена вероятность ошибки «пропущенная атака» 44%, а ошибки «ложная тревога» 92%;
5. Проанализирована зависимость ошибок «ложная тревога» и «пропущенная атака» от порога принятия решений.
Для критерия, основанного на метрике Евклида, вероятность ошибки «пропущенная атака» стремится к нулю, а ошибка «ложная тревога» равна 8%.
Критерий, основанный на нормированной метрике Евклида, показал результат вероятности появления ошибок «пропущенная атака» и «ложная тревога» 7%.
Наихудший результат показал критерий принятия решений на основе СКО. При использовании этого подхода, вероятность появления ошибок стремится к нулю, однако, только 95% вредоносных и 8% нормальных запросов было обработано.



