№3 Основные атаки и паттерны
===
## Цель работы:
- Изучить основные атаки на WEB

**SQL-injection уязвимости**
---
**1. Lab: SQL injection vulnerability allowing login bypass**
Включаем intercept во вкладке proxy и вводим логин и пароль на сайте
Перехватим запрос
Пропишем sql-инъекцию (username закомментирован, он войдет в учетную запись указанного пользователя) и пропустим запрос дальше
Залогинимся на сайте

**2. Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data**
Заходим на страницу для реализации инъекции. Переходим во вкладку Corporate gifts и добавляем инъекцию (у параметра category всегда будет true, поэтому он выведет все товары) в заголовок пакета
Переходим во вкладку Options в bupr suite и ставим галочку в параметре "intercept responses based on the following rules"
Пропускаем запрос дальше и видим что каталог товаров выводит теперь все что есть

**3. Lab: SQL injection UNION attack, retrieving data from other tables**
Заходим на страницу лабораторной и переходим во вкладку Pets. Перехватываем запрос
Отправим его в repeater
Пытаемся вывести данные пользователей с помощью инъекции в заголовке, котораы должна вывести данные столбцов username, password из таблицы users
Залогинимся с помощью этих данных

**4. Lab: SQL injection attack, querying the database type and version on MySQL and Microsoft**
Открываем страницу и переходим в любую из вкладок, в моем случае это вкладка Tech gifts
Переносим перехваченный запрос в repeater
Вводим инъекцию и ищем в responce строку 8.0.30 (в респонсе бул хинт в котором было это написано). Вводим инъекцию в заголовок, которая должна вывести версию и добавляем еще 1 столбец, т.к иначе запрос выдает ошибку
В туториале этого нет, но запрос без "#" на конце выводит ошибку

**XSS уязвимости**
---
При реализации такой атаки приложение получает данные из ненадежного источника и включает эти данные в свои последующие HTTP-ответы

**1. Lab: Stored XSS into HTML context with nothing encoded**
Заходим в любой блов и пиишем к нему комментарий, скрипт, который приостановит работу, до тех пор пока пользователь не нажмёт «ОК»
Запостим его
Вернемся обратно в блог и увидем всплывающее окно

**2. Lab: DOM XSS in document.write sink using source**
Переходим по ссылке лабораторной работы, вводим в поисковик любую последовательность символов и нажимаем кнопку search
Исследуем код страницы и видим что у скрипта не закрыты скобки
Прописываем alert-функцию
Нажимаем кнопку search и видим результат

**3. Lab: Reflected XSS into a JavaScript string with angle brackets HTML encoded**
Запускаем лабораторную, вводим в поисковим набор символов и перехватываем запрос
Отправляем перехваченый пакет в repeater и отключаем interсept. Прописываем js-функцию в строку поисковика
Результат

**4. Lab: Reflected DOM XSS**
В поисковике ищем xss, просматриваем get-запрос в http history
Переходим в таргет, находим js файл и вводим в поисковую строку функцию, которая приостановит работу сайта и выведет окно с "1"
Результат

**CSRF**
---
**1. Lab: CSRF vulnerability with no defenses**
Залогинимся под учетной записью wiener с паролем peter и изменим почту. Просмотрим http историю
Переходим в csrf poc generator и ставим галочку в include auto-submit script. Затем нажимаем кнопку regenerate, потом copy html, после этого можно закрыть вкладку (это заставит пользователя-жертву непреднамеренно выполнить какое-либо действие)
Далее на странице браузера нажимаем кнопку go to exploit server и вставляем скопированный html в body и меняем почтовый адрес
Сохраняем с помощью кнопки store и просматриваем изменения с помощью view exploit

**2. Lab: CSRF where token validation depends on request method**
Залогинимся под учетной записью wiener с паролем peter и изменим почту. Просмотрим http историю. Отправим запрос в repeater
Меняем requesr method и переходим в csrf poc generator, меняем адрес почты и ставим галочку в include auto-submit script. Затем нажимаем кнопку regenerate, потом copy html, после этого можно закрыть вкладку
Далее на странице браузера нажимаем кнопку go to exploit server и вставляем скопированный html в body и сохраняем
Просматриваем изменения с помощью view exploit

**SSRF**
---
**1. Lab: Basic SSRF against the local server**
Нажимаем check stoks и перехватываем запрос, в поле stockApi прописываем http://localhost/admin (это может заставить сервер установить соединение с внутренними службами в инфраструктуре организации) и нажимаем forward
Выыод проверяем с помощью просмотра элементов страницы
Повторяем действия из первого пункта, но в поле stockApi прописываем http://localhost/admin/delete?username=carlos для удаления пользователя carlos и пропускаем запрос
Снова прописываем http://localhost/admin и проверяем список users

**2. Lab: SSRF with filter bypass via open redirection vulnerability**
Зайдем на страницу товара, нажмем кнопку check stoks и перехватываем запрос, в поле stockApi прописываем
/product/nextProduct?path=http://192.168.0.12:8080/admin
В результате нам выводится список пользователей, исследуем код страницы и находим как удалить бзера
/http://192.168.0.12:8080/admin/delete?username=carlos
Пропысываем эту строку в поле stockApi
Проверяем список юзеров

**RCE**
---
**1. Lab: OS command injection, simple case**
Зайдем на страницу товара, нажмем кнопку check stoks и перехватываем запрос, в поле productId дописываем '|whoami'
Нажимаем forward и получаем ответ

**Path traversal**
---
**1. Lab: File path traversal, simple case**
Переходим во вкладку Options в bupr suite и ставим галочку в параметре "intercept responses based on the following rules"
Переховим во вкладку одного из товаров и изменяем заголовок. Результат проверяем во вкладке http history

**2. Lab: File path traversal, traversal sequences blocked with absolute path bypass**
Переховим во вкладку одного из товаров, перехватываем пакет и изменяем заголовок так, чтобы запрос выводил нам содержимое файла по указанному пути
Прописываем /etc/passwd проверяем результат в http истории

Прогресс
---