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

### Цель работы

Получить практические навыки анализа 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-инъекции и мы будем упоминать этот вектор еще не раз.

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

<image src="assets/L3_1.jpg">

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

<image src="assets/L3_2.jpg">

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

<image src="assets/L3_3.jpg">

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

<image src="assets/L3_4.jpg">

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

<image src="assets/L3_5.jpg">

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

<image src="assets/L3_6.jpg">

Различают несколько видов SQL-инъекций:
1.	Внедрение операторов SQL (SQL Injection)
2.	Слепое внедрение операторов 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\JS – кода в уязвимую страницу. Инъекция кода осуществляется через все доступные способы ввода информации. Успешное завершение атаки может привести к использованию значений различных переменных, доступных в контексте сайта, записи информации, перехвату пользовательских сессий, данных и т.д. Cross-Site Scripting (XSS) – Это уязвимость на стороне клиента.

Условно Cross-Site Scripting (XSS) делят на:
*	Сохраненный вариант (Persistent / Stored)
*	Отраженный вариант (non-persistent / reflected)

Как это работает:
1.	Пользователь вводит на Web-сайте в строке поиска слово “secureweb”. 
 
<image src="assets/L3_7.jpg">

2.	Web-сервер отображает введенную поисковую фразу на странице так, как она была введена в поле
 
<image src="assets/L3_8.jpg">

3.	Обнаружив уязвимость злоумышленник отправляет жертве ссылку с внедренным кодом
 
<image src="assets/L3_9.jpg">

4.	После перехода по ссылке в браузере пользователя выполняется внедренный код
 
<image src="assets/L3_10.jpg">

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

<image src="assets/L3_11.jpg">

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

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

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

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

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

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

<image src="assets/L3_12.jpg">

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

<image src="assets/L3_13.jpg">

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

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

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

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

<image src="assets/L3_14.jpg">
 
2.	Злоумышленник меняет наименование файла на путь к файлу, который он хочет прочесть, к примеру `../../../../../../../../etc/passwd`. Сервер  так же обрабатывает параметр и возвращает пользователю файл с соответствующим названием.

<image src="assets/L3_15.jpg">

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

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

```ssh
mysite.ru/read_message.jsp?id=123654
```

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

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

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

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

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

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

<image src="assets/L3_16.jpg">

<image src="assets/L3_17.jpg">
 
*	Разглашение информации в сообщениях об ошибках
 
<image src="assets/L3_18.jpg">

<image src="assets/L3_19.jpg">

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

<image src="assets/L3_20.jpg">

<image src="assets/L3_21.jpg">

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

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


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

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

Скачайте и установите [Burp Suite Community](https://portswigger-cdn.net/burp/releases/download?product=community&version=2023.3.5&type=WindowsX64) 

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

<image src="assets/L3_22.jpg">

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

<image src="assets/L3_23.jpg">

После запуска программы переходим на вкладку “Proxy”, отключаем прерывание запросов: 
 
<image src="assets/L3_24.jpg">

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

<image src="assets/L3_25.jpg">

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

<image src="assets/L3_26.jpg">
 
После нажатия, попадаем в меню Подключений. Выбираем «Настройка сети»

<image src="assets/L3_27.jpg">
 
Настраиваем прокси-сервер в соответствии с тем, что было указано в настройках Burp Suite.

<image src="assets/L3_28.jpg">

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

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

<image src="assets/L3_29.jpg">
 
В появившемся окне нажимаем импорт и продвигаемся по меню, выбрав скачанный ранее файл сертификата. Его необходимо добавить в доверенные центры сертификации.

<image src="assets/L3_30.jpg">

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

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

<image src="assets/L3_31.jpg">

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

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

Перейти на сайт `http://www.ubraintv.com/watchchannel.php?id=6`

Проверить, что получится, если после id=6 поставить кавычку.

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

```ssh
python sqlmap.py -u "http://www.ubraintv.com/watchchannel.php?id=6" 
```

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

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

```ssh
python sqlmap.py -u "http://www.ubraintv.com/watchchannel.php?id=6" --dbs 
```

В полученных результатах нас интересует база данных mysql (т.к. information_schema это системная база данных, она не интересна).
Попробуем получить список таблиц в выбранной базе данных:

```ssh
python sqlmap.py -u "http://www.ubraintv.com/watchchannel.php?id=6" -D mysql --tables
```

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

```ssh
python sqlmap.py -u "http://www.ubraintv.com/watchchannel.php?id=6" -D mysql -T user --dump
```

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

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

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

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

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

Перейти на вкладку «Intruder» -> «Position»
 
<image src="assets/L3_32.jpg">

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

Перейти на вкладку «Payloads», загрузить файл через кнопку «Load…»
 
<image src="assets/L3_33.jpg">

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

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

<image src="assets/L3_34.jpg">

***Скриншот**

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

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

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

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

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

***Скриншот**

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

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

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

***Скриншот**

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

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

Зайдите на сайт `http://10.5.143.103:3000/`

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

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

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

<image src="assets/L3_35.jpg">

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

***Скриншот**

### 3.	Задание

На сайте `http://10.5.143.103:3000/#/` найти и сделать скриншот:
* Cross-Site Scripting (XSS)
* SQL Injection
* Панель scoreboard

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