Вот наша статья, опубликованная в Springer, Сингапур, 2021 г., в которой можно указать результаты и технические выводы:
https://link.springer.com/chapter/10.1007/978-981-16-6285-0_24
SQLi — это уязвимость веб-безопасности, которая позволяет злоумышленнику использовать запросы и манипулировать ими с помощью таких входных данных, что база данных предоставляет запрашивающему несанкционированную информацию. Во многих случаях эти запросы могут быть созданы не только для получения ответа из базы данных, но также для удаления или манипулирования базой данных. удалять таблицы, содержащие записи о сотрудниках организации и другую конфиденциальную информацию. Эти изменения сохраняются в содержимом и поведении приложения.
Атака может быть модифицирована с помощью гибридных векторов атаки, чтобы скомпрометировать базовый сервер или другую внутреннюю инфраструктуру для выполнения DDOS.
Существуют различные типы методов внедрения sql. Проблема возникает, когда в пространстве ввода используются специальные символы и строки, где нам обычно необходимо очищать, ограничивать или обрабатывать передачу запросов. Некоторые из распространенных способов проверки включают отправку логических условий, таких как ИЛИ 1=1 и ИЛИ 1=2, и поиск различий в ответах приложения. Синтаксис, специфичный для SQL, для систематических различий в результирующих ответах. Даже одиночный персонаж' и ищет аномалии. Они также включают полезные нагрузки OAST, которые предназначены для запуска инъекций и спецификаций. результат таких заявлений.
Но уязвимости SQL-инъекций в принципе могут возникать в любом месте запроса и в разных типах запросов. Другие наиболее распространенные места, где возникает SQL-инъекция:
- В операторах UPDATE в обновленных значениях или в предложении WHERE.
- В операторах INSERT внутри вставленных значений.
- В операторах SELECT внутри имени таблицы или столбца.
- В операторах SELECT в предложении ORDER BY.
Есть два основных способа, с помощью которых я вижу эти инъекции: когда приложение получает пользовательский ввод из HTTP-запроса и во время обработки запроса оно небезопасным образом структурирует вводимые данные в запрос.
Второй тип — это хранимая инъекция, когда она сохраняется для будущих запросов. Обычно это делается путем помещения входных данных в базу данных, но в этот момент никакой уязвимости не возникает, однако, когда позже HTTP-запрос извлекается небезопасным способом, это сработало.
Распространенный подход заключается в использовании параметризованных запросов, также известных как подготовленные операторы, вместо конкатенации строк внутри запроса.
Машинное обучение для конечной безопасности:
По данным OWASP, атаки с использованием SQL-инъекций являются одной из основных атак, нацеленных на веб-приложения. SQL-инъекция, часто называемая SQLI, представляет собой новый вектор атаки, использующий вредоносный код SQL для несанкционированного доступа к данным. Это может сделать систему уязвимой и привести к серьезной потере данных. В этой исследовательской работе мы рассмотрели различные типы атак с использованием SQL-инъекций и существующие методы обнаружения атак с использованием SQL-инъекций. Мы собрали и подготовили наш собственный набор данных для исследования, включая все основные типы SQL-атак, и проанализировали производительность алгоритмов машинного обучения, таких как наивный Байес, деревья решений, машина опорных векторов и K-ближайший сосед. Мы также проанализировали производительность сверточных нейронных сетей (CNN) в наборе данных, используя такие показатели производительности, как точность, точность, отзыв и площадь кривой ROC. Наши эксперименты показывают, что CNN превосходит другие алгоритмы по точности, точности, полноте и площади кривой ROC.
Методы обнаружения атак SQL-инъекций можно разделить на две части:
Динамический — этот метод известен как динамическое обнаружение, поскольку он использует модели машинного обучения/статистические модели для классификации запросов на вредоносные и безопасные, а также обеспечивает гибкость веб-кода для обнаружения и улучшения профилактика.
Статический — этот тип подхода в основном работает с подходами сопоставления словарных строк, которые используют NLP для разрушения данного запроса и сравнения его с уже существующим словарем и проверки, является ли запрос вредоносным. или нет.
НАБОР ДАННЫХ: Одной из основных задач нашего проекта была подготовка исчерпывающего набора данных, включающего все возможные типы полезных данных и запросов, которые можно использовать для атак с помощью SQL-инъекций. Это сильно поможет во время обучения модели, так что система может быть надежно защищена от всех типов запросов, которые могут использовать даже профессиональные злоумышленники.
Таким образом, путем компиляции полезных данных для каждого типа SQL-инъекций, таких как общие, слепые, основанные на ошибках и объединениях SQL-инъекции, был создан комплексный набор данных, содержащий ряд всех возможных полезных нагрузок для атак с помощью SQL-инъекций. В набор данных также были включены запросы, специфичные для различных баз данных, таких как Oracle, MS-SQL, MySQL и Postgres. Они были взяты из различных библиотек с открытым исходным кодом, таких как Kaggle. Они были добавлены вместе с отредактированными версиями этих операторов, что в конечном итоге помогло создать гибкую систему, которая также обнаруживает вредоносные запросы, определяемые пользователем.
Беспорядочные текстовые документы, содержащие запросы полезной нагрузки, сначала были разбиты на отдельные запросы в зависимости от их типа. Затем они были классифицированы в зависимости от типа внедрения и помечены как 1, если полезная нагрузка является вредоносной, или 0, если она не является вредоносной. Затем все полезные данные были скомпилированы в фрейм данных со столбцами в виде запроса полезных данных, типа внедрения и того, является ли полезная нагрузка вредоносной или нет.
Затем несколько других таких текстовых документов были скомпилированы в фрейм данных. После этого данные были отсортированы, а затем подвергнуты дальнейшей предварительной обработке путем удаления повторяющихся полезных данных, а затем удаления пустых и пустых точек данных из таблицы.
Были обучены различные алгоритмы, приведенные ниже, проверена и выбрана лучшая модель. Результаты можно увидеть здесь: