ВВЕДЕНИЕ
В современном мире практически ни одно технологическое предприятие
не может эффективно функционировать без использования автоматизированных
информационных систем управления. Использование данных систем значительно
повышает эффективность производственных процессов предприятия, но также
создает характерные для информационных систем риски, связанные с угрозами
безопасности информации. Эксплуатация уязвимостей подобных систем может
привести не только к хищению конфиденциальной информации предприятия, но и
привести к серьезным сбоям производства и физическому повреждению
производственного оборудования.
Большинство аналогичных систем представляют собой интернет-ресурсы,
доступ к которым можно получить с помощью глобальной сети Интернет. В
соответствии с этим одна из наиболее значительных проблем функционирования
таких систем – обеспечение информационной безопасности, основной принцип
которой лежит в исследовании потенциальных угроз, проведении мер по их
устранению и дальнейшем исследовании состояния безопасности системы.
SQL-инъекция-это
атака,
при которой злоумышленником
производится
внедрение вредоносного SQL-кода в строки, передающиеся на сервер системы
управления базой данных (СУБД) для последующего синтаксического анализа и
выполнения Данный способ взлома веб-приложений очень распространен и
занимает лидирующие места в отчетах организаций в сфере информационной
безопасности.
SQLi в отчёте Positive Technologies, международной компании, специализирующаяся на разработке программного обеспечения в oблaсти безопаснoсти,
oпубликoвaла стaтистикy за 2018 год, в кoтoрой SQL-инъекции, рaспoлагаясь на
1-oм мeсте, зaнимают пoрядка 30-ти процентов от oбщего кoличествa aтaк нa
интeрнет-прилoжения
зa
этoт
период. Большинство атак
пришлoсь
на
гoсударственные прeдприятия и финaнсoвые yчреждения. В сooтветствии c этим
можно с пoлной увереннoстью гoворить об aктуальности проблемы защиты
данных от атак с использованием SQL-инъекций.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
4
1 АНАЛИТИЧЕСКАЯ ЧАСТЬ
1.1 Концепция, разбор Sql-инъекции
Атака с использованием SQL-инъекций состоит из вставки или внедрения
SQL-запроса через входные данные от клиента к приложению. Команды SQL
вводятся в поле ввода в плоскости данных, которые влияют на выполнение
предопределенных команд SQL. Успешный exploit SQL-инъекции может
считывать конфиденциальные данные из базы данных, изменять данные базы
данных
(например,
вставлять,
обновлять
или
удалять),
выполнять
административные операции с базой данных, восстанавливать содержимое файла,
присутствующего в системе управления базами данных, и даже в некоторых
случаях выдавать команды операционной системе.
Если веб-приложение или веб-сайт использует базы данных SQL, такие как
Oracle, SQL Server или MySQL, они уязвимы для атаки с использованием SQLинъекций. Хакеры используют атаки с использованием SQL-инъекций для
доступа к конфиденциальной деловой или личной информации (PII), что в
конечном итоге увеличивает уязвимость конфиденциальных данных.
Атаки с использованием SQL-инъекций являются одной из наиболее
распространенных уязвимостей OWASP Top 10 и одной из старейших
уязвимостей приложений. В одном недавнем отчете он указан как третья по
распространенности серьезная уязвимость.
Чтобы выполнить атаку с использованием SQL-инъекций, злоумышленник
должен найти уязвимый ввод в веб-приложении или веб-странице. Когда
приложение или веб-страница содержат уязвимость для внедрения SQL, они
напрямую используют пользовательский ввод в форме SQL-запроса. Хакер может
выполнить специально созданную SQL-команду в качестве вредоносного кибервторжения. Затем, используя вредоносный код, хакер может получить ответ,
который дает четкое представление о структуре базы данных и, таким образом,
доступ ко всей информации в базе данных.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
5
SQL служит способом связи с базой данных. Инструкции SQL используются
для извлечения и обновления данных в базе данных. Злоумышленники
используют вредоносные инструкции SQL в поле ввода, и в ответ база данных
представляет конфиденциальную информацию. Этот эксплойт безопасности
направлен на получение доступа к несанкционированным данным веб-сайта или
приложения. Несколько веб-сайтов и веб-приложений хранят данные в базах
данных SQL. Для любого из этих приложений становится необходимым
выполнить тестирование на уязвимость, чтобы убедиться в отсутствии лазеек для
выполнения SQL-инъекции.
При атаке с использованием SQL-инъекций приложение интерпретирует
данные,
предоставленные
киберпреступником,
как
команду
и
отвечает
конфиденциальными деталями. Внедрение SQL может привести к ряду рисков,
которые могут представлять серьезные угрозы для организации.
Существует три основных класса атак, основанных на внедрении SQL-кода:
классическая SQL инъекция (Classic SQLi) SQL инъекция, основанная на
эксплуатации выводимых СУБД сообщений об ошибках (Error-based SQLi)
Слепая SQL инъекция (Blind SQLi).
Рисунок 1.1 – Типы SQL-инъекций
Error Based инъекция: Злоумышленник отправляет некоторый вредоносный
запрос в базу данных, что приводит к ошибкам. Ошибки должны быть очень
обобщёнными, в противном случае они могут дать полезные подсказки
злоумышленнику. Возможно использование строки комментария для того, чтобы
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
6
база данных игнорировала часть допустимого запроса.
Например: Select * from stores where product_id = blah’ or 1=1—( все, что
будет после этого, будет проигнорировано).
Union Based SQL-инъекция:Использование команды union в SQL-запросе
для выполнения дополнительных запросов; таким образом, изменение / вставка /
удаление или сбрасывание содержимого таблицы. Неправильные запросы:
Создание логически неправильных запросов для просмотра сообщений об
ошибках, чтобы получить больше информации о целевой базе данных.
Например: Select * from stores where id=1’ данный запрос приведет к
синтаксической ошибке и может выявить тип внутренней базы данных.
Blind SQL-инъекция: Это тип SQL-инъекции, при котором
преступник
не
имеет ни малейшего представления о том, уязвимо ли веб-приложение для
инъекционной атаки или нет.
Boolean: результат показывают только правильные запросы, неправильные
запросы
ничего
не
возвращают.
Злоумышленники
должны
попытаться
генерировать логически правильные запросы.
Time Based: в зависимости от некоторых условий, установка временной
задержки. Если это условие выполняется, мы можем наблюдать временную
задержку;
таким
образом,
делая
вывод,
что
вводимые
данные
дали
положительный результат. Это трудоемкий процесс.
1.2 Справочная информация по SQLi
Термин ”SQL-инъекция” восходит к 1998 году, в то время как его первое
публичное использование было в 2000 году . С тех пор SQLIA стала одной из
наиболее распространенных атак, используемых через Интернет . Это происходит,
когда злоумышленник изменяет семантику или синтаксис законного запроса,
вставляя новые ключевые слова или операторы SQL, что приводит к
неожиданным результатам, не предназначенным для веб-приложений. Внедренное
приложение не делает различий между реальными и поддельными запросами и
отображает результат в соответствии с тем, что они получают в запросе, тем
самым выводя ложные или непреднамеренные результаты. Как пример, Эхуд
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
7
Тененбаум был арестован по обвинению в краже 1,5 миллиона долларов из
канадских
и
по
меньшей
мере
10
миллионов
долларов
из
американских банков с помощью SQLi.
Угрозы, создаваемые атакой с использованием SQL-инъекций, могут
выходить за рамки простого использования данных. Злоумышленник также может
повысить привилегии, обойти проверку подлинности, выполнить удаленные
команды для передачи вредоносного программного обеспечения или выполнить
атаку типа "отказ в обслуживании". Прежде чем понять, как работает SQLi, важно
кратко рассказать о том, как работает веб-приложение. Хотя веб-приложения
бывают разных форм и размеры, одна общая черта, которую они имеют,
независимо от языка программирования, на котором они были написаны,
заключается в том, что они управляются базой данных. Веб-приложения,
управляемые базами данных, очень распространены в современном веб-мире. Они
просто похожи на черные ящики, которые принимают HTTP-запросы в качестве
входных данных и создают SQL-запросы в качестве выходных данных, как
показано на рисунке 1.2. Значения параметров из HTTP-запросов используются
для генерации SQL-запросов.
Серверная база данных принимает эти SQL-
запросы и отправляет обратно определенную информацию в веб-приложения в
соответствии с требованиями веб-клиента в front-end.
Рисунок 1.2 – Работа веб-приложений
Поскольку наиболее распространенной уязвимой страницей для атаки SQLинъекций является форма входа в систему, на иллюстрации показан упрощенный
пример, чтобы показать, как в ней происходит SQLi. Можно заметить, что этот
пример символизирует исключительно простой вид SQLi, и он изображён только
в иллюстративных целях. Это обычный запрос для входа пользователя в PHP.
На рисунке 1.3 показан фрагмент уязвимого PHP-кода SQLi, который
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
8
использует
динамически
генерируемый
для
SQL-запрос
аутентификации
пользователя с помощью имени пользователя и пароля, предоставленных
пользователем в форме входа.
Рисунок 1.3 - Уязвимый фрагмент кода
На
рисунке
1.4
показана
форма
входа
в
систему
с
простыми
пользовательскими вводами, где отображается пароль в обычном тексте, а не в
типичном формате ”******”, чтобы сделать пример более понятным. На рисунке
1.5 показана форма входа в систему с вводом данных злоумышленником.
Рисунок 1.4 - Форма входа в систему
Исходя из рисунка 1.4 на основе пользовательских данных, будет
сгенерирован запрос:
SELECT
*
FROM
tbl
users
WHERE
username
=
’david’
AND
password = ’sweden123’.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
9
Рисунок 1.5 - Форма входа в систему с вводом данных злоумышленником
Исходя из рисунка 1.5 на основе вводимых данных злоумышленником, будет
сгенерирован запрос:
SELECT * FROM tbl users WHERE username = ’david’ OR ’1’=’1’- - ’AND password = ’whatever’.
В приведенном выше запросе все, что находится после двойного тире ”- -”,
будет проигнорировано базой данных, поскольку это оператор комментария SQL.
Результат приведенного выше запроса предоставит злоумышленнику доступ
независимо от действительного имени пользователя, поскольку результат
”1=1”всегда верен. Таким образом, злоумышленник может обойти процесс
аутентификации без действительного имени пользователя и пароля. Следует
отметить, что это не единственный способ, которым злоумышленник может
обойти процесс аутентификации.
1.3 Методы защиты от SQLi
Методы защиты от
SQL-инъекций
должны быть способны точно
обнаруживать уязвимости во время разработки или эксплуатации в полевых
условиях. Методы, обеспечивающие более высокую точность и меньшие затраты
на
внедрение,
с
большей
вероятностью
будут
внедрены
организацией
(организациями). Мы создали таксономию для методов защиты от SQL-инъекций,
чтобы помочь понять точность методов и критерии их оценки , включая
дополнительную инфраструктуру для справедливого сравнения.
Различные аспекты нашей таксономии могут быть сгруппированы по двум
более высоким или более низким терминам; метод обнаружения и критерии
оценки. Первый касается аспекта системы, в то время как другой касается аспекта
оценки/представления системы, а не самой системы. Каждая из этих группировок
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
10
более высокого порядка содержит несколько связанных измерений. Метод
обнаружения
состоит
из
семи
измерений:
характер
защиты,
принцип
обнаружения, метод анализа, время обнаружения, местоположение обнаружения,
реакция и реализация. Критерии оценки состоят из трех измерений: точность
(ложноположительный и ложноотрицательный результат), накладные расходы на
производительность
и
дополнительные
инфраструктуры.
Таким
образом,
конкретному методу защиты от SQL-инъекций будет присвоено уникальное
значение в каждом из измерений, и классификация метода в целом будет
описываться этой точкой, определяемой каждым значением для каждого
измерения.
На рисуках 1.6 и 1.7 представлены метод обнаружения и критерии
оценивания соответственно.
Рисунок 1.6 – Методы обнаружения
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
11
Рисунок 1.7 – Критерии оценивания
1.4 Анализ существующих решений на
рынке
Существует огромное множество инструментов обнаружения SQLi,
многие из которых имеют открытый исходный код и доступны на GitHub. В
дополнение к специализированным инструментам обнаружения SQLi существуют
более крупные наборы и проприетарные пакеты, которые включают SQLi как
часть их общих возможностей обнаружения уязвимостей.
1.4.1 Netsparker. Netsparker
Netsparker. Netsparker - это ПО для управления веб-уязвимостями, которое
включает обнаружение Sql в качестве одной из своих многочисленных функций.
Он также фокусируется на масштабируемости, автоматизации и интеграции.
Пакет построен на базе сканера веб-уязвимостей и может быть интегрирован со
сторонними инструментами. Операторам не нужно разбираться в исходном коде.
Компания также предлагает шпаргалку для SQL-инъекций, чтобы помочь в
усилиях по смягчению последствий.
Платформа Netsparker использует технологию проверки на основе
проверки для выявления и подтверждения уязвимостей, указывая на результаты,
которые определенно не являются ложноположительными. В дополнение к SQL-
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
12
инъекции он может выявлять межсайтовые скрипты (XSS) и другие уязвимости в
веб-приложениях, веб-службах и веб-API.
Платформа также имеет инструменты тестирования безопасности и
генератор отчетов и может быть интегрирована в среды DevOps. Он проверяет
веб-серверы, такие как Apache, Nginx и IIS, и поддерживает приложения на основе
AJAX и JavaScript.
1.4.2 SQLMap.
SQLMap - это инструмент автоматического управления Sql и базами данных,
доступный на GitHub. Этот инструмент тестирования на проникновение с открытым
исходным кодом автоматизирует процесс обнаружения и использования недостатков
SQLi или других атак, которые захватывают серверы баз данных.Он включает в себя
механизм
обнаружения;
несколько
способов
проведения
тестирования
на
проникновение; и инструменты для снятия отпечатков пальцев с базы данных,
извлечения данных, доступа к базовым файловым системам и выполнения команд в
операционной системе (ОС) через внеполосные соединения.
1.4.3. jSQL Injection.
jSQL Injection - это инструмент на базе Java, который помогает ИТподразделениям находить информацию о базе данных с удаленных серверов. Это еще
один из многих бесплатных способов работы с Sql с открытым исходным кодом. Он
поддерживает операционные системы Windows, Linux и Mac, а также Java версий 11-17.
Это настолько эффективное средство сдерживания SQLi, что оно включено
во многие другие продукты и дистрибутивы для сканирования уязвимостей и
тестирования на проникновение. Сюда входят Kali Linux, Pentest Box, Parrot
Security OS, Arch Strike и BlackArch Linux.
Он также предлагает автоматическое внедрение 33 ядер баз данных,
включая Access, DB2, Hana, Ingres, MySQL, Oracle, PostgreSQL, SQL Server,
Sybase и Teradata. Он предоставляет пользователю способы решения множества
стратегий и процессов внедрения, а также предлагает песочницы сценариев для
SQL и несанкционированного доступа.
1.4.4 Havij.
Havij был разработан иранской охранной компанией. Он предоставляет
графический
Изм. Лист
№ докум.
пользовательский
Подпись Дата
интерфейс
(GUI)
и
представляет
собой
ПКИТ 1315000.027-15 ПЗ
Лист
13
автоматизированный инструмент SQLi, поддерживающий несколько методов
Это
SQLi.
имеет
особое
значение
для
поддержки
тестировщиков
на
проникновение в поиске уязвимостей на веб-страницах. Хотя он предназначен в
первую очередь для Windows, существуют обходные пути, позволяющие
заставить его работать и в Linux.
1.4.5 Burp.
Сканер веб-уязвимостей в Burp Suite использует исследования PortSwigger,
чтобы
помочь
пользователям
автоматически
находить
широкий
спектр
уязвимостей в веб-приложениях. Например, Burp Collaborator определяет
взаимодействия между своей целью и внешним сервером для проверки на наличие
ошибок, невидимых для обычных сканеров, таких как асинхронная SQL-инъекция
и слепая подделка запросов на стороне сервера (SSRF).
Механизм обхода в Burp Scanner, лежащий в основе таких крупных пакетов,
как Burp Suite Enterprise Edition и Burp Suite Professional, устраняет такие
препятствия, как маркеры для подделки межсайтовых запросов (CSRF),
функциональность с отслеживанием состояния и перегруженные или изменяемые
URL-адреса. Его встроенный браузер Chromium отображает и сканирует
JavaScript. Алгоритм обхода создает профиль своей цели аналогично тестеру.
Burp
также
предназначен
для
обработки
динамического
контента,
нестабильных интернет-подключений, определений API и веб-приложений. Кроме
того, проверки сканирования могут быть выбраны индивидуально или по
группам, а пользовательские конфигурации могут быть сохранены, например,
конфигурация
сканирования
для
сообщения
только
об
уязвимостях,
появляющихся в OWASP Top 10.
1.4.6 Leviathan.
Leviathan характеризуется как набор инструментов для массового аудита.
Как таковой, он содержит ряд возможностей для обнаружения служб, перебора,
обнаружения
SQL-инъекций
и
запуска
пользовательских
возможностей
эксплойтов. Он включает в себя несколько инструментов с открытым исходным
кодом, включая mass can, ncrack и DSSS, которые можно использовать по
отдельности или в комбинации.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
14
Кроме того, он может обнаруживать службы FTP, SSH, Telnet, RDP и
MySQL, работающие в определенной стране или в диапазоне IP. Обнаруженные
службы затем могут быть подвергнуты грубой силе с помощью ncrack. Команды
могут
выполняться
удаленно
на
скомпрометированных
устройствах.
Специфичный для уязвимостей SQLi, он может обнаруживать их на веб-сайтах с
расширениями стран.
Таблица 1.1 – Результаты сравнения
Характерист
ики
SQLMap
Havij
jSQL
Injection
Burp
Netsparker
Leviat
han
Авторизаци
я в системе
-
-
-
-
+
-
Поиск
“GET” SQLi
+
+
+
+
+
+
Поиск
«POST»
SQLi
Поиск
уязвимостей
другого
типа
Наличие
ГИП
Формирован
ие
отчета
+
+
+
+
+
+
+
+
+
+
+
+
-
+
+
+
+
-
+
+
+
-
+
-
Основываясь на проведённом исследовании можно заявить что найти и
эксплуатировать уязвимости вида SQL Injection может каждый желающий
уверенный пользователь компьютера. Это делает данный вид инъекции
опасным, т.к. даже в 2022 году огромное количество сайтов подвержено данной
уязвимости.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
15
1.5 Анализ и выбор средств реализации
проекта
Выбор средств и методов реализации проекта будет зависеть от нескольких
факторов:

