WEb практикум. Web'cepbep

Название	Web'cepbep
Анкор	WEb практикум
Дата	22.01.2023
Размер	4.76 Mb.
Формат файла
Имя файла	WEB.docx
Тип	Документы #898678
страница	12 из 18

1 ... 8 9 10 11 12 13 14 15 ... 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

Я показал не все таблицы, а только несколько для примера, и самая интересная из них — это user. Если у вас есть под рукой СУБД MySQL, то выполните SQL-запрос:

SELECT *

FROM mysql.user

Данный SQL-запрос выбирает все записи из таблицы user базы данных mysql. В этой таблице хранятся имена пользователей, их зашифрованные пароли, а также права доступа для каждого пользователя. Если у вас такой базы данных нет, то ничего страшного, мы рассмотрим основные поля этой таблицы:

Host — имя хоста;
User — имя пользователя;
Password — зашифрованный пароль пользователя;
Select_priv — если в этой колонке Y, то пользователю разрешено выполнять оператор sELECT;

Insert_priv — если в этой колонке Y, то пользователю разрешено вставлять новые записи, то есть выполнять оператор insert;
Update_priv — если в этой колонке Y, то пользователю разрешено обновлять данные, то есть выполнять оператор update;
Delete_priv — если в этой колонке Y, то пользователю разрешено удалять данные, то есть выполнять оператор delete;
Create_priv — если в этой колонке Y, то пользователю разрешено создавать новые таблицы или базу данных, то есть выполнять оператор create table;
Drop_priv — если в этой колонке Y, то пользователю разрешено удалять таблицы или базу данных, то есть выполнять оператор drop table;
Grant_priv — если в этой колонке Y, то пользователю разрешено управлять правами доступа, то есть выполнять операторы grant и deny;
File_priv — если в этой колонке Y, то пользователю разрешено получать доступ к файловой системе с помощью операторов select into outfile и load data infile;
Index_priv — если в этой колонке y, то пользователю разрешено управлять индексами: создавать и удалять;
shutdown_priv — если в этой колонке Y, то пользователю разрешено останавливать работу сервера;
Process_priv — если в этой колонке Y, то пользователю разрешено управлять процессами сервера;
Alter_priv — если в этой колонке Y, то пользователю разрешено изменять структуру таблицы, то есть выполнять оператор alter.

Если вы хотите просмотреть права доступа пользователя root, то выполните следующий SQL-запрос:

SELECT *

FROM mysql.user

WHERE User='root'

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

Следующий SQL-запрос добавляет нового пользователя, которому доступны все привилегии:

INSERT INTO user

VALUES ('%', 'hacker', password('mypass'), 'Y', 'Y',

'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y')

Если добавление новых записей недоступно, зато доступно обновление, то хакер может изменить существующую учетную запись, изменить ее пароль или права:

UPDATE user SET Drop_priv='Y'

WHERE user='hacker'

Чаще всего добавление все же доступно, тут не должно возникнуть проблем.

Следующая таблица, которая позволяет управлять правами, — это db. Если в таблице user содержатся права доступа ко всем базам данных, то в db — только к определенной. Для чтения данных из таблицы выполняем SQL-запрос:

SELECT *

FROM mysql.user

В этой таблице можно найти следующие поля:

Host — имя хоста;
db — база данных;
User — имя пользователя;
Select_priv — если в этой колонке Y, то пользователю разрешено выполнять оператор SELECT;
Insert_priv — если в этой колонке Y, то пользователю разрешено вставлять новые записи, то есть выполнять оператор insert;
Update_priv — если в этой колонке Y, то пользователю разрешено обновлять данные, то есть выполнять оператор UPDATE;
Delete_priv — если в этой колонке Y, то пользователю разрешено удалять данные, то есть выполнять оператор DELETE;
Create_priv — если в этой колонке Y, то пользователю разрешено создавать новые таблицы или базу данных, то есть выполнять оператор create table;
Drop_priv — если в этой колонке Y, то пользователю разрешено удалять таблицы или базу данных, то есть выполнять оператор DROP TABLE;
Grant_priv — если в этой колонке Y, то пользователю разрешено управлять правами доступа, то есть выполнять операторы GRANT и DENY;
Alter_priv — если в этой колонке Y, то пользователю разрешено изменять структуру таблицы, то есть выполнять оператор alter.

