История

Сергей Филатов dd5a319b14 Изменил(а) на 'labs/lab3/README.md'		4 дней назад
..
assets	Удалить 'labs/lab3/assets/L3_36.jpg'	4 дней назад
README.md	Изменил(а) на 'labs/lab3/README.md'	4 дней назад

README.md

Лабораторная работа 3

Выполнение лабораторной работы

Подключение к серверу

Для части лабораторной работы используется специальный тестовый сайт:

10.5.143.101:PORT

Где порт (PORT) у каждого студента индивидуальный:

А-01м-24

№	Студент	Порт
1	Агеева Юлия Михайловна	3101
2	Баутин Алексей Николаевич	3102
3	Булатников Александр Николаевич	3103
4	Гребенева Юлия Игоревна	3104
5	Дашин Илья Николаевич	3105
6	Жильцов Александр Иванович	3106
7	Иванов Олег Борисович	3107
8	Калясов Тимур Маратович	3108
9	Львов Михаил Дмитриевич	3109
10	Минасян Артём Акопович	3110
11	Подлубный Андрей Юрьевич	3111
12	Рымарева Татьяна Алексеевна	3112
13	Сыропятов Вячеслав Владимирович	3113
14	Яковлева Альбина Леонидовна	3114

А-02м-24

№	Студент	Порт
1	Аношкин Данила Викторович	3201
2	Болотникова Алёна Алексеевна	3202
3	Ванина Александра Юрьевна	3203
4	Волобуева Валентина Андреевна	3204
5	Газтдинов Рамиль Рафилович	3205
6	Ефимов Кирилл Алексеевич	3206
7	Иванов Андрей Сергеевич	3207
8	Иванова Вероника Александровна	3208
9	Киселев Семён Игоревич	3209
10	Панжуков Михаил Дмитриевич	3210
11	Поташов Сергей Евгеньевич	3211
12	Тюрин Егор Олегович	3212

Несанкционированный поиск и использование уязвимостей Web-приложений запрещены законодательством (ст. 272 УК РФ)

Требования к отчёту:

Формат отчёта DOCX
Название отчёта должно содержать номер группы (А1 или А2), фамилию и номер лабораторной работы (Л3): А1 Иванов ИБ Л3.docx
Содержание отчёта:
- Титульный лист
- Описание проделанной работы и вводимых команд
- Скриншоты результатов выполнения и их описание
- Вывод

Цель работы

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

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

На сегодняшний день по данным исследований, около 70% процентов сайтов содержат хотя бы одну уязвимость критического уровня. В компьютерной безопасности термин «уязвимость» (англ. vulnerability) используется для обозначения недостатка в системе, используя который можно намеренно нарушить её целостность и вызвать неправильную работу. Уязвимость может быть результатом ошибок программирования, недостатков, допущенных при проектировании системы, ненадежных паролей, вирусов и других вредоносных программ, скриптовых и SQL-инъекций. Некоторые уязвимости известны только теоретически, другие же активно используются и имеют известные эксплойты.

Обычно уязвимость позволяет атакующему «обмануть» приложение — заставить его совершить действие, на которое у того не должно быть прав. Это делается путём внедрения каким-либо образом в программу данных или кода в такие места, что программа воспримет их как «свои».

1.1. OWASP

Open Web Application Security Project (OWASP) — это открытый проект обеспечения безопасности веб-приложений. Сообщество OWASP включает в себя корпорации, образовательные организации и частных лиц со всего мира. Сообщество работает над созданием статей, учебных пособий, документации, инструментов и технологий, находящихся в свободном доступе.

Раз в несколько лет OWASP публикует рейтинг наиболее популярных уязвимостей в Web-приложениях, который называется OWASP Top 10. На данный момент список выглядит следующим образом:

A1 Внедрение кода
A2 Некорректная аутентификация и управление сессией
A3 Межсайтовый скриптинг (XSS)
A4 Нарушение контроля доступа
A5 Небезопасная конфигурация
A6 Утечка чувствительных данных
A7 Недостаточная защита от атак
A8 Подделка межсайтовых запросов (CSRF)
A9 Использование компонентов с известными уязвимостями
A10 Незащищенный API

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

1.2. Внедрение кода (SQL Injection)