потребности и возможности пользователей;

реализуемые функции программного обеспечения.
Решение, разрабатываемое в рамках дипломной работы должно быть
доступно широкому кругу пользователей с разным уровнем подготовки и
владения
веб-технологиями.
Данное
требование
будет
влиять
на
вид
программного обеспечения, которое будет разрабатываться, это может быть:

тонкий
клиент,
предоставляющий
пользователю
возможность
осуществлять поиск уязвимостей с помощью веб-интерфейса;

толстый клиент.
При клиент-серверном подходе к организации программного обеспечение
взаимодействие между пользователями и сервером содержащим бизнес-логику
происходит через браузер, поэтому проблема кроссплатформенности в этом
случае не стоит, так как ее берет на себя разработчик браузера. Пользователю
достаточно иметь устройство с установленным браузером, чтобы начать работать
в системе. В этом заключается основное преимущество по сравнению с толстыми
клиентами. При этом, попадая в систему с разных устройств, пользователь будет
видеть одинаковый или практически одинаковый, но содержащий идентичный
функционал интерфейс, что облегчит освоение приложения.
Работа через веб-приложение не предполагает дополнительной установки
программного обеспечения со стороны пользователя, за исключением случаем,
когда функционал браузера достаточен в полной мере для работы.
1.6 Оценка рисков
Веб-приложения, как известно, уязвимы для атак с внедрением кода.
Учитывая это, специалистам-практикам необходимо оценить риск, создаваемый
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
16
приложениями из-за атак с внедрением кода, чтобы заранее спланировать
применение необходимых подходов к смягчению последствий. Существует
наблюдение, что традиционные подходы к оценке рисков хорошо работают, когда
заранее известны количественные значения конкретных параметров модели
расчета рисков. На практике их трудно правильно предсказать. Более того, одна
конкретная уязвимость при внедрении кода может быть использована различными
способами, что может привести к различным типам уровня серьезности. Кроме
того, различные типы уязвимостей при внедрении и их последствия не могут быть
объединены в существующих подходах.
Чтобы устранить эти ограничения, мы предлагаем систему на основе
нечеткой логики (FLS) для оценки риска, связанного с различными типами
уязвимостей при внедрении кода. Наш дальнейший вклад - это набор
предлагаемых показателей на уровне кода, которые могут быть использованы для
определения лингвистических терминов для субъективного выражения уровней
уязвимости и их влияния. Применяются вложенные FLS для объединения рисков
от нескольких уязвимостей для оценки одного значения, представляющего общий
риск.
Происходит
оценивание
с
помощью
реального
веб-приложения,
реализованных на PHP, где применяется SQL-инъекция (SQLI) и Межсайтовый
скриптинг (XSS), две наиболее часто отмечаемые уязвимости в современных вебприложениях. Первоначальные результаты показывают, что предлагаемый подход
может эффективно оценивать высокие риски, присущие уязвимым приложениям.
Конфиденциальные данные, как правило, передаются через Интернет и,
следовательно,
становятся
достоянием
общественности.
Учитывая
это,
существует очень высокий риск незаконного доступа к этим данным со стороны
хакеров и других лиц, особенно с учетом того, что веб-приложения становятся
общеизвестно уязвимыми и становятся объектом большинства интернет-атак. В
этом документе предлагается оценка веб-сканеров, которые использовались для
обнаружения
недостатков
безопасности
веб-приложений.
В
частности,
фокусировка направлена на уязвимости SQL-инъекций в веб-приложениях.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
17
1.7 Методы обнаружения SQLi
В зависимости от характера защиты, принципа обнаружения, методы
обнаружения могут быть классифицированы как:
1.7.1 Классификация по характеру защиты.
Исследователи предложили множество различных методов защиты для
решения проблем, связанных с SQLi. Эти различные методы могут иметь разную
природу защиты. Природа защиты определяет, как техника будет защищать
приложение от инъекций. Согласно Halme , характер защиты для системы
обнаружения вторжений (IDS) можно разделить на шесть категорий высокого
уровня, а именно: предотвращение,упреждение, отклонение, сдерживание,
обнаружение и контрмеры. В то время как Hal-fond классифицировал природу
защиты для методов защиты SQLi только на два типы; обнаружение и
предотвращение. Всего было выявлено три типа защитных действий в области
методов защиты от SQL-инъекций. Это предотвращение, обнаружение и
отклонение.
Упреждение и сдерживание естественны, поскольку их не так
легко воплотить в технологии, как другие. Более того, упреждение считается
слишком жестким, что может быть причиной отказа от его применения в этой
области исследований.Поскольку подготовленные инструкции заботятся обо всем
сдерживании SQL-инъекций , мы не классифицировали сдерживание как
отдельную защитную природу, как классифицирует Halme. Halme определил
контрмеру как мину-ловушку, в то время как Халмонд и др. использовали ее для
обозначения общих методов защиты от SQLi.
a) Предотвращение: Метод предотвращения предотвращает или серьезно
ограничивает
возможность
успеха
SQLi путем
статического
выявления
уязвимостей в коде, предложения другой парадигмы разработки для генерации
SQL-запросов или проверки приложения на предмет применения наилучших
методов защитного кодирования во время разработки.
b) Обнаружение: Метод обнаружения отличает попытки и подготовку SQLi от
нежелательной активности и предупреждает систему. Он обнаруживает SQLi в
основном во время работы. После обнаружения атак он предупреждает власти,
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
18
чтобы они могли выполнять определенные действия, такие как отклонение атак и
уклонение от них.
c) Отклонение: Техника отклонения заставляет злоумышленника поверить, что
он преуспел в попытке инъекции, в то время как реальность такова, что ему
удалось скомпрометировать только ложную информацию. Он разработан таким
образом, что злоумышленники легко привлекаются к нему. Эта техника помогает
узнать больше о различных SQLi и их атакующих обычаях. Honeypot единственная техника, которая подпадает под эту категорию.
1.7.2 Классификация по принципу обнаружения.
Каждый метод имеет свои собственные критерии для обнаружения наличия
уязвимостей в веб-приложении. Было определено четыре различных принципа
обнаружения:
 нарушение на основе грамматики;
 нарушение на основе сигнатуры/подписи;
 испорченный поток данных;
 обнаружение аномалий.
