Проверка системы управления содержимым на SQL уязвимости

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ПОВОЛЖСКИЙ Государственный Технический Университет

Пояснительная записка

«Методы и средства создания угроз информационной безопасности»

на тему Проверка системы управления содержимым на SQL уязвимости

Выполнил:

Скворцова А.С.

Проверил:

Кречетов А.А.

Йошкар-Ола 2015

Содержание

Введение

1. Теоретическая часть

1.1 Из чего состоит запрос

1.2 Примеры

1.3 Защита

2. Практическая часть

3. Потенциальные уязвимости

Заключение

Введение

Многие веб-разработчики даже не догадываются, что SQL-запросы могут быть подделаны, и считают, что SQL-запросы всегда достоверны. На самом деле поддельные запросы могут обойти ограничения доступа, стандартную проверку авторизации, а некоторые виды запросов могут дать возможность выполнять команды операционной системы.

Прямое внедрение вредоносных инструкций в SQL-запросы - это методика, в которой взломщик создает или изменяет текущие SQL-запросы для отображения скрытых данных, их изменения или даже выполнения опасных команд операционной системы на сервере базы данных. Атака выполняется на базе приложения, строящего SQL-запросы из пользовательского ввода и статических параметров. Следующие примеры, к сожалению, построены на реальных фактах.

Благодаря отсутствию проверки пользовательского ввода и соединению с базой данных под учетной записью суперпользователя (или любого другого пользователя, наделенного соответствующими привилегиями), взломщик может создать еще одного пользователя БД с правами суперпользователя.

1. Теоретическая часть

1.1 Из чего состоит запрос

SQL injection -- одна из самых опасных уязвимостей веб-приложений. Позволяет злоумышленнику выполнять запросы в БД сайта, а в некоторых случаях писать/читать файловую систему с правами сервера баз данных.

Любой запрос SQL состоит из нескольких предложений.

SELECT *

FROM base_user

Это пример самого простого запроса, который состоит из двух предложений: предложение SELECT и предложение FROM. Для выбора по условию к запросу добавляется предложение WHERE. В нем обычно и скрываются неприятности.

SELECT *

FROM base_user

WHERE id=1

В MySQL литеральные строки заключаются в двойные или одинарные кавычки. Комментарии пишутся после - или /*. Первый вид комментария -- комментарий до конца строки, второй -- до символов */, по аналогии с С++ или до конца многострочного запроса.

Также стоит упомянуть про объединение результатов запроса с использованием оператора UNION.

SELECT name

FROM A

WHERE id=1

UNION

SELECT name

FROM B

WHERE id=2

Оператор UNION эквивалентен теоретико-множественному оператору объединения множеств. Работает только с запросами на выборку, необходимо одинаковое количество выбираемых полей в предложении SELECT для обоих объединяемых запросов.

Начиная с 5-й версии, MySQL поддерживает написание подзапросов, которые заключаются в круглые скобки ().

1.2 Примеры

Целые числа

$id = $_GET['id'];

mysql_query("SELECT * FROM base_user WHERE id=" . $id);

Данный пример собирает запрос, подобное можно встретить во множестве сайтов. Как видно, в запрос просто подставляется значение ячейки суперглобального массива $_GET.

Переменная id никак не фильтруется, то есть в GET-запрос можно вписать все что угодно.

Сначала узнаем количество полей возвращаемых запросом, для этого начинаем угадывать количество столбцов.

После определения количества столбцов можно узнать, например, версию сервера. Составляем запрос вида:

Дальше, можно набрести на системные таблицы INFORMATION_SCHEMA и на БД mysql. Если сервер настроен плохо, то можно надеятся на права чтения этих таблиц и баз данных. Для выполнения запроса к другой базе данных достаточно поставить ее имя перед именем таблицы и поставить “.”(точка) между именем БД и таблицей.

Пример:

mysql.user

Имея доступ к INFORMATION_SCHEMA, злоумышленник легко узнает количество, имена и структуры всех таблиц БД.

