# WEB Basic - 3

**SQL-injection уязвимости**
1. SQL injection vulnerability allowing login bypass
- изучаем работу приложения, вводим произвольные логин и пароль. Сервер возвращает - Invalid username or password.

- подставляем ' в поле Username, возвращается - Internal Server Error, значит можно предположить, что нет фильтрации входных данных в SQL-запросах

- в Burp Suite изменяем параметр username на administrator'--', отбрасываем параметр пароля и отправляем запрос


2. Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data

- изучаем работу приложения
> всего -12 товаров, в 4-х категориях (по 3 в каждой)

- в параметрах URL видим фильтрацию по категориям

> проверяя категории, вводим ' и комментарий в парамет в URL после категории товаров.
> Видим вывод введенных символов, значит нет фильтрации в SQL-запросах на сервере

> дополним SQL-запрос - '+OR+1=1--
> Видим весь перечень товаров

- также можно посмотреть весь перечень изменяя параметр ID, так как там тоже нет фильтрации

3. Lab: SQL injection UNION attack, retrieving data from other tables

- для начала нужно узнать сколько столбцов в таблице
- через Burp Suite дополняем запрос - '+UNION+SELECT+'abc'
- сервер возвращает - Internal Server Error

- дополняем SQL-запрос - '+UNION+SELECT+'abc','def'--
- ответ от сервера изменился

- попробуем указать наименования столбцов из таблицы users- '+UNION+SELECT+username,+password+FROM+users--

- видим вывод учетных записей нескольких пользователей

- заходим под учетной записью администратора

4. Lab: SQL injection attack, querying the database type and version on MySQL and Microsoft
- узнаем сколько столбцов в таблице, в Burp Suite дописываем в SQL-запрос - '+UNION+SELECT+'abc','def'#

- видим вывод в ответе введенные данные

- добавляем в запрос параметр версии

- в ответе Burp Suite и браузере видим версию MySQL

**XSS уязвимости:**

1. Lab: Stored XSS into HTML context with nothing encoded
- изучаем работу приложения:
> видим, что к каждой публикации есть поле для ввода комментария, имя, e-mail и веб-сайта

- попробуем заполнить эти поля и подставить спецсимволы, отправим комментарий и вернемся в блог
> видим, что спецсимволы не экранируются

- попробуем подставить скрипт и отправить комментарий

- отправим комментарий

- вернемся в блог, скрипт сработал

2. Lab: DOM XSS in document.write sink using source location.search

- изучаем работу приложения
> вводим произвольный запрос в поисковую строку и проверяем куда он падает в JS

- подставляем полезную нагрузку

- скрипт сработал

3. Lab: Reflected XSS into a JavaScript string with angle brackets HTML encoded

- изучаем работу приложения
> вводим произвольный запрос в поисковую строку и проверяем куда он падает в JS
> данные попали в скрипт

- подставляем полезную нагрузку

- скрипт сработал

4. Lab: Reflected DOM XSS

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

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

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

- добавляем полузную нагрузку

- скрипт сработал

CSRF:

1. Lab: CSRF vulnerability with no defenses

- заходим в приложение под учетной записью wiener

- обновляем адрес электронной почты

- находим POST запрос в Burp Suite, который отсылали на измение почты

- пишем HTML-код, в котором указываем ссылку (параметр host в POST-запросе) на страницу изменения почты, метод и новую почту

- переходим на сервер эксплойтов, вставляем свой HTML-код в раздел «Body» и сохраняем

- проверяем работу кода и отправляем жертве

2. Lab: CSRF where token validation depends on request method

- заходим в приложение под учетной записью wiene

- обновляем адрес электронной почты

- в Burp Suite перехватываем запрос и видим, что это POST-запрос и есть параметр csrf

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

- пишем HTML-код в котором указываем метод GET, ссылку на страницу изменения почты и новую почту, но без указания параметра csrf

- переходим на сервер эксплойтов, вставляем свой HTML-код в раздел «Body» и сохраняем

- проверяем работу кода и отправляем жертве

SSRF:
1. Lab: Basic SSRF against the local server

- проверяем работу приложения
> на каждой позиции (товаре) есть опция проверки остатков в определенном городе
> значит приложения извлекает данные с сервера
> 

- проверим возможность получения данных по URL
> перехватываем запрос в Burp Suite и изменяем параметр stockApi

> сервер возвращает список админов и возможной опции их удаления

> в HTML-коде находим путь для удаления пользователя

- модифицируем запрос к серверу

> выполняем атаку

2. Lab: SSRF with filter bypass via open redirection vulnerability

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

- изменяя параметр stockApi невозможно отправить запрос напрямую другому хост

- попробуем перенаправить запрос используя парамет path и получим админский интерфейс

- в HTML-коде находим путь для удаления пользовател

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

- задание выполнено

RCE:

Lab: OS command injection, simple case

- проверяем работу приложения
> видим в запросе параметры productId и storeId

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

- задание выполнено

Path traversal:

1. Lab: File path traversal, simple case

- проверяем работу приложения
> видим что при запросе использутся параметр filename в котором лежит файл (.jpg)

- изменяем путь и файл, указываем абсолютный путь к файлу /etc/passwd

- задание выполнено

2. Lab: File path traversal, traversal sequences blocked with absolute path bypass

- на примере предыдущего задания попробуем обратится к файлу /etc/passwd, но видим что здесь абсолютный путь заблокирован

- попробуем обратится по относительному пути

- задание выполнено