a) Обнаружение нарушений на основе грамматики: Грамматическая структура
SQL-оператора - это понятие этого метода обнаружения для обнаружения
уязвимостей SQL-инъекций. SQL-инъекция происходит, когда злоумышленник
предоставляет вредоносный ввод, который изменит структуру SQL-запроса в
соответствии с замыслом разработчика приложения. Метод обнаружения
нарушений на основе грамматики обнаруживает недопустимую структуру
инструкции SQL путем сравнения дерева синтаксического анализа или конечных
автоматов (FSM), построенных с использованием пользовательского ввода и без
пользовательского
ввода.
Дерево
синтаксического
анализа
может
быть
определено как структура данных для проанализированного представления
инструкции SQL. Если грамматические структуры деревьев синтаксического
анализа
отличаются,
это означает,
что пользовательский
ввод
является
вредоносным, что изменит структуру запроса с отступами и не позволит
выполнить инструкцию SQL. Например, на рисунке 1.8 показано представление
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
19
SQL-запроса с помощью конечного автомата (FSM) для примера, показанного на
рисунке 1.3.
Рисунок 1.8 – FSM для SQL запроса
SQLi обнаружен, потому что FSM построен на основе пользовательского
ввода (david’ OR ’1’ = ’1’ –) имеет грамматическую структуру, отличную от той,
которая была создана без ввода пользователем. Дерево синтаксического анализа
построено таким образом, что любые ключевые слова SQL, которые пользователи
включили
в
пользовательский
ввод,
создадут
неуникальный
корень.
Следовательно, наличие неуникальных корней в дереве синтаксического анализа
SQL-запроса указывает на SQLi.
b) Обнаружение на основе сигнатур/подписей: Сигнатура может быть
такой же простой, как регулярное выражение, описывающее известный шаблон
атаки. Системы обнаружения на основе сигнатур поддерживают список
возможных сигнатур атаки, а затем сравнивают внешние входные строки со
списком сигнатур во время выполнения, чтобы обнаруживать и блокировать
шаблоны, связанные с внедрением SQL. Идея методов обнаружения на основе
сигнатур заключается в поиске известных шаблонов атак для блокирования. Было
выделено две подкатегории методов обнаружения на основе сигнатур:

Входная сигнатура. Методы обнаружения входных сигнатур
обнаруживают
потенциальные вредоносные символы путем проверки внешних входных
строк на соответствие белому списку или черному списку. Белый список - это
набор безопасных (возможно правильных) значений, тогда как черный список это набор небезопасных (отрицательных) значений. В белом списке внешние
входные строки проверяются на соответствие набору правильных входных
значений / шаблонов / условий и блокируют все, что не включено белый список. В
черном списке внешние входные строки проверяются на соответствие набору
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
20
отрицательных / неверных значений / шаблонов / условий и очищают ввод с
помощью определяемых пользователем действий, таких как отклонение,
экранирование (добавление обратного слеша) и т.д. Одинарная кавычка (’)
является одним из примеров черного списка;

Выходная сигнатура. Методы обнаружения выходных сигнатур обнар
уживают потенциальные вредоносные символы в выходных данных выполнения
веб-приложения до того, как они будут отправлены для построения SQL-запроса.
Важно иметь в виду, что выходные данные часто содержат вводимые
пользователем данные. Безопасная обработка выходных данных важна для
предотвращения уязвимостей от атак SQL-инъекций;
c) Обнаружение испорченного потока данных: Ключевая идея обнаружения
потока зараженных данных заключается в том, чтобы определить, попадут ли
зараженные данные в чувствительные приемники в приложении. Испорченные
данные - это данные, введенные пользователем, которые всегда следует
рассматривать как вредоносные. Чувствительные приемники - это любая точка
приложения, которая может привести к проблемам безопасности при выполнении
над любым несанкционированным пользовательским вводом. Обнаружение
потока испорченных данных идентифицирует вводимые пользователем данные, а
также ненадежные источники и отслеживает все данные, на которые влияют эти
входные
данные.
Обнаружение
испорченных
потоков
данных
можно
дополнительно разделить на две подкатегории:
 Позитивное заражение. Подход с позитивным заражением идентифицирует
и помечает доверенные данные вместо ненадежных данных. Это позволяет только
доверенным данным формировать семантически корректный SQL запросы, такие
как ключевые слова и операторы SQL. В авторы предлагают положительное
заражение, которое помечает надежные данные в исходном коде и гарантирует,
что все SQL-запросы строятся только с использованием надежных данных;
 Негативное заражение. Подход с негативным заражением идентифицирует и
помечает ненадежные данные вместо надежных данных. Он в основном
отслеживает
Изм. Лист
№ докум.
испорченность
Подпись Дата
значений
данных
и
специально
проверяет
ПКИТ 1315000.027-15 ПЗ
Лист
21
вредоносное содержимое только в тех частях выходных данных, которые
поступили из ненадежных источников;
d) Обнаружение аномалий. Методы обнаружения аномалий вызывают тревогу,
когда поведение приложения во время выполнения отличается от нормального
поведения системы, которое отслеживалось во время периода обучения. Выявить
ненормальное поведение приложения во время выполнения довольно сложно.
Текущее
состояние
приложения
периодически
сравнивается
с
моделями
нормального поведения системы для выявления аномалий. Методы обнаружения
аномалий могут идентифицировать только те атаки, которые были смоделированы
во время периода обучения:
 Основанный на обучении. Основанный на обучении подход к обнаружению