Сервер MySQL имеет очень удобное предложение запроса на выборку INTO OUTFILE.

Запрос такого вида позволит записать результат запроса в файл. Хоть эта возможность встречается не так часто, но с ее помощью на сервер можно загружать любые файлы.

Чтение файловой системы. LOAD DATA INFILE '/tmp/test.txt' INTO TABLE test

Запрос загружает содержимое фала в таблицу базы данных. С этим типом запросов возникают некоторые трудности при его инъекции в другие запросы, но в этом случае можно используется построение подзапросов.

Литералы

$name = $_GET['name'];

mysql_query("SELECT * FROM base_user WHERE name='" . $name . "'");

Этот код безопаснее предыдущего, но только в том случае, если в настройках PHP включены magic_quotes. При включении magic_quotes во всем вводе экранируются кавычки. Если же “волшебные кавычки” отключены, то запрос строится по принципу как и с целочисленными данными, только закрывается открытая кавычка

В итоге, вместо

SELECT * FROM base_user WHERE name='TEST'

получаем

SELECT * FROM base_user WHERE name='TEST' UNION SELECT 1,2,3/*

1.3 Защита

Существуют разные способы защиты от инъекции, но в основе каждого лежит правильная и хорошая фильтрация пользовательского ввода. Данные к веб-приложениям поступают из массивов GET, POST и из COOKIE. Любой из массивов может быть преднамеренно изменен. Необходимо контролировать типы входящих значений.

Нужно численные значения преобразовывать к численным посредством intval(), floatval() и тп.

$a = intval($_GET['a']);

Это уже не позволит вместо $а вписать какой-то запрос. Следует отметить, что intval() нельзя использовать при проверке число или нет в переменной. Intval() возвращает 1 при непустых значениях параметра любого не числового типа. Для проверки на число лучше использовать is_numeric().

Для строковых значений следует использовать addslashes(), которая экранирует все кавычки символом \. А еще лучше html_entities() для кодирования символов сущностями html(" и т.п.).

Как видно, доступ к чтению БД очень опасен. При использовании PHP и глобальных массивов стоит быть очень осторожным. Следует с ответственностью относится к настройке прав пользователей базы, запрещать чтение INFORMATION_SCHEMA и базу данных mysql. Необходимо фильтровать все входные данные. На сайтах стоит отключать error_reporting и дамп ошибок БД в браузер.

2. Практическая часть

В данном курсовом проекте производится аудит "Системы управления сайтами NetCat 3.0 Extra". Была загружена Demo-версия данной CMS и установлен полный комплект дистрибутива. Все файлы NetCat закодированы с использованием Zend. Но эта защита ненадежна, так как их можно просто раскодировать с помощью комплекта "dezend". Это первая уязвимость. Для облегчения работы был включен отладочный режим. Отключаем magic_quotes_gpc - это процесс автоматического экранирования входящих данных PHP-скрипта. вредоносный фильтрация пользовательский код

Рис.1.

Желательно отключать директиву magic quotes и вместо этого экранировать данные в процессе разработки, если это необходимо. Отключаем его путем удаления соответствующих строк из .htaccess, расположенного в корневой директории web-сервера. (php_flag magic_quotes_gpc Off). Магические кавычки также включены в конфигурационном файле /netcat/vars.inc.php, поэтому сбрасываем его значение в ноль и в этом файле. Там же переопределяем переменную "$SHOW_MYSQL_ERRORS" в значение "On". Остался еще файл php.ini, в котором переопределяем значения "display_errors" и "display_startup_errors" в значение "On", и меняем "error_reporting" в "E_ALL & ~E_NOTICE". Перезапускаем демон apache. Отображаем в браузере все запросы, поступающие к БД MySQL. Этого можно добиться путем вставки "echo "$query<br>";" в файл sql_mysql.php в функцию "query{}". Тогда все запросы, поступающие к БД, будут отображаться в браузере. Проверяем самую распространенную SQL инъекцию (Blind SQL Injection - "Слепое выполнение произвольных SQL-запросов"). На запрос вида "/about/=1'" браузер выдал "You have an error in your SQL syntax". Это вторая уязвимость. Техника эксплуатации подобных уязвимостей отработана и заключается в том, что на основе логического выражения нужно определить истинность какого-либо запроса, передаваемого в БД.

Например, на запрос:

/about/=1'/**/OR/**/EnglishName='profile'/**/AND/**/1=1