Как видите, здесь хранятся права, которые относятся только к данным. Права управления сервером доступны лишь в таблице user.

Права доступа могут быть назначены и на определенную таблицу. Эти права можно найти в системной таблице mysql. table_priv. Возможны права даже на определенные колонки, и эти права доступа есть в mysql. column_priv.

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

Есть еще три очень интересные функции:

database () — возвращает имя базы данных;
user () — возвращает имя текущего пользователя;
version () — возвращает версию базы данных.

Попробуйте выполнить следующий SQL-запрос:

SELECT DATABASE(), USER(), VERSION()

Вы увидите примерно такой результат:

1 row in set (0.00 sec)

Использование уязвимости

В зависимости от того, сколько информации вы получили, можно воспользоваться найденной уязвимостью. Давайте рассмотрим классические варианты, которые встречаются достаточно часто.

Самое страшное, что может сделать хакер, — уничтожить данные. Дело в том, что база данных способна работать под учетной записью, которая может позволять выполнять команды модификации данных. Если СУБД будет позволять еще и выполнять несколько команд в SQL-запросе, то это может оказаться плачевным. В большинстве баз данных запросы должны разделяться точкой с запятой. В этом случае хакеру достаточно передать через уязвимый параметр следующую команду:

'; DROP TABLE Имя таблицы; /*

Если комментарии недоступны, то можно попробовать выполнить:

' ; DROP TABLE City ;

Все, что после последней точки с запятой может быть проигнорировано базой данных, по крайней мере MySQL игнорирует.

Эта команда удаляет указанную таблицу. Таким образом, можно распрощаться с таблицей и всеми ее данными. Хакеру только нужно знать имя таблицы, которую он хочет удалить, и иметь соответствующие права.

Хорошие администраторы запрещают выполнение команды удаления баз данных и таблиц. Но запретить вставку, обновление и удаление данных из таблиц очень часто невозможно.

'; DELETE FROM Имя таблицы; /*

Если комментарии приводят к тому, что запрос перестает выполняться, то можно попробовать использовать что-то типа:

' ; delete from City where 1='1

Для выполнения этого запроса опять же необходимо знать имя таблицы и иметь права на выполнение запроса delete. Если drop table достаточно просто запретить, то команда DELETE очень часто необходима сценариям. Дело в том, что код сайта, с которым работаем мы, и код сайта, который использует в своей работе администратор, — чаще всего работает от одной и той же учетной записи. И если простым пользователям обычно не нужна опция удаления, то администраторам она очень часто необходима.

Зная поля таблицы, вы можете выполнять команды update для изменения данных или insert для добавления новых записей. Команда изменения данных так же опасна, как и удаление. Например, хакер может внедрить следующий SQL-запрос:

UPDATE user SET password = ''

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

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

Доступ к файловой системе

С помощью SQL-запросов можно получить даже доступ к файловой системе. Для этого в MySQL есть два оператора: load_file и into outfile. С помощью первого можно прочитать файл, например:

hacker' union select null,LOAD_FILE('/etc/passwd'), null,null,null,null,null,null,null/*

В результате будет выполнен следующий SQL-запрос:

SELECT *

FROM smf_polls

WHERE posterName=' hacker' union select

null,LOAD_FILE('/etc/passwd') ,