аномалий основан на обучающем наборе данных для построения профилей
нормального, безопасного поведения приложений. Он обычно использует методы
интеллектуального анализа данных, методы кластеризации для характеристики
сетевого трафика
и выявления
моделей вторжений.
Некоторые
методы
используют статистический анализ для характеристики поведения пользователя, в
то время как другие используют искусственную нейронную сеть (ANN) для
обучения и изучения обычной схемы трафика. Некоторые методы создают
законные библиотеки во время обучения и обнаруживают атаку с использованием
этой библиотеки. В авторы описан основанный на обнаружении аномалий подход
к обнаружению атак веб-приложения , основанный на анализе внутреннего
состояния веб-приложения. Он обучается , анализируя взаимосвязь между
внутренним состоянием веб-приложения и критическими точками выполнения
приложения, чтобы идентифицировать атаку, которая пытается перевести
приложение в аномальное состояние, например, в обход предполагаемого
рабочего процесса веб-приложения;
 На основе программирования. Описание принятого поведения сети
программируется администратором сети или пользователем для обнаружения
аномальных событий (которые выходят за рамки модели принятого поведения
сети). Таким образом, пользователь определяет правила в отношении того, что
считается достаточно ненормальным, чтобы приложение могло предупредить о
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
22
нарушении безопасности. Обнаружение аномалий на основе программирования
использует обученные спецификации нормального поведения и генерирует
пороговые значения для различных параметров. Такими параметрами могут быть
количество сетевых подключений, количество неудачных логины и т.д.
Пороговые значения определяют, следует ли подавать сигнал тревоги или нет.
Например, сигнал тревоги, если количество неудачных входов в систему
превышает два.
1.7.3 Классификация по методу анализа.
Методы обнаружения
SQL-инъекций используют несколько различных
методов анализа для обнаружения наличия уязвимостей в веб-приложении. Мы
определили
шесть
различных
типов
методов
анализа:
безопасное
программирование, статический анализ, динамический анализ, гибридный анализ,
тестирование черного ящика и тестирование белого ящика.
a) Безопасное программирование: Безопасное программирование - это
защитный подход к кодированию для уменьшения уязвимости при внедрении
путем реализации процедур проверки входных данных или использования
существующих стандартных API или библиотечных классов для построения
предложения в исходном коде приложения во время разработки. Существует
множество доступных защищенных библиотек, предоставляемых поставщиками.
SQL DOM рекомендует разработчикам использовать набор классов, который
строго типизирован для схемы базы данных. Вместо использования манипуляций
со строками для построения динамического SQL запросы, запрограммированные
разработчиками, использует безопасный API для генерации SQL-инструкций,
которые позаботится о безопасности и, таким образом, избежит вредоносных
символов,
чтобы
предотвратить
атаки
с
использованием
SQL-инъекций.
Основным недостатком безопасного программирования является то, что оно
требует обучения разработчиков правильному использованию защищенных
библиотек.
b) Статический анализ: Методы статического анализа анализируют артефакты
приложений, такие как исходный код, двоичный код, байтовый код и файлы
конфигурации, чтобы получить информацию о приложении. Информация может
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
23
заключаться в том, как данные будут передаваться во время выполнения без
выполнения кода. Некоторые методы основаны на сложном статическом анализе
для
выявления
статический
возможных
анализ
может
уязвимостей
привести
в
к
коде.
Такой
большому
консервативный
количеству
ложных
срабатываний.
c)
Динамический
анализ: Методы
динамического
анализа
анализируют
информацию, полученную во время выполнения программы, для обнаружения
уязвимостей SQL-инъекций. Информация может быть запрошена и шаблоны
ответов, структура запросов. Динамический анализ может выполняться во время
тестирования во время разработки или во время выполнения после выпуска.
Недостатком динамического анализа является то, что он обнаруживает только
уязвимости в путях выполнения, но не может обнаружить те, которые не были
выполнены в коде.
d) Гибридный
анализ: Гибридный
анализ
использует
комбинацию
как
статического, так и динамического анализа для анализа информации, полученной
во время выполнения программы. В некоторых методах используется гибридный
анализ для снижения накладных расходов на производительность и повышения
эффективности обнаружения уязвимостей. AMNESIA использует комбинацию
статического и динамического анализа для противодействия атаке SQL-инъекций.
В части статического анализа он анализирует код приложения и автоматически
генерирует модель законных запросов. Находясь в динамической части, он
отслеживает все динамически генерируемые запросы во время выполнения и
сравнивается с законными запросами, построенными с помощью статической
модели.
e) Тестирование «Black box»: Тестирование «Black box» - это метод разработки
тестов для обнаружения уязвимостей путем тестирования приложения на основе
спецификации
требований.
Спецификация
требований
означает,
каковы
доступные входные данные и ожидаемые выходные данные, которые должны
быть получены в результате каждого ввода. Это не связано с исходным кодом
приложения. Например, к этой категории относятся автоматизированные методы
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
24
сканирования, такие как WAVES, Scuba. В основном он используется во время
тестирования приложения.
f) Тестирование «White box»: Тестирование «White box» - это также методы
разработки тестов для обнаружения уязвимостей путем тестирования приложения
с помощью тестовых примеров. Тестовые примеры генерируются на основе
внутренней структуры системы, то есть исходного кода. Например, Ardilla - это
инструмент тестирования белого ящика.
1.7.4 Классификация по времени обнаружения.
SQLi и их уязвимости могут бытьобнаружены во время кодирования,
тестирования или работы (т.е. во время работы).
a) Время кодирования: Если уязвимости SQLi обнаруживаются во время
кодирования цикла разработки приложения, то это рассматривается как
обнаружение времени кодирования. Обнаружение уязвимостей на этой ранней
стадии помогает снизить затраты, вызванные поздним обнаружением. Методы
статического анализа обнаруживают уязвимости SQLi во время кодирования без
необходимости выполнения кода.
b) Время тестирования: Если SQLi и их уязвимости обнаруживаются во время
тестирования цикла разработки приложения, то это считается обнаружением во
время тестирования. Различные подходы к тестированию, такие как тестирования
«white box» и «black box» , могут использоваться в качестве методов анализа во
время тестирования для обнаружения атак и их уязвимостей.
c) Время работы: Если SQLi и их уязвимости обнаруживаются во время
выполнения в реальном мире после выпуска продукта, то это считается
обнаружением во время работы. Методы защиты во время выполнения обычно
предотвращают SQLi, прекращая выполнение атак или очищая их. Однако в
случае ложных срабатываний прекращение выполнения может привести к
значительным неудобствам для пользователей.
1.7.5 Классификация по месту обнаружения.
SQLi и их уязвимости могут быть обнаружены в различных местах системы. В
данном дипломном проекте они были разделены на четыре категории: клиентское
приложение, клиентский прокси-сервер, серверное приложение, серверный
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
25
прокси-сервер.
a) Клиентское приложение: Методы клиентского приложения обнаруживают
SQLi путем анализа HTML-страниц. В то время как сценарии на стороне клиента
также
анализируются
некоторыми
методами,
которые
используются
для
обнаружения как SQLi, так и межсайтовых сценариев.
b) Серверное приложение: Технология серверного приложения обнаруживает
SQLi
путем
анализа
серверного
приложения,
написанного
на
языках
программирования и скриптов.
c) Клиентский прокси-сервер: Прокси-сервер на стороне клиента действует как
шлюз или промежуточный сервер между пользователем и веб-сервером. Он
перехватывает запросы и ответы пользователя с веб-сервера, чтобы обнаружить
SQLi. После обнаружения вредоносных входных данных он либо отклоняет
запрос, либо изменяет вредоносные входные данные на безопасные входные
данные.
d) Серверный прокси-сервер: Прокси-сервер на стороне сервера действует как
дополнительный сервер между сервером приложений и сервером базы данных. Он
перехватывает SQL-запросы из приложения перед обращением к серверу базы
данных. Это помогает блокировать выполнение вредоносных запросов в базе
данных.
1.7.6 Классификация по отклику.
a)
Докладывание:
Некоторые
методы
защиты
сообщают
о
каждом
обнаружении уязвимостей в приложении. Отчет часто состоит из номера
уязвимой строки исходного кода в приложении. Инструменты статического
анализа и тестирования уязвимостей генерируют отчеты.
b) Отклонение: Некоторые методы защиты отклоняют запросы пользователя
всякий раз, когда выясняется, что пользовательский ввод является вредоносным, и
блокируют выполнение.
c) Избегание: Некоторые методы защиты вместо того, чтобы отклонять
запросы пользователей, пытаются провести очистку, избегая вредоносного ввода.
Однако экранирование вредоносного ввода по-прежнему уязвимо для атак SQLинъекций второго порядка
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
26
d)
Действие,
определяемое
пользователем:
Разработчик
приложения
определяет действие всякий раз, когда он обнаруживает вредоносный ввод. Они
могут устанавливать правила, которые будут экранировать или кодировать
вводимые пользователем данные при обнаружении вредоносного шаблона. Это
может быть отказ или избегание.
e) Предложение кода: Некоторые методы собирают информацию из исходного
кода, содержащего уязвимости SQL-инъекций, и генерируют заменяющий
безопасный код, который может поддерживать функциональную целостность
приложений. Он предлагает безопасный код всякий раз, когда обнаруживает
уязвимость.
1.7.6 Классификация по реализации.
Чтобы развернуть какие-либо методы, разработчик должен знать, требуют ли
они изменения исходного кода приложения. В соответствии с внедрением методов
мы выделили следующие две категории:
 Модификация кодовой базы. Разработчику необходимо изменить исходный
код приложения, чтобы развернуть методы защиты от SQL-инъекций. Поэтому
это часто трудоемко, отнимает много времени и утомительно;
 Никаких изменений в кодовой базе. Разработчикам не нужно изменять
