ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 28.04.2024
Просмотров: 88
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Это приведет к тому, что мы увидим информацию из системной таблицы о привилегиях (рис 5.5).
Если вы до сих пор не знали о проблеме SQL-инъекции, то, надеюсь, этим примером я смог вас заинтересовать. Теперь давайте разберемся с проблемой подробнее.
-
Сбор информации
Прежде чем продолжить атаку, хакеру необходимо собрать как можно больше информации о системе, в которую он попал. Желательно получить следующую информацию:
-
Количество колонок, выбираемых запросом, в который мы внедряемся. Как разработчик сценария и таблицы я знал, что в ней 6 колонок и все они выбираются, так что мне не составляло труда эксплуатировать это. -
Какие именно поля отображаются. Тут я тоже знал, что отображаются второе, третье и четвертое поле из выполняемого запроса.
Имея эту информацию, можно его попробовать проникнуть дальше и выяснить имена пользователей в базе данных и пароли.
В этом разделе мы поговорим о том, каким образом можно получить максимально возможную информацию.
Итак, как можно посчитать количество полей? Самый простой способ — объединение union с другим SQL-запросом. Когда два SQL-запроса объединяются через union, то они будут выполнены, только если оба возвращают одинаковое количество полей и типы соответствующих полей имеют совместимый тип.
А с каким SQL-запросом нам произвести объединение? Что он должен возвращать и откуда брать данные? Да ниоткуда и ничего. Он просто должен возвращать нулевое значение. Нулевые значения позволят нам забыть о типах полей. Например, следующий SQL-запрос вполне корректен и возвращает одно пустое значение (null):
SELECT null
Можно возвращать какую-то строку:
SELECT '1'
Что выбрать? Зависит от ситуации. В нашем случае нужно второе. Дело в том, что мы внедряемся в запрос между двумя кавычками:
SELECT * FROM phone WHERE firstname=''
Мы должны передать хотя бы одинарную кавычку и после этого запрос. Если мы передадим:
' union select null то получится:
SELECT * FROM phone WHERE firstname='' union select null'
Но проблема в том, что в конце осталась одна кавычка, которая открыта, но не закрыта. Чтобы от нее избавиться, можно использовать второй подход с выбором строки, то есть передать:
' union select ' 1
что приведет к этому запросу:
SELECT * FROM phone WHERE firstname='' union select '1'
В результате сервер отобразит ошибку:
The used SELECT statements have a different number of columns
что означает — в данном SELECT-запросе используется некорректное число колонок. Это не дословный перевод, но смысл верный.
Значит нам нужно добавить еще колонку
' union select '1', '1
Потом еще:
' union select '1', '1' , '1
И таким образом продолжать добавлять, пока запрос не выполнится. Так как запрос в коде возвращает 6 колонок, то мы добьемся результата, добавив 6 колонок:
' union select '1', '1', '1', '1','1','1
Сообщение об ошибке упростило поиск, но в реальной жизни на большинстве сайтов сообщения об ошибках отключены, и в этом случае можно увидеть два варианта поведения сайта — при ошибке он будет отображать ошибку типа 404 или просто пустую страницу. В любом случае — это признак того, что мы предоставили некорректное количество колонок и нужно увеличивать, пока страница не отобразится с какими-то данными.
Примечание
В SQL-запросе можно вместо пробела указывать знак плюса, например:
union+SELECT+null,+null.
Иногда такая запись запроса более удобна, особенно если пробелы отфильтровываются сценарием.
В некоторых случаях подбор могут упростить символы комментариев — двойное тире или /* на конце. Например, можно попробовать передать:
' union select '1' /*
Это работает не всегда — зависит от кода и базы данных, которые использовались на сервере. Но попробовать использовать символы комментария все же можно, и если они работают, то это упростит жизнь.
А что означает /* на конце? Эти два символа указывают СУБД, что весь последующий текст в SQL-запросе — это комментарий и его выполнять не нужно. Если не указать этого, то СУБД вернет ошибку в любом случае. Почему?
Если после внедрения нашего объединенного SQL-запроса не поставить комментарий в конце, он примет следующий вид:
SELECT *
FROM smf_polls WHERE posterName='' union
SELECT null '
Обратите внимание на одинарную кавычку в конце. Она лишняя, и из-за нее СУБД не сможет выполнить SQL-запрос. Благодаря комментарию мы можем отбросить эту точку:
SELECT *
FROM smf_polls
WHERE posterName='' union SELECT null /* '
Запрос может быть и более сложным:
SELECT *
FROM smf_polls
WHERE posterName='$username' and field2='$param'
ORDER BY posterName LIMIT 0, 25
Тут уже после переменной $username еще очень много операторов, и они также представляют для нас проблему. Символ комментария позволяет отбросить эту часть SQL-запроса.
Все примеры, которые мы рассматривали ранее, подразумевают, что переменная, в которую мы включили SQL-запрос, является строковой. В запросах переменную такого типа необходимо заключать в одинарные кавычки. Если переменная должна быть числовой, то ее заключение в одинарные кавычки не является обязательным. Например:
SELECT *
FROM poll
WHERE pollid = $pollid
В данном случае переменная $pollid не заключается в кавычки, а значит, кавычку не нужно передавать в качестве параметра. Достаточно просто передать вставку SQL-запроса.
Помимо стандартных SQL-запросов select каждая СУБД поддерживает свои расширения, с помощью которых можно получить подробную информацию об объектах базы данных. Позже мы обсудим нюансы сбора информации в Microsoft SQL Server, а в этой главе мы говорим о связке PHP + MySQL, и значит, рассматриваем именно MySQL.
Начнем с оператора SHOW. Он имеет несколько вариантов, и первый из них, который мы рассмотрим, будет отображать доступные базы данных. Для этого необходимо выполнить оператор show databases. В результате на экране будут отображены имеющиеся базы данных:
WEB'CEPBEP 1
глазами 1
1 ... 7 8 9 10 11 12 13 14 ... 18
Оглавление 4
Введение 8
Основы безопасности 12
1.3.1.Определение типа операционной системы 19
1.3.2.Определение имен работающих служб 20
1.3.3.Используемые фреймворки 24
1.3.4.Использование эксплоитов 28
1.3.5.Автоматизация 29
1.4.1.Анализатор web-уязвимостей 33
1.4.2.Взлом с помощью поисковой системы 36
1.7.1.Distributed Denial of Service (DDoS) 46
1.7.2.Защита от распределенной атаки 47
1.8.1.Защита web-сервера 49
1.8.2.Модули безопасности Apache 50
1.9.1.Права сценариев web-сервера 52
1.9.2.Права системных сценариев 53
1.9.3.Права доступа к СУБД 54
1.11.1.Самостоятельно написанные программы 58
1.11.2.Готовые решения 59
1.11.3.Программы, написанные под заказ 60
1.11.4.Золотая середина 60
Простые методы взлома 64
2.1.1.Вариант накрутки № 1 64
2.1.2.Вариант накрутки № 2 65
2.1.3.Вариант накрутки № 3 66
2.1.4.Защита от накрутки 67
2.3.1.Внутренний мир каптчи 71
2.3.2.Примеры некорректных каптчей 73
2.3.3.Пример хорошей каптчи 74
Взлом PHP-сценариев 80
3.1.1.Пример реальной ошибки 80
3.1.2.Проблема include 85
3.1.3.Инъекция кода 89
3.2.1.Лишние сценарии на рабочем сервере 91
3.2.2.Дополнительные программы 91
3.2.3.Резервные копии или старые файлы 92
3.3.1.Метод GET 96
3.3.2.Метод POST 98
3.3.3.Уязвимость 101
3.3.4.Другие методы 103
3.3.5.Инициализация переменных 104
3.4.1.Конфигурационные файлы 110
3.4.2.Промежуточные модули 113
3.4.3.Скрытые функции 116
3.9.1.Воровство кликов 125
3.9.2.Cross Frame Scripting 125
3.9.3.Защита от фреймов 126
Работа 130
с системными командами 130
• • • 131
4.3.1.Проверка корректности файлов изображений 142
4.3.2.Проверка корректности текстовых файлов 144
4.3.3.Сохранение файлов в базе данных 145
4.3.4.Обращение к файловой системе 145
4.3.5.Угроза безопасности 148
SQL-инъекция (PHP + MySQL) 149
5.2.1.Сбор информации 156
5.2.2.Использование уязвимости 170
5.2.3.Доступ к файловой системе 172
5.2.4.Поиск уязвимости 172
5.2.5.Процент опасности 173
5.2.6.Возможные проблемы 176
5.2.7.От теории к практике 178
SQL-инъекция .NET + MS SQL Server 181
6.1.1.Опасные процедуры MS SQL Server 181
6.1.2.Распределение прав доступа 184
6.1.3.Опасные SQL-запросы 186
6.1.4.Рекомендации по безопасности MS SQL Server 187
CSRF, или XSRF-уязвимость 192
DoS-атака на web-сайт 201
8.2.1.Оптимизация SQL-запросов 202
8.2.2.Оптимизация базы данных 208
8.2.3.Выборка необходимых данных 211
8.2.4.Резюме 212
8.3.1.Кеширование вывода 213
8.3.2.Кеширование web-страниц 214
8.3.3.Программные решения 216
8.3.4.Медленный код 217
8.3.5.Асинхронный код 218
Авторизация 226
XSS 239
Заключение 251
Предметный указатель 253
На моем сервере несколько баз данных. Первая из них является системной. В ней хранятся системные таблицы, которые могут сообщить хакеру достаточно ценную информацию о базе данных и ее содержимом.
Для просмотра таблиц в текущей базе данных необходимо выполнить оператор show tables. Если выполнить эту команду в базе данных mysql, то вы увидите примерно следующий результат:
WEB'CEPBEP 1
глазами 1
Оглавление 4
Введение 8
Основы безопасности 12
1.3.1.Определение типа операционной системы 19
1.3.2.Определение имен работающих служб 20
1.3.3.Используемые фреймворки 24
1.3.4.Использование эксплоитов 28
1.3.5.Автоматизация 29
1.4.1.Анализатор web-уязвимостей 33
1.4.2.Взлом с помощью поисковой системы 36
1.7.1.Distributed Denial of Service (DDoS) 46
1.7.2.Защита от распределенной атаки 47
1.8.1.Защита web-сервера 49
1.8.2.Модули безопасности Apache 50
1.9.1.Права сценариев web-сервера 52
1.9.2.Права системных сценариев 53
1.9.3.Права доступа к СУБД 54
1.11.1.Самостоятельно написанные программы 58
1.11.2.Готовые решения 59
1.11.3.Программы, написанные под заказ 60
1.11.4.Золотая середина 60
Простые методы взлома 64
2.1.1.Вариант накрутки № 1 64
2.1.2.Вариант накрутки № 2 65
2.1.3.Вариант накрутки № 3 66
2.1.4.Защита от накрутки 67
2.3.1.Внутренний мир каптчи 71
2.3.2.Примеры некорректных каптчей 73
2.3.3.Пример хорошей каптчи 74
Взлом PHP-сценариев 80
3.1.1.Пример реальной ошибки 80
3.1.2.Проблема include 85
3.1.3.Инъекция кода 89
3.2.1.Лишние сценарии на рабочем сервере 91
3.2.2.Дополнительные программы 91
3.2.3.Резервные копии или старые файлы 92
3.3.1.Метод GET 96
3.3.2.Метод POST 98
3.3.3.Уязвимость 101
3.3.4.Другие методы 103
3.3.5.Инициализация переменных 104
3.4.1.Конфигурационные файлы 110
3.4.2.Промежуточные модули 113
3.4.3.Скрытые функции 116
3.9.1.Воровство кликов 125
3.9.2.Cross Frame Scripting 125
3.9.3.Защита от фреймов 126
Работа 130
с системными командами 130
• • • 131
4.3.1.Проверка корректности файлов изображений 142
4.3.2.Проверка корректности текстовых файлов 144
4.3.3.Сохранение файлов в базе данных 145
4.3.4.Обращение к файловой системе 145
4.3.5.Угроза безопасности 148
SQL-инъекция (PHP + MySQL) 149
5.2.1.Сбор информации 156
5.2.2.Использование уязвимости 170
5.2.3.Доступ к файловой системе 172
5.2.4.Поиск уязвимости 172
5.2.5.Процент опасности 173
5.2.6.Возможные проблемы 176
5.2.7.От теории к практике 178
SQL-инъекция .NET + MS SQL Server 181
6.1.1.Опасные процедуры MS SQL Server 181
6.1.2.Распределение прав доступа 184
6.1.3.Опасные SQL-запросы 186
6.1.4.Рекомендации по безопасности MS SQL Server 187
CSRF, или XSRF-уязвимость 192
DoS-атака на web-сайт 201
8.2.1.Оптимизация SQL-запросов 202
8.2.2.Оптимизация базы данных 208
8.2.3.Выборка необходимых данных 211
8.2.4.Резюме 212
8.3.1.Кеширование вывода 213
8.3.2.Кеширование web-страниц 214
8.3.3.Программные решения 216
8.3.4.Медленный код 217
8.3.5.Асинхронный код 218
Авторизация 226
XSS 239
Заключение 251
Предметный указатель 253