Все данные, как правило, хранятся в специальных базах, обращения к которым строятся в виде запросов, чаще всего написанных на специальном языке запросов SQL (Structured Query Language – структурированный язык запросов). Приложения используют SQL-запросы для того, чтобы получать, добавлять, изменять или удалять данные, например при редактировании пользователем своих личных данных или заполнении анкеты на сайте. При недостаточной проверке данных от пользователя, злоумышленник может внедрить в форму Web-интерфейса приложения специальный код, содержащий кусок SQL-запроса.

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

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

В целом эта разновидность атак имеет общее название «Ошибки валидации», к ней относятся далеко не только SQL-инъекции и мы будем упоминать этот вектор еще не раз.

Пользователь переходит по ссылке, передавая определённые параметры

Сервер обрабатывает параметры, формирует SQL-запрос и отправляет его в базу данных

База данных возвращает результат и сервер использует \ти данные в формировании страницы

Что произойдёт, если в параметре передать строку, содержащую специальные символы, дополняющие SQL-запрос?

Сервер обработает эти данные, подставит их в запрос и, если запрос валидный, выполнит запрос

Дальше данные обработаются и вернутся на страницу пользователя

Различают несколько видов SQL-инъекций:

Внедрение операторов SQL (SQL Injection)
Слепое внедрение операторов SQL (Blind SQL Injection)

Дополнительные материалы по атакам инъекции SQL