исходный код приложения для развертывания методов защиты от SQL-инъекций.
Это обеспечивает гибкость и требует меньше усилий при внедрении методов;
1.8 Защита от SQL-инъекций с помощью
нормализации переменных
Авторы SQL предложили метод нормализации переменных для защиты веб
-приложений от атак SQL-инъекций. Во-первых, метод использует виртуальную
связь с базой данных для извлечения базовой структуры инструкции SQL. Вовторых, эта информация используется для проверки правильности инструкции
SQL. Если оператор SQL отличается, он будет заблокирован. Метод не требует
модификации исходного кода приложения базы данных.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
27
Суть этого метода заключается в использовании нормализации переменных
для изменения переменных и сохранения структуры инструкции SQL. Хотя
пользователь предоставил переменные (которые в основном каждый раз
отличаются) используются для построения SQL-инструкции, но базовая структура
SQL-инструкции
всегда
остается
неизменной,
и
если
предоставленные
переменные являются вредоносными, это изменит структуру SQL-инструкции, и
мы сможем это обнаружить.
Допустимый список состоит из нормализованной инструкции SQL и
требования к переменной. Допустимый список может быть определен вручную
или также может быть автоматически изучен. Прокси-диск используется для
нормализации SQL-инструкций и их сверки с доступным списком. Если
нормализованный оператор SQL существует, оператор SQL будет разрешен
выполнить, в противном случае он будет заблокирован. Авторы утверждают, что
производительность не будет снижена при нормализации переменных.
1.9
Устранение
атак
SQLi-механизм
защиты от передачи данных
Авторы
предложили
автоматизированный
метод,
который
сочетает
статический анализ с проверкой во время выполнения для защиты от атак SQLинъекций. Модификация исходного кода не требуется для развертывания этого
метода (требуется только простое исправление веб-сервера) и может быть легко
интегрирована с текущей существующей системой.
Этот метод использует библиотеку анализа строк java для выполнения
статического анализа
исходного кода. На
статической фазе
он строит
предполагаемую структуру SQL-запроса в виде SQL graph в, и во время
выполнения SQL graph проверяется на соответствие всем внешним входным
данным чтобы перехватить вредоносный запрос и предотвратить его отправку в
базу данных для выполнения. Авторы представили конкретные результаты оценки
в сравнении с различными показателями эффективности.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
28
2 ПРОЕКТНАЯ ЧАСТЬ.
2.1 Разработка организационных
мероприятий
Организационными мероприятиями обеспечивающие работу на языках
программирования HTML, PHP
и других вспомогательных языках для
создания проекта на программе Sublime Text, являются:
1) правильная настройка программы;
2) настройка
нужной
кодировки
для
полной
функциональности
программы;
3) правильный ввод кода для построения проекта;
4) создания базы данных для взаимодействия с локальным веб-ресурсом;
5) выбор браузера, на котором будет выполняться работа;
6) демонстрация ввода кода на веб приложение от лица злоумышленника
для демонстрации SQLi;
7) предоставление методов защиты от лица разработчика данного веб
приложения от SQL-инъекций.
Для достижения поставленной цели необходимо решить следующие
задачи:
– исследовать предметную область и выявить особенности проведения
SQL-инъекций;
–
провести
сравнительный
предназначенных для выявления
анализ
существующих
решений,
уязвимостей вида SQLi, выявить их
преимущества и недостатки;
– разработать эффективные алгоритмы поиска SQL-инъекций;
–
провести
технико-экономическое
обоснование,
тестирование
и
апробацию предложенного решения и наметить пути его дальнейшего
совершенствования.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
29
2.2 Настройка безопасности
веб-приложения
2.2.1 Параметризованные запросы.
Этот метод состоит в использовании подготовленных операторов с
заполнителем вопросительного знака (“?”) в наших запросах всякий раз, когда
нужно вставить пользовательское значение. Это очень эффективно и, если в
реализации драйвера JDBC нет ошибки, невосприимчиво к эксплойтам.
public List<AccountDTO> safeFindAccountsByCustomerId(String customerId)
throws Exception {
String sql = "select "
+ "customer_id, acc_number, branch_id, balance from Accounts"
+ "where customer_id = ?";
Connection c = dataSource.getConnection();
PreparedStatement p = c.prepareStatement(sql);
p.setString(1, customerId);
ResultSet rs = p.executeQuery(sql));
// omitted - process rows and return an account list
}
Здесь был использован метод prepareStatement(), доступный в экземпляре
соединения,
чтобы
получить
подготовленный
оператор.
Этот
интерфейс
расширяет обычный интерфейс оператора несколькими методами, которые
позволяют нам безопасно вставлять пользовательские значения в запрос перед его
выполнением.
Для JPA есть аналогичная функция:
String jql = "from Account where customerId = :customerId";
TypedQuery<Account> q = em.createQuery(jql, Account.class)
.setParameter("customerId", customerId);
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
30
При запуске этого кода под Spring Boot можно установить ведение журнала
свойств.level.sql для отладки и просмотра того, какой запрос на самом деле создан
для выполнения этой операции:
[DEBUG][SQL] select
account0_.id as id1_0_,
account0_.acc_number as acc_numb2_0_,
account0_.balance as balance3_0_,
account0_.branch_id as branch_i4_0_,
account0_.customer_id as customer5_0_
from accounts account0_
where account0_.customer_id=?
Как и ожидалось, уровень ORM создает подготовленную инструкцию,
используя заполнитель для параметра CustomerID. Это то же самое, что пришлось
бы сделать в обычном случае JDBC, но с меньшим количеством утверждений, что
приятно. В качестве бонуса такой подход обычно приводит к повышению
производительности
запроса,
поскольку
большинство
баз
данных
могут
кэшировать план запроса, связанный с подготовленной инструкцией.
Стоит обратить внимание, что этот подход работает только для
заполнителей, используемых в качестве значений. Например, нельзя использовать
заполнители для динамического изменения имени таблицы:
// Это не будет работать
PreparedStatement p = c.prepareStatement("select count(*) from ?");
p.setString(1, tableName);
Получится сообщение об ошибке во время выполнения.
Основной причиной этого является сама природа подготовленного
оператора: серверы баз данных используют их для кэширования плана запроса,
необходимого для извлечения результирующего набора, который обычно
одинаков для любого возможного значения. Это не относится к именам таблиц и
другим
конструкциям,
доступным
на
языке
SQL,
таким
как
столбцы,
используемые в предложении order by.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
31
2.2.2 Очистка Пользовательских Данных.
Очистка данных - это метод применения фильтра к предоставленным
пользователем данным, чтобы их можно было безопасно использовать другими
частями нашего приложения. Реализация фильтра может сильно различаться, но в
целом мы можем классифицировать их на два типа: белые списки и черные
списки.
Черные
списки,
состоящие
из
фильтров,
которые
пытаются
идентифицировать недопустимый шаблон, обычно не имеют большого значения в
контексте предотвращения SQL–инъекций, но не для обнаружения! Подробнее об
этом позже.
Белые списки, с другой стороны, работают особенно хорошо, когда мы
можем точно определить, что является допустимым вводом.
Давайте улучшим наш метод безопасного поиска учетных записей по
идентификатору клиента, чтобы теперь вызывающий абонент мог также указать
столбец, используемый для сортировки результирующего набора. Поскольку мы
знаем набор возможных столбцов, мы можем реализовать белый список с
помощью простого набора и использовать его для очистки полученного
параметра:
private static final Set<String> VALID_COLUMNS_FOR_ORDER_BY
= Collections.unmodifiableSet(Stream
.of("acc_number","branch_id","balance")
.collect(Collectors.toCollection(HashSet::new)));
public List<AccountDTO> safeFindAccountsByCustomerId(
String customerId,
String orderBy) throws Exception {
String sql = "select "
+ "customer_id,acc_number,branch_id,balance from Accounts"
+ "where customer_id = ? ";
if (VALID_COLUMNS_FOR_ORDER_BY.contains(orderBy)) {
sql = sql + " order by " + orderBy;
} else {
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
32
throw new IllegalArgumentException("Nice try!");
}
Connection c = dataSource.getConnection();
PreparedStatement p = c.prepareStatement(sql);
p.setString(1,customerId);
}
Здесь происходит объединение подхода с подготовленным утверждением и
белый список, используемый для очистки аргумента OrderBy. Конечным
результатом является безопасная строка с заключительным оператором SQL. В
этом простом примере используется статический набор, но также могли бы
использоваться функции метаданных базы данных для его создания.
Можно использовать тот же подход для JPA, также используя API
критериев и метаданные, чтобы избежать использования строковых констант в
коде:
final Map<String,SingularAttribute<Account,?>>
VALID_JPA_COLUMNS_FOR_ORDER_BY = Stream.of(
new AbstractMap.SimpleEntry<>(Account_.ACC_NUMBER, Account_.accNumber),
new AbstractMap.SimpleEntry<>(Account_.BRANCH_ID, Account_.branchId),
new AbstractMap.SimpleEntry<>(Account_.BALANCE, Account_.balance))
.collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));
SingularAttribute<Account,?> orderByAttribute =
VALID_JPA_COLUMNS_FOR_ORDER_BY.get(orderBy);
if (orderByAttribute == null) {
throw new IllegalArgumentException("Nice try!");
}
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Account> cq = cb.createQuery(Account.class);
Root<Account> root = cq.from(Account.class);
cq.select(root)
.where(cb.equal(root.get(Account_.customerId), customerId))
.orderBy(cb.asc(root.get(orderByAttribute)));
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
33
TypedQuery<Account> q = em.createQuery(cq);
Этот код имеет ту же базовую структуру, что и в обычном JDBC. Сначала
используется белый список для очистки имени столбца, затем переходим к
созданию запроса критериев для извлечения записей из базы данных.
2.3 Контрольный пример реализации
проекта
Код скрипта на PHP, написанный для проверки уязвимости веб-приложения,
выполняет
проверку
пары
login/password
введённой
пользователем
на
соответствие с парой из БД. В случае если пары совпадают, выводится надпись
"TRUE", в ином случае - надпись "FALSE". Эту форму можно найти на
большинстве интернет-ресурсов, где вместо TRUE и FALSE пользователь получит
какие-либо права.
Демонстрация PHP кода :
<?
mysql_select_db('test', mysql_connect('localhost','mysql', 'mysql')) ;
if($_GET["login"] && $_GET["pass"]){
$login=$_GET["login"];
$pass=$_GET["pass"];
$sql = "SELECT * FROM `user` WHERE `login`='$login' AND
`password`='$pass'";
$result = mysql_query($sql) or die(mysql_error());
if(mysql_num_rows($result)) echo "TRUE";
else echo "FALSE";
}
?>
<body>
<form action="" method="get">
Логин:<input type="text" name="login" value="<?=$_GET["login"]?>"/>
Пароль:<input type="text" name="pass" value="<?=$_GET["pass"]?>"/>
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
34
<input type="submit" value="submit"/>
</form>
</body>
Для проверки были введены правильные данные для входа:
логин = admin
пароль = 123456
Рисунок 2.1 – Ввод правильных данных.
Вывелась надпись TRUE, теперь выполняется проверка с не правильным паролем
для вывода надписи FALSE.
Рисунок 2.2 – Ввод неправильных данных
Все работает правильно — пары логин и пароль, проверяются, и корректно
обрабатываются. Для демонстрации SQL-инъекции в форме входа необходимо
ввести любой логин и в поле пароля запись вида «' OR 1='1».
Рисунок 2.3 – SQLi в форме входа
Это сработало, и скрипт теперь показывает нам, что авторизация прошла
успешно и пара login/password введена верно. Так как защита от SQL инъекций в
скрипте не предусмотрена, злоумышленник запросто может оперировать
информацией из базы данных, подставляя совершенно любые запросы.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
35
Аналогично можно выполнить SQL инъекцию с помощью адресной строки,
дописав к GET параметрам такую информацию:
«sql/index.php?login=admin&pass=luboj+'+OR+1='1» и
в
результате
появится
надпись «TRUE».
Скрипт, получая данные, выполняет запрос к базе данных, следующего
вида:
$sql = "SELECT * FROM `user` WHERE `login`='$login' AND `password`='$pass'";
При передаче в него переменных $login и $pass получится следующий запрос:
SELECT * FROM `user` WHERE `login`='admin' AND `password`='luboj '
И в соответствии с найденным или не найденным результатом будет показано
сообщение.
2.3.1 Что происходит при данной SQL инъекции.
Передав в переменную пароля $pass строку «' OR 1='1» на SQL сервер уйдет запрос
вида:
SELECT * FROM `user` WHERE `login`='admin' AND `password`='' OR 1='1'
Т.е. к исходным параметрам проверки будет добавлено новое условие, OR
1=’1′ , выполняющееся всегда, так как единица при любом раскладе равна
единице. Соответственно полученному запросу сервер вернет строки из таблицы
пользователей, и скрипт выведет значение TRUE.
Рисунок 2.4 – Демонстрация параметра TRUE
2.3.2 Настройка защиты от SQLi.
Защита веб-приложений от SQLi необходима, даже в случае если БД не имеет в
себе важных данных, ведь это поможет сэкономить время, не тратя его на
восстановление удаленных таблиц мелкими злоумышленниками.
Способов защиты от SQLi огромное множество, но никакой из этих
способов не дает полной защищенности. Так как на каждое действие есть
противодействие, заинтересованный хакер с хорошим опытом скорее всего найдет
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
36
способ, чтобы получить доступ к базе данных.
Для защиты придётся прибегнуть к использованию стандартных PHP
функций mysql_real_escape_string() и sprintf().Функция
mysql_real_escape_string()
экранирует специальные символы строки, таким образом, изменяя синтаксис
параметров
Функция
sprintf()
директивы
запроса
SQL
и
приводя
его
в
негодность.
возвращает отформатированную строку. Нам пригодятся
вида
%s
—
строка,
и
%d
–
целое
число.
Стоит принять за правило, что пароль в системе должен быть всегда целым
числом, и изменим код таким образом:
<?
mysql_select_db('test', mysql_connect('localhost','mysql', 'mysql')) ;
if($_GET["login"] && $_GET["pass"]){
$login=$_GET["login"];
$pass=$_GET["pass"];
$sql = "SELECT * FROM `user` WHERE `login`='%s' AND `password`='%d'";
$query = sprintf($sql, $login, $pass);
$result = mysql_query($query) or die(mysql_error());
if(mysql_num_rows($result)) echo "TRUE";
else echo "FALSE";
}
?>
Теперь в $sql подставляется не $login и $pass, как это было ранее, а
директивы %s и %d. Этим учитывается условие, что пароль должен быть
числовым. Затем эта строка передается вместе с параметрами $login и $pass в
функцию sprint() , для форматирования.
На данный момент при попытке провести SQL-инъекцию как это
показывалось ранее, атака проходит безрезультатно, и скрипт возвращает надпись
FALSE, так как функцией sprint() строка в переменной $pass заменяется на ноль и
запрос принимает вид:
SELECT * FROM `user` WHERE `login`='admin' AND `password`='0'
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
37
Рисунок 2.5 – Демонстрация начальной защиты
Данный способ лишь часть защиты от SQLi , ведь в реальности пароль является не
числом а строкой, и если вместо %d подставить директиву %s , то мы опять будем
получать
TRUE.
Для
того,
чтобы
избежать
этого
воспользуемся
mysql_real_escape_string(), и код примет такой вид:
<?
mysql_select_db('test', mysql_connect('localhost','mysql', 'mysql')) ;
if($_GET["login"] && $_GET["pass"]){
$login=$_GET["login"];
$pass=$_GET["pass"];
$sql = "SELECT * FROM `user` WHERE `login`='%s' AND `password`='%s'";
$query = sprintf($sql,
mysql_real_escape_string($login),
mysql_real_escape_string($pass));
echo $query."<br/>";
$result = mysql_query($query) or die(mysql_error());
if(mysql_num_rows($result)) echo "TRUE";
else echo "FALSE";
}
?>
Переменные $login и $pass мы прогоняем через mysql_real_escape_string(),
экранируя все спецсимволы, если таковые имеются.
В этом случае итоговый SQL запрос после инъекции будет иметь не корректный
вид:
SELECT * FROM `user` WHERE `login`='a' AND `password`='iol \' OR 1=\'1'
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
38
И как следствие скрипт вернет в результате надпись FALSE.
Рисунок 2.6 – Демонстрация конечной защиты
Данный метод подойдет для базовой защиты любого php проекта, но для
предотвращения
инъекций,
необходимо тщательно проверять полученные
параметры от пользователя, любыми образами.
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
39
3 ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ
ЭФФЕКТИВНОСТИ ПРОЕКТА
3.1 Выбор и обоснование методики
расчета экономической части
Общие трудозатраты Tо получаются суммированием всех трудозатрат на
нормированные и ненормированные работы (операции), а также внеплановые
задания и работы, связанные с непредвиденными ситуациями. Используемые в
организациях нормы труда содержат нормативы времени и выработки каждого
сотрудника. Расчет трудозатрат на работы по основной и дополнительной
деятельности выражается в рабочих днях или часах.
Задача расчета трудозатрат является одной из самых важных задач. Для
определения общих трудозатрат работников отдела безопасности необходимо
охватить весь круг обязанностей сотрудников отдела безопасности и вычислить
необходимое время выполнения работ, связав их с компетентностью сотрудника.
Средние
отдела
на
трудозатраты
обслуживание
сотрудников
АРМ
одноранговой
информационно-технологического
(автоматизированных
рабочих
и
мест)
в
доменной
системах представлены в таблице 1.
Таблица 3.1 - Нагрузка на сотрудника безопасности при использовании
отдельных автоматизированных рабочих мест (Н о)
№
Наименование работ
1
Разработка частной модели угроз
Установка систем безопасности (включая установку
специальных средств, плат безопасности)
Составление паспорта безопасности рабочего места
Установление антивирусных средств
Составление перечня защищаемых помещений и технический
паспорт защищаемого помещения
Разграничение прав доступа к информационным ресурсам
Резервное копирование данных ( с учетом записи на съемные
носители и сдача в архив)
Ведение журнала учета съемных носителей информации
2
3
4
5
6
7
8
Изм. Лист
№ докум.
Подпись Дата
Трудоёмкость
норма-час
2
3
3
2
5
2
20
1
ПКИТ 1315000.027-15 ПЗ
Лист
40
9
10
11
12
13
14
15
16
17
18
Ведение журнала учета криптографических средств
1
информации
Ведение журнала учета средств криптографической защиты
1
информации
Восстановление работоспособности технических средств
1
Внесение в список сотрудников, допущенных к работе с
1
персональными данными
Составление актов об уничтожении персональных данных и
1
уничтожении данных
Составление плана мероприятий и включение данного АРМ в
1
список мероприятий по защите информации
Внесение в план проверок и составление перечня
1
проверяемых субъектов на данном АРМ
Установка обновлений систем безопасности
4
Внесение сотрудника в матрицу доступа к сведениям
4
конфиденциального характера и сверки имеющихся ресурсов
Проведение проверок рабочих мест
5
Итого на одно рабочее место:
58
Если организация ввела доменную систему, то возможности сотрудника
безопасности значительно возрастают (таблица 2).
Таблица 3.2 - Нагрузка на сотрудника безопасности при использовании
домена (Нд)
№
Наименование работ
Разработка частной модели угроз
Установка систем безопасности
Составление паспорта безопасности
3
рабочего места
4
Установление антивирусных средств
Составление перечня защищаемых
5
помещений и технический паспорт
защищаемого помещения
Разграничение прав доступа к
6
информационным ресурсам
Резервное копирование данных ( с учетом
7
записи на съемные носители и сдача в
архив)
Ведение журнала учета съемных носителей
8
информации
Ведение журнала учета
9
криптографических средств информации
Ведение журнала учета средств
10
криптографической защиты информации
1
2
Изм. Лист
№ докум.
Подпись Дата
Трудоёмкость
норма-час
2
3
Примечание
3
0
Централизованно
5
0,5
Централизованно
1
Централизованно
1
1
1
ПКИТ 1315000.027-15 ПЗ
Лист
41
11
12
13
14
15
16
17
18
Восстановление работоспособности
1
технических средств
Внесение в список сотрудников,
допущенных к работе с персональными
1
данными
Составление актов об уничтожении
персональных данных и уничтожении
1
данных
Составление плана мероприятий и
включение данного АРМ в список
1
мероприятий по защите информации
Внесение в план проверок и составление
перечня проверяемых субъектов на данном
1
АРМ
Установка обновлений систем
0
безопасности
Внесение сотрудника в матрицу доступа к
сведениям конфиденциального характера и
4
сверки имеющихся ресурсов
Проведение проверок рабочих мест
5
Итого на одно рабочее место:
31
Общие трудозатраты Tо определяются по формуле (1):
116
Централизованно
-
Т 0  Н 0  n1   ( Н д  n2 )
Т 0  58  2  (31  48) = 1604 чел./час
(3.1)
где Но - нагрузка на сотрудника безопасности при использовании отдельных
автоматизированных рабочих мест, чел/час;
Нд - нагрузка на сотрудника безопасности при использовании домена,
чел/час;
n1, n2 - парк рабочих мест, количество.
3.2 Расчет затрат на обеспечение работ по
информационной безопасности
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
42
Затраты на обеспечение информационной безопасности определяются по
формуле (2):
ЗИБ  М з  Фот  Зноф  Зэн  А  НР
ЗИБ  1986  1266503,96  143874,84  34281,04  191315,86  765263,45  2403225,15
(3.2)
где Мз – материальные затраты,1986 тенге;
Фот - фонд оплаты труда, 1266503,96 тенге;
Зноф - затраты на налоги и отчисления в фонды, 143874,84 тенге;
Зэн – расходы на электроэнергию, отопление, освещение, 34281,04 тенге;
А - амортизационные отчисления на покупное оборудование и программное
обеспечение, 191315.86 тенге;
НР – накладные расходы, 765263,45 тенге.
2.2.1 Расчет материальных затрат
Материальные затраты прямым счетом (по факту) рассчитываются по
формуле (3):
М з  З б  З т  З др
М з  400  1000  586 = 1986
тенге
(3)
где Зб – затраты на покупку бумаги, 400 тенге;
Зт - затраты на покупку тонера для принтера, 1000 тенге;
Здр – расходы на другие канцелярские товары, 586 тенге.
Затраты на приобретение бумаги рассчитываются по формуле (4):
Зб  С б  К б ,
Зб  4  100  400
тенге
(4)
где Сб – стоимость одного листа бумаги, 4 тенге;
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
43
Кб – количество листов бумаги, 100 листов.
Затраты на приобретение тонера определяются по формуле (5):
Зк  С т  К т
Зк  1000 1  1000 тенге
(5)
где Ст – стоимость одной заправки принтера тонером, 1000 тенге;
Кт – количество заправок в процессе работы,1.
Здр (расходы на другие канцелярские товары) указываются в тенге, исходя из
потребности в них, в количестве и стоимости, необходимом для работы над
обеспечением информационной безопасности – 586 тенге.
2.2.2 Расчет фонда оплаты труда
Размер фонда оплаты труда работника(ов) службы информационной
безопасности(Фот) рассчитывается по формуле (6):
Фот  (Зосн  Здоп )  Т
Фот  (1151367,24  115136.724)  1  1266503,96
тенге
(6)
где Зoсн – основная заработная плата, 1151367,24 тенге;
Здоп – дополнительная заработная плата, 115136,72 тенге;
Т - время разработки и поддержки работоспособности систем защиты
информации, 1 месяц.
Основная
заработная
плата
работников
службы
информационной
безопасности рассчитывается по формуле (7):
Зосн  Т 0  Зчас
Зосн  1604  717,81  1151367,24 тенге
(7)
где Т0 − общие трудозатраты, 1604 чел/час (формула 1);
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
44
Зчас − заработная плата работника службы информационной безопасности за
час проработанного времени, 717,81 тенге.
Дневная заработная плата определяется, исходя из месячного оклада
работника и количества рабочих дней в месяце (в среднем - 21 - 24 рабочих дня)
[6].
Сведения по работникам службы информационной безопасности необходимо
представить в виде таблице 3.
Таблица 3 - Сведения по работникам службы информационной безопасности
Специалист –
Исполнитель
Макурин М.А.
Заработная плата в месяц,
тенге
1
137819
Итого:
137819
Результаты расчета основной заработной платы необходимо представить в
Количество, человек
виде таблицы 4.
Таблица 4- Сводные результаты расчета затрат основной заработной платы
Наименование
содержания
работ
Защита БД от
SQL Injection
Исполнитель
Трудоёмкость
норма-час
Заработная
плата за час
работы
Сумма
заработной
платы
Макурин М.А.
1604
717,81
1151367,24
Итого:
1151367,24
Дополнительная заработная плата составляет 10% от основной заработной
платы и рассчитывается по формуле (8):
Здоп 
Здоп 
Зосн  Н д
100%
1151367,24  10%
= 115136,72 тенге
100%
(8)
где Нд – коэффициент дополнительной заработной платы, 10%.
Согласно налоговому законодательству и законодательству РК о пенсионном
обеспечении из фонда оплаты труда производятся удержания и отчисления [7].
Сумма обязательного пенсионного взноса (ОПВ) рассчитывается по формуле
(9):
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
45
ОПВ  Фот 10%
ОПВ  1266503,96  10%  126650,39 тенге
9)
Сумма социальных отчислений (СО) рассчитывается по формуле (10):
СО  (Фот  ОПВ)  3,5%
СО  (1266503,96  126650,39)  3,5%  39894,87 тенге
10)
Сумма взносов на обязательное социальное медицинское страхование
(ВОСМС) рассчитывается по формуле (11):
ВОСМС  Фот  2%
ВОСМС  1266503,96  2%  25330,07 тенге
(11)
Сумма социального налога (СН) рассчитывается по формуле (12):
СН  (Фот  ОПВ  ВОСМС )  9,5%  СО
СН  (1266503,96  126650,39  25330,07)  9,5%  39894,87  65984,86 тенге
(12)
Сумма отчислений на обязательное социальное медицинское страхование
(ОСМС) рассчитывается по формуле (13):
ОСМС  Фот  3%
ОСМС  1266503,96  3%  37995,11 тенге
(13)
Затраты на налоги и отчисления в фонды (Зноф) рассчитываются по формуле
(14):
Зноф  СН  СО  ОСМС
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
46
тенге
Зноф  65984,86  39894,87  37995,11  143874,84
(14)
2.2.3 Расчет затрат на электроэнергию, освещение, отопление
Затраты на электроэнергию, освещение, отопление (З эн) рассчитываются по
формуле (15):
Зэн  Сэл  Сос  Сот
Зэн  25422,09  215,2  8643,75  34281,04
(15)
где Сэл – затраты на электроэнергию, потребляемую основными средствами,
тенге;
Сос – затраты на освещение, тенге;
Сот – затраты на отопление, тенге.
Затраты на электроэнергию (Сэл) рассчитываются по формуле (16):
Сэл  ( М k  t k )  ( M n  t n ) Tз  с
Сэл  (15  6,3)  (0,01 0,24) 21 12,81  25422,09
тенге
(16)
где Мк – потребляемая мощность ПК,15 кВт;
tк – время работы ПК в день, 6,3 час;
Мп – потребляемая мощность принтера,0,01 кВт;
tп – время работы принтера в день, 0,24 час;
Тз – количество рабочих дней, затраченных на обеспечение информационной
безопасности, 21 день;
с - стоимость1кВт, 12,81 тенге [8].
Затраты на освещение (С ос) рассчитываются по формуле (17):
Сос  С л  T  с  Tз
Сос  0,8  1 12,81 21  215,2
(17)
где Сл – мощность светоустановки в рабочем помещении, кВт;
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
47
T – количество часов освещения в день, 1 час;
с - стоимость 1кВт/час, 12,81 тенге [8];
Тз – количество рабочих дней, затраченных на обеспечение информационной
безопасности, 21 день.
Результаты расчета затрат на электроэнергию заносятся в таблицу 5.
Таблица 5 - Затраты на электроэнергию
Наименование
оборудования
Количество
рабочих дней,
Паспо затраченных
Время
Цена
ртная
на
Сум
работы
электроэнерг
мощно обеспечение
ма,
оборудован
ии, тенге/
сть,
информацион
тенге
ия, час
кВт-час
кВт
ной
безопасности,
дней
Принтер лазерный
Pantum P2207
Персональный
компьютер(50 шт)
Люминесцентная ла
мпа
(10шт)
0,01
21
0,24
12,81
64,56
15
21
6,3
12,81
1694,
76
0.8
21
4
12,81
1076,
04
Итого:
2835,
36
Затраты на отопление (Сот) рассчитываются по формуле (18):
Сот  Ц от  П л  М от
Сот  115,25  75  1  8643,75
(18)
где Цот - цена отопленияза1м2, 115,25 тенге [8];
Пл – площадь рабочего помещения, 75 м2;
Мот – количество месяцев отопительного сезона,
совпадающих с
проведением работ, 1 месяц.
2.2.4 Расчет затрат на амортизационные отчисления
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
48
Затраты на амортизационные отчисления (А) определяются по формуле (19):
А 
Сопс  Н а
12  100%  Т з
А 
15305269  15%
 191315.86