null,null,null,null,null,null,null/*'

В данном случае результат нормального SQL-запроса select объединяется с SQL-запросом, который во втором параметре (там, где должен быть вопрос голосования) загружает файл /etc/passwd.

Запись в файл происходит следующим образом:

hacker' union select null,null,null,null,null,null,null,null,null from sfm_polls into outfile index.php/*

Таким образом, результат SQL-запроса будет записан в файл index.php. Чаще всего у учетной записи, под которой вы работаете, достаточно прав, чтобы перезаписать этот файл, а значит, вы сможете произвести дефейс (deface) — перезаписав файл index.php, изменить его содержимое.

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

hacker' union select null,'', null,null,null,null,null,null,null from sfm_polls into outfile cmd.php/*

В данном случае в файл cmd.php будет записан результат выполнения запроса и PHP-оператор .

Теперь можно вызывать этот сценарий и в параметре $cmd передавать команды, которые будут выполняться, например: http://localhost/cmd.php?cmd=ls -al. В итоге web-сервер выполнит команду ls -al и отобразит результат ее выполнения.

Поиск уязвимости

Итак, как вы можете искать уязвимости на web-сайте? Самый рабочий способ — во всех параметрах, которые вы видите в строке URL, в полях ввода и в файле cookies, попытаться указать символ одинарной кавычки. Например, если URL выглядит следующим образом: http://localhost/index.php?id=1&s=test, то можно попытаться указать: http://localhost/index.php?id=1'&s=test\

Если сценарий вернет ошибку, то это уже говорит о возможности реализовать атаку SQL-инъекции. Как мы уже знаем, по ошибке можно определить достаточно много полезной информации, в том числе и выполняемый сценарием запрос, имя таблицы и ее поля.

На профессиональных web-сайтах, которые обслуживают опытные администраторы и программисты, вы не увидите ошибок на странице. Все прекрасно понимают, что такие ошибки дают хакеру слишком много информации, поэтому, получая некорректные параметры, сценарий просто может прерывать свою работу, отображая пустую web-страницу или web-страницу, на которой находится только шапка web- сайта. Если вы увидели пустую web-страницу, то это абсолютно ни о чем не говорит. Возможно, там есть ошибка, а может быть, ее там и нет.

Чтобы убедиться в наличии возможности реализации ошибки, в качестве контрольного выстрела можно попытаться выполнить следующие два запроса:

http://localhost/mdex.php?id=1' and 1=1&s=test’ and 1=1 и http://localhost/index.php?id=1 and 1=1&s=test’ and 1=1.

В обоих случаях помимо кавычки мы передаем условие "and 1=1", которое возвращает положительный результат, а значит, SQL-запрос с нашей инъекцией должен положительно выполниться. Если после этого web-страница отобразится корректно, то это уже говорит о возможности удачной атаки и о правильном направлении. Если web-страница отобразится пустой, то ошибки, скорее всего, нет.

Обратите внимание, что в первом случае в параметре id мы передаем кавычку, а во втором — нет. Дело в том, что этот параметр явно числовой, а значит, в запросе он может быть окружен одинарной кавычкой, а может и нет. Необходимо проверить оба варианта.

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

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

Процент опасности

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

SELECT * FROM smf_polls WHERE posterName LIKE '$username'

Символ подчеркивания означает любой одиночный символ. Например, вы не знаете, как правильно написано имя Михаил на английском — Michael или Mikhail. В обоих случаях семь букв и имя начинается с букв Mi, а заканчивается на букву l. В этом случае символы, которые вы знаете точно, можно написать в тех позициях, которые есть, а неизвестные символы можно заменить подчеркиванием:

M i _ _ _ _ l

Пробелы в данном случае введены только для того, чтобы вы видели границы символов. В реальных условиях это не нужно. Если передать в качестве параметра эту строку, то в результате база данных вернет нам записи, в которых есть как Mikhail, так и Michael.

Символ процента заменяет последовательность из любых символов. Это значит, что проблему имени Михаил можно решить следующим образом:

M i % l

Результат будет тем же самым, и база данных вернет нам записи, в которых есть как Mikhail, так и Michael. Если в качестве параметра просто передать символ процента, то в результате мы получим абсолютно все записи таблицы.

Как эти символы могут использовать хакеры? Допустим, что у вас есть таблица users, в которой хранятся имена учетных записей всех пользователей web-сайта. Для входа на web-сайт пользователь вводит имя пользователя и пароль, а ваш сценарий должен проверить, есть ли такой пользователь в таблице. Вероятная проверка может выглядеть следующим образом:

$sql = "SELECT * FROM user WHERE username like '". $_POST['username'] .

"' AND password like '". $_POST['password'] . "'";

$query = $connection->prepare($sql);

$query->execute();

if ($query->rowCount() > 0) {

echo "

1 ... 8 9 10 11 12 13 14 15 ... 18