web-сервер в данном случае ответит "HTTP 302 Found", и это будет означать

TRUE, а на запрос /about/=1'/**/OR/**/EnglishName='profile'/**/AND/**/1=2

web-сервер ответит: "HTTP 404 Not Found", что будет означать FALSE. Используя конструкции вида if(), ascii(), substring((SELECT…)) или LIKE, становится возможным получить любую информацию в пространстве БД, к которой есть доступ в соответствии с ACL. Можно даже читать произвольные файлы, если у пользователя БД есть разрешение File_priv, а также заливать web-shell, если не экранируются кавычки.

3. Потенциальные уязвимости

Для автоматизированного анализа исходного кода существует огромное число инструментов, позволяющих за короткое время выявить потенциальные уязвимости путем разбора кода. Разделяют два подхода к анализу - динамический и статический. Большее распространение получили именно статистические анализаторы (благодаря простоте реализации). Такой инструментарий можно найти под все распространенные языки программирования, в том числе под PHP.

Такой анализ в ряде случаев выдает огромное число false positive либо вообще не находит ни одной уязвимости в коде, который может быть просто наполнен различными недоработками. В связи с этим подход методом статического анализа исходного кода применяется больше как вспомогательный при ручном анализе кода. Более эффективны динамические анализаторы. Таких продуктов не так уж и много в силу их сложности (одну и ту же операцию можно выполнить бесконечным числом вариаций, поэтому такие анализаторы должны хорошо уметь парсить синтаксис языка). А цена по причине ограниченного круга потребителей достаточно высока. Как следствие, в Сети подобные инструменты просто так трудно найти.

Стоит отметить, что и динамические анализаторы кода могут не заметить логическую уязвимость, присутствующую в приложении. Например, уязвимости типа "Предсказуемое значение идентификатора сессии" (Credential/Session Prediction) или "Небезопасное восстановление паролей" (Weak Password Recovery Validation) будут пропущены. За неимением инструментов динамического анализа исходных текстов приходится пользоваться статическими анализаторами. Для этих целей необязательно использовать чужую разработку, можно использовать grep/egrep. Используя язык регулярных выражений, можно найти ряд уязвимостей разного уровня критичности по сигнатурному принципу.

Например, конструкция "grep -R -i "header[ (]" * | grep -i Location | grep "\$"" покажет потенциальные уязвимости "Расщепление HTTP-запроса", которые могут существовать при передаче необработанных данных функции header(). Использование этой уязвимости пригодится в проведении фишинг-атак и различных атак на браузер пользователя. Набор сигнатур ("='\"\.\$_", "=\"\./<?=(isset(\$_" и т.д.) позволяет легко искать уязвимости типа "Межсайтовое выполнение сценариев". Ручная проверка подтверждает присутствие уязвимостей в ряде случаев. Так, сформировав запрос вида "/netcat/modules/netshop/post.php?system=../../../../.htaccess%00", можно получить содержимое файла .htaccess, расположенного в корневой директории web-сервера.

Все выявленные уязвимости сигнатурным поиском сорцов NetCat попадали либо под client-side уязвимости, либо для их эксплуатации требовалось использование кавычек.

Заключение

Внедрение SQL-кода -- один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода. Внедрение SQL, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере.

Атака типа внедрения SQL может быть возможна из-за некорректной обработки входных данных, используемых в SQL-запросах. Разработчик прикладных программ, работающих с базами данных, должен знать о таких уязвимостях и принимать меры противодействия внедрению SQL.

Размещено на Allbest.ru