12  100%  1
(19)
где Сопс – стоимость основных средств, тенге;
На – норма годовых амортизационных отчислений от стоимости основных
средств, 15-25%;
Тз – временной период, затраченный на обеспечение информационной
безопасности, месяц.
Стоимость основных средств (Сопс) рассчитывается по формуле (20):
Сопс  Ском п  Сприн  Спо  n
Сопс  15000000  80000  58423  3  15305269
тенге
(20)
где Скомп – стоимость компьютера, 15000000тенге;
Сприн – стоимость принтера, 80000 тенге;
Спо – стоимость пакета программного обеспечения, 108423тенге;
n
-
количество
компьютеров,
на
которых
устанавливается
пакет
программного обеспечения.
2.2.5 Расчет накладных расходов
Накладные расходы (НР) – это расходы, связанные с организацией
производства
и
содержанием
производственного
оборудования.
Они
рассчитываются по формуле (21):
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
49
НР 
К з  Сопс
100%
НР 
5%  15305269
 765263,45
100%
(21)
где Кз – условный коэффициент затрат на накладные расходы от стоимости
основных средств, (5%);
Сопс – стоимость основных средств, тенге.
2.2.6 Затраты на обеспечение информационной безопасности
На основании полученных данных по отдельным статьям составляется смета
затрат на обеспечение информационной безопасности по форме, приведенной в
таблице 6.
Таблица 6 - Смета затрат
Наименование
Материальные затраты
Фонд оплаты труда
Затраты на налоги и отчисления в фонды
Затраты на электроэнергию, освещение,
отопление
Затраты на амортизационные отчисления
Накладные расходы
Себестоимость затрат на обеспечение
информационной безопасности
Сокращенное
обозначение
Мз
Фот
(Зноф)
Сумма, тенге
1986
1266503,96
143874,84
Зэн
34281,04
А
НР
191315.86
765263,45
СИБ
2403225,15
2.3 Расчет экономического эффекта от
внедрения мероприятий по информационно
й безопасности
2.3.1 Система защиты от вредоносного ПО (SPSM)
Формула для расчета (22):
Изм. Лист
SPSM 
ISM
EBSM
SPSM 
1205
1
1200
№ докум.
12/1200
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
(22)
Лист
50
где ISM – сумма инцидентов, связанных с вредоносным ПО;
EBSM – сумма обнаруженных и блокированных инцидентов, связанных с
вредоносным ПО.
Критерии:
1) Неудовлетворительно: SPSM>0.001;
2) Удовлетворительно: SPSM<0.001
Если SPSM имеет неудовлетворительное значение, необходим пересмотр
данной процедуры обеспечения ИБ.
2.3.2 Управление конфигурациями ПО
Формула расчета (23):
F
47
 100%  94