Изложение технологии инъекции кода SQL [https://www.dofactory.com/sql/injection]
Учебный сайт с уязвимостями SQL инъекций: [https://redtiger.labs.overthewire.org]
Сайт с объяснением, как внедрять инъекции в учебный сайт: [https://aayushmalla56.medium.com/sql-injection-redtigers-hackit-4f7b9399f1b0]

1.3. Межсайтовый скриптинг (XSS)

Межсайтовое выполнение сценариев (Cross site scripting или XSS) – это возможность вставки HTML/JavaScript – кода в уязвимую страницу. Инъекция кода осуществляется через все доступные способы ввода информации: в полях пользовательского ввода, именах загружаемых файлов, параметрах HTTP запроса и т.п. Успешное завершение атаки может привести к использованию значений различных переменных, доступных в контексте сайта, записи информации, перехвату пользовательских сессий, данных и т.д. Cross-Site Scripting (XSS) – Это уязвимость на стороне клиента.

Условно Cross-Site Scripting (XSS) делят на:

Сохраненный вариант (Persistent / Stored)
Отраженный вариант (non-persistent / reflected)

Как это работает:

Пользователь вводит на Web-сайте в строке поиска слово “secureweb”.

Web-сервер отображает введенную поисковую фразу на странице так, как она была введена в поле

Обнаружив уязвимость злоумышленник отправляет жертве ссылку с внедренным кодом

После перехода по ссылке в браузере пользователя выполняется внедренный код

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

Дополнительные материалы по атакам XSS

Основы XSS по-русски [https://hackware.ru/?p=1174]
Основы XSS по-английски [https://learn.snyk.io/lessons/xss/javascript/]

1.4. Подбор паролей

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

идентификация – установление идентификационных данных;
аутентификация – подтвержденное установление идентификационных данных;
авторизация – назначение прав идентификационным данным.

При входе в веб-приложение (sign in, log in) пользователь идентифицируется (сообщает свой идентификатор) и аутентифицируется (доказывает, что он именно тот пользователь, чей идентификатор был сообщен). Большинство веб-приложений используют аутентификацию по паролю. В веб-приложениях с высоким уровнем защищенности (например, в Интернет-банках) также применяются протоколы двухфакторной аутентификации. Очевидным недостатком аутентификации по паролю является возможность использования паролей с плохими статистическими характеристиками. Хранение пароля или его передача по каналам связи в открытом или даже зашифрованном виде потенциально несет угрозу раскрытия пароля.

Очень большое количество пользователей использует очень простые и предсказуемые пароли для приложений. Очень часто пароль один от различных сервисов (почта, социальные сети, онлайн-банк).

Самой распространенной атакой является брутфорс или перебор по словарю. Как это работает:

Пользователь задаёт пароль и логин (или использует логин по умолчанию):

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

1.5. Обратный путь в директориях (Path Traversal)

Атака по обходному пути (также известная как Path Traversal) предназначена для доступа к файлам и каталогам, которые хранятся вне корневой папки сервера. Путем манипулирования переменными, которые ссылаются на файлы с чередованием «dot-dot-slash или (../)» и его вариантами или с использованием абсолютных путей к файлу, может быть получен доступ к произвольным файлам и каталогам, хранящимся в файловой системе, включая исходный код приложения или конфигурацию и критические системные файлы. Следует отметить, что доступ к файлам ограничен управлением операционным доступом системы (например, в случае заблокированных или используемых файлов в операционной системе Microsoft Windows) или файлах без права чтения в Linux.

Как это работает:

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

Злоумышленник меняет наименование файла на путь к файлу, который он хочет прочесть, к примеру ../../../../../../../../etc/passwd. Сервер так же обрабатывает параметр и возвращает пользователю файл с соответствующим названием.

1.6. Прямой доступ к объектам

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

mysite.ru/read_message.jsp?id=123654

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

1.7. Некорректная настройка механизмов безопасности

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

доступность интерфейсов управления в т.ч. фактически неиспользуемые: сетевые порты, URI
разглашение информации в сообщениях об ошибках (фреймворк, ЯП, СУБД, сервер)
Проблемы на границе сфер ответственности администраторов и разработчиков (workingCopy)
автодополнение и кэширование
отсутствие флагов или заголовков безопасности (защита от client-side атак: Clickjacking, XSS)
файлы, содержащие конф. информацию, доступны всем (*.php.1)

Несколько примеров того, как это работает:

доступность интерфейсов управления

Разглашение информации в сообщениях об ошибках

Проблемы на границе сфер ответственности администраторов и разработчиков (workingCopy)

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

Ни одно современное веб-приложение не работает без подключения сторонних компонентов (пришлось бы тратить слишком много времени на изобретение велосипеда). Основная проблема данного подхода в том, что приложение использует чужой код, но не следит за его актуальностью и состоянием. А в этом коде могут содержаться критические уязвимости или незадекларированные возможности. Очень хорошим примером является пример с библиотекой SSL/TLS, в которой за последние несколько лет нашли огромное количество уязвимостей:

FREAK (экспортные ключи)
POODLE (downgrade и CBC)
HEARTBLEED (некорректная проверка длины)
BEAST (предсказуемый IV и CBC)
CRIME / BREACH (компрессия)

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

2.1. Настройка Burp Suite

Скачайте и установите Burp Suite Community

Создайте временный проект

Выбираем настройки по умолчанию

После запуска программы переходим на вкладку “Proxy”, отключаем прерывание запросов:

Переходим на вкладку «Options». Настройка прокси-сервера должна выглядеть следующим образом:

Открываем браузер Chrome и заходим в «настройки» -> «Дополнительно» -> «Настройки прокси-сервера»

После нажатия, попадаем в меню Подключений. Выбираем «Настройка сети»

Настраиваем прокси-сервер в соответствии с тем, что было указано в настройках Burp Suite.

После настройки переходим на сайт http://burpsuite/ и скачиваем сертификат, нажав на кнопку CA Certificate.

После этого заходим в «настройки браузера Chrome» –> «Дополнительно» -> «Настроить сертификаты».

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

Настройка завершена. Для того, чтобы удостовериться, что всё работает, введите в адресной строке http://yandex.ru

После отображения страницы перейдите в Burp Suite на вкладку «Proxy» -> «HTTP History». В ней вы увидите запросы, которые отправляет ваш браузер и ответы, которые получает от сервера.

*Открыть последний ответ и сделать скриншот

2.2. Внедрение кода (SQL Injection)

Перейти на сайт http://10.5.143.101:PORT/#/products/search?q=

Проверить, что получится, если подставить rest вместо # .

В данном случае присутствует незащищённая ссылка или прямой доступ к объектам. Попробуем получить доступ к Базе данных данного сайта. Для этого необходимо запустить программу sqlmap при помощи команды

python sqlmap.py -u http://10.5.143.101:PORT/rest/products/search?q= --level=3 --risk=3

Если возникнет вопрос про WAF/IPS/IDS – отвечаем N.

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

...
---
Parameter: q (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: q=') AND 9603=9603 AND ('SMUf' LIKE 'SMUf
---
[12:44:52] [INFO] testing SQLite
[12:44:52] [INFO] confirming SQLite
[12:44:52] [INFO] actively fingerprinting SQLite
[12:44:52] [INFO] the back-end DBMS is SQLite
back-end DBMS: SQLite
...

Попробуем получить информацию о количестве и названии баз данных:

python sqlmap.py -u http://10.5.143.101:PORT/rest/products/search?q= --dbs

Программа напишет, что перечислить базы данных невозможно, но можно вывести таблицы. Попробуем получить список таблиц:

python sqlmap.py -u http://10.5.143.101:PORT/rest/products/search?q= --tables

...
[20 tables]
+-------------------+
| Addresses         |
| BasketItems       |
| Baskets           |
| Captchas          |
| Cards             |
| Challenges        |
| Complaints        |
| Deliveries        |
| Feedbacks         |
| ImageCaptchas     |
| Memories          |
| PrivacyRequests   |
| Products          |
| Quantities        |
| Recycles          |
| SecurityAnswers   |
| SecurityQuestions |
| Users             |
| Wallets           |
| sqlite_sequence   |
+-------------------+
...

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

python sqlmap.py -u http://10.5.143.101:PORT/rest/products/search?q= -T Users --dump

2.3. Подбор пароля (Brute-force attack)

Зайти на сайт http://10.5.143.101:PORT/#/login

Проверить, что отображается в Burp Suite. Войти с учётными данными в приложение (admin@juice-sh.op : admin123) Выйти из приложения.

Попытаться войти в приложение, используя неправильный пароль.

Изучить взаимодействие с сервером, определить критерий успешного или не успешного логина в приложение.

Выбрать запрос, отвечающий за логин пользователя, нажать правой кнопкой, выбрать пункт «Send to Intruder».

Перейти на вкладку «Intruder» -> «Position»

В окне выделить символом § с двух сторон только форму password. Создать на компьютере файл, содержимое которого является паролями, которые будут перебираться (каждое значение с новой строки). В файле должен быть валидный пароль.

Перейти на вкладку «Payloads», загрузить файл через кнопку «Load…»

Нажать на кнопку «Start Attack», дождаться окончания. После в приведенной таблице проанализировать ответы сервера и понять, какой пароль из представленных действительно подошёл от нашей учётной записи.

Это можно сделать, посмотрев на длину ответа от сервера, для валидного пароля она будет отличаться.

*Скриншот

2.4. Межсайтовый скриптинг (XSS)

Перейти на https://xss-game.appspot.com/level1

В появившемся окне в строке поиска ввести строку

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

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

*Скриншот

Переходим на уровень 2.

Здесь представлен форум, на котором можно писать сообщения. При этом тэг <script> фильтруется и использовать его нельзя. Попробуем обойти другим способом и внедрим следующий код в страницу:

<img src="http://url.to.file.which/not.exist" onerror=alert('111');>

*Скриншот

Таким образом мы попросили браузер обратиться за картинокй, которой не существует и, в случае ошибки, выполнить код указанный далее.

2.5. Прямой доступ к объектам

Зайдите на сайт http://10.5.143.101:PORT/

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

Для этого в браузере нажмем F12 и перезагрузим страницу. Теперь, необходимо найти файл main.js и провести в нем поиск по слову “admin”.

Увидим, что он встречается в строке для роутинга path: "administration"

Таким образом, обратившись напрямую к http://10.5.143.101:PORT/#/administration попадем в панель администратора

*Скриншот

3. Задание

На сайте http://10.5.143.101:PORT/#/ найти и сделать скриншот:

Cross-Site Scripting (XSS)
SQL Injection
Панель scoreboard

*дополнительно можно попробовать получить таблицу пользователей

README.md

Лабораторная работа 3

Выполнение лабораторной работы

Подключение к серверу

Требования к отчёту:

Цель работы

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

1.1. OWASP

1.2. Внедрение кода (SQL Injection)

Дополнительные материалы по атакам инъекции SQL

1.3. Межсайтовый скриптинг (XSS)

Дополнительные материалы по атакам XSS

1.4. Подбор паролей

1.5. Обратный путь в директориях (Path Traversal)

1.6. Прямой доступ к объектам

1.7. Некорректная настройка механизмов безопасности

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

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

2.1. Настройка Burp Suite

2.2. Внедрение кода (SQL Injection)

2.3. Подбор пароля (Brute-force attack)

2.4. Межсайтовый скриптинг (XSS)

2.5. Прямой доступ к объектам

3. Задание

Каждый скриншот должен сопровождаться подробным описанием вводимых команд/настроек и результатов их выполнения