50
(23)
где A – количество ОС, имеющих актуальную версию;
B – общее количество используемых ОС.
Критерии:
1) Неудовлетворительно F90%;
2) Удовлетворительно F>90%.
Если F <90%, необходим пересмотр данной процедуры обеспечения ИБ
Вывод: Себестоимость затрат на обеспечение информационной безопасности –
2 403 225,15
тенге;
Система
защиты
от
неудовлетворительно ; Управление
вредоносного
конфигурациями
ПО
–
0,01
–
ПО
–
94
–
удовлетворительно.
ЗАКЛЮЧЕНИЕ
В рамках данной дипломной работы была разработана защита веб-системы
от SQL-инъекций, с целью помочь начинающим разработчикам веб-сайтов и вебприложений
Изм. Лист
№ докум.
начальной
Подпись Дата
защитой
от
злоумышленников
веб-системы.
ПКИТ 1315000.027-15 ПЗ
Лист
51
В ходе разработки дипломной работы, была проанализирована предметная
область,
проведен
программирования,
анализ
были
используемых
элементов
проанализированы
языки
языка
и
и
среды
инструменты,
предназначенные для защиты веб-систем.
Представленные функции и переменные в полной мере выполняют
заданные им роли, а их названия кратко описывают их цель и задачи.
ПРИЛОЖЕНИЕ А
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Введение
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
52
Информационные
системы
сегодня
являются
важной
частью
организаций. Независимо от того, рассматриваем ли мы крупное глобальное
предприятие или начинающего предпринимателя, роль информационных
технологий жизненно важна. В случае технологической проблемы, остановки
системы
или
чего-то
подобного
результаты,
как
правило,
являются
значительными и приводят к остановке деятельности компании.
Например, продажи не могут быть осуществлены, если система продаж
не функционирует. Поэтому важно разрабатывать информационные системы,
которые будут служить надежной основой для процессов и деятельности
внутри организации. Здесь мы рассматриваем управление информационными
системами
как
важнейший
фактор
успеха
операций
и
деятельности
организации.
1 Основание для разработки
Система разрабатывается на основании задания, рассмотренного и
утвержденного
на
заседании
кафедры
«Информационных технологий»,
протоколом №03 от «03» марта 2022г.
2 Назначение
Целью дипломной работы является разработка функций для защиты от
SQL-инъекций.
пользователям
Разработанные
веб-ресурсов
функции
не
защиты
связываться
с
призваны
проблемами
помочь
из-за
злоумышленников, и решать свои дела на различных веб-сайтах без какого
либо опасения. Также данная разработка позволит обезопасить базы данных и
не бояться что кто-то получит к ней доступ. Данной функцией защиты
предназначено пользоваться как начинающим, так и профессиональным
разработчикам веб-ресурсов и веб-приложений.
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ А
3 Требования
к
программе
или
программному изделию
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
53
Разрабатываемые функции защиты должны соответствовать следующим
требованиям:
1) Простой ввод функций защиты при разработке разработчиком вебсайта;
2) Открытый доступ к веб-приложению после ввода функций защиты для
любого пользователя в сети интернет;
3) Возможности корректировки с помощью любых редакторов;
4) Возможности использования данной функцией защиты во всем мире;
5) Безопасности веб-систем;
Результатом работы защиты интернет-ресурса от SQL-инъекций является
обеспечение безопасности данных пользователя, а также остальных данных в
БД при нахождении в веб-системе.
ПРИЛОЖЕНИЕ Б
РЕГЛАМЕНТ ИСПОЛЬЗОВАНИЯ
СИСТЕМЫ
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
54
Система функций защиты от SQL-инъекций имеет свои правила за счет
чего
защита
проходит
качественно
и
безошибочно.
Для
функции
htmlspecialchars(), можно выделить такие правила как:
1) При использовании параметра encoding, определяющий кодировку,
используемую при конвертации символов. Если не указан, то значение по
умолчанию для encoding зависит от конфигурационной опции default_charset.
Хотя этот аргумент является технически необязательным, настоятельно
рекомендуется указать правильное значение для кода, опция конфигурации
default_charset может быть задана неверно для входных данных;
2) Кодировки ISO-8859-1, ISO-8859-15, UTF-8, cp866, cp1251, cp1252 и
KOI8-R являются практически эквивалентными, предполагая то, что сама
строка string содержит корректные символы в указанной кодировке, то
символы, изменяемые htmlspecialchars(), останутся на тех же местах во всех
этих кодировках;
3) Не рекомендуется устанавливать опцию конфигурации default_charset в
пустое значение;
4) Если
параметр
double_encode
выключен,
то
PHP
не
будет
преобразовывать существующие html-сущности. По умолчанию преобразуется
все без ограничений;Кодировки, используемые для написания функций защиты
показано в таблице Б.1.
Таблица Б.1 – Кодировки, которые можно использовать для написания
функций защиты от SQLi в свой код при разработке личной веб-системы.
Кодировка
Псевдонимы
Описание
ISO-8859-1
ISO8859-1
Западно-европейская Latin-1.
ISO-8859-5
ISO8859-5
Редко используемая кириллическая
кодировка (Latin/Cyrillic).
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ Б
Продолжение таблицы Б.1
ISO-8859-15
Изм. Лист
№ докум.
ISO8859-15
Подпись Дата
Западно-европейская Latin-9. Добавляет знак евро,
французские и финские буквы к кодировке Latin-1.
ПКИТ 1315000.027-15 ПЗ
Лист
55
8-битная Unicode, совместимая с ASCII.
UTF-8
cp866
ibm866, 866
Кириллическая кодировка, применяемая в DOS.
cp1251
Кириллическая кодировка, применяемая в Windows.
KOI8-R
Windows-1251,
win-1251, 1251
Windows-1252,
1252
koi8-ru, koi8r
BIG5
950
GB2312
936
Традиционный китайский, применяется в основном
на Тайване.
Упрощённый китайский, стандартная национальная
кодировка.
Расширенная Big5, применяемая в Гонконге.
cp1252
BIG5-HKSCS
Shift_JIS
EUC-JP
Западно-европейская кодировка, применяемая в
Windows.
Русская кодировка.
Японская кодировка.
SJIS, SJIS-win,
cp932, 932
EUCJP, eucJPwin
Японская кодировка.
Кодировка, используемая в Mac OS.
Пустая строка активирует режим определения
кодировки из файла скрипта, default_charset и
текущей в указанном порядке. Не рекомендуется к
использованию.
MacRoman
''
Остальные кодировки не поддерживаются, вместо них будет применена
кодировка по умолчанию и сгенерировано предупреждение.
Для функции strip_tags(), можно выделить такие правила как:
1) strip_tags(string $string, array string null $allowed_tags = null): string. Эта
функция всегда пытается возвратить строку, из которой удалены все NULLбайты, HTML-теги и PHP-теги из заданной строки (string). Для удаления тегов
используется тот же механизм fgetss() – удаляет любые NULL-байты, HTMLтеги и PHP-теги из прочитанной строки.
2) allowed_tags параметр нужно использовать для указания тегов, которые
не нужно удалять.
ПРИЛОЖЕНИЕ В
КОНТРОЛЬНЫЙ ПРИМЕР
РЕАЛИЗАЦИИ ПРОЕКТА
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
56
Для получения результата в ходе дипломной работы нужно создать сайт для
демонстрации защиты от SQL-инъекций.
Рисунок А.1 – сайт для показа дипломной работы
Также, необходимо подключиться к базе данных для полноценной работы
сайта.
Рисунок А.2 – База данных phpMyAdmin
Введенный зловредный код для атаки на данный веб-сайт после которого
злоумышленник получает полный доступ к базам данных
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ В
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
57
Рисунок А.3 – Проведение атаки хакером на веб-сайт
Рисунок А.4 – Результат всей проведенной атаки злоумышленником
Рисунок А.5 – Изменение PHP кода
Изменения описанные в главе 2.3.2 позволяют закрыть эту уязвимость и
защитить веб-приложение на PHP при помощи контроля вводимых данных.
ПРИЛОЖЕНИЕ Г
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
58
РУКОВОДСТВО ОПЕРАТОРА СКУД
Для использования функцией защиты необходимо ввести пользователю в
свою разработку сайта код, который препятствует вводу многих знаков, что
запретит ввод посторонних, зловредных знаков для проведения SQL-инъекции
на данном сайте.
Рисунок Г.1 – Пример замещения символов переменной
Использование переменных во вводе исключает попытки SQL-инъекции
в форме ввода.
Рисунок Г.2 – Пример вставки функции защиты htmlspecialchars()
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ Г
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
59
Рисунок Г.3 – Пример правильной вставки функции защиты
htmlentities()
Основной функцией использования функции защиты htmlentities()
является обработка специальных символов в переменных. Двойные кавычки и
одинарные
кавычки,
а
также
другие
специальные
символы
будут
экранироваться против SQL-инъекций и XSS-атак символьного типа.
Все предоставленные функции защиты пишутся в немного отличавшимся
от друг друга виде и с заданными правилами для каждой введенной функции.
Приложение Д. Схема функционирования системы безопасности
(Графический лист формата А4)
Изм. Лист
№ докум.
Подпись Дата
ПКИТ 1315000.027-15 ПЗ
Лист
60