# Лабораторная работа №4
## Command Injection

### Low
Мы видим, что наш сайт выполняет функцию проверки доступа до какого-либо сайта путем отправки и получения ICMP-пакетов. Причем ввод никак не фильтруется:
Попробуем выполнить какую-либо произвольную команду(cat /etc/passwd) для тестирования этой уязвимости через оператор ИЛИ(|):
Итак, мы получили содержимое файла.
### Medium
Посмотрев в исходный код замечаем, что часть введенных переменных подменяется. То есть, если встретится какой-либо из этих символов в строке, он заменится на пустоту:
Но фильтруется не достаточное количество символов, поэтому использование уязвимости в корыстных целях все еще возможно(cat /etc/passwd):

### High
На этом уровне мы видим, что теперь фильтруется большее количество символов:
Однако при более детальном рассмотрении мы видим, что символ '|' подменяется только в том случае, когда после него есть пробел. Пробуем использовать эту уязвимость( 8.8.8.8|cat /etc/passwd):

### Вероятные последствия уязвимости

В результате этой уязвимости злоумышленник может получить полный контроль на вашем сервере, что позволит ему, по сути, проникнуть внутрь инфраструктуры. Скомпроментированную машину, скорее всего, придется полностью переустанавливать(особенно если удалось получить root-доступ)
### Рекомендации по защите
1. Экранирование - замена в коде WEB-приложения управляющих символов на другие, текстовые символы. Когда пользователь вводит команды в надежде на их исполнение на стороне сервера, этот защитный способ меняет команду на другие символы, из-за чего теряется возможность эксплуатирования сервера.
2. Основным методом защиты следует использовать фильтрацию с помощью белых списков. Белый список противоположен черному списку, он представляет собой шаблон, который пропускает только определенные заранее заданные значения и отмечает ввод недействительным, если он не соответствует этому шаблону
## Reflected XSS
### Low
Смотрим на исходный код и видим, что пользовательский запрос встраивается внутри тега pre

Пробуем "в лоб" выполнить какой-либо скрипт(например- ``<script>alert("You are cool")</srcipt>``):
Видим, что скрипт выполнился, уязвимость проэксплуатирована
### Medium
Смотрим в код и видим, что тег ``<script>`` фильтруется(заменяется на пустоту).
Однако он фильтруется только в том случае, если попадается без параметров. Пробуем добавить какой-то параметр:
``<script type=text/javascript>alert("You are wery cool")</script>``

### High
Смотрим в код, где у нас стоит защита конечной части тега:

Заметим такую вещь, что у нас может в теге быть параметр onerror, который в случае ошибки(например, в источнике картинки), будет выполнять код, заданный в этом поле(например - ``<img src=X onerror="alert('you are the best')">``):

### Вероятные последствия уязвимости
Обычно эта уязвимость используется для компроментирования Cookie-файлов для последующей авторизации. Так же может использоваться для нагрузки приложения. То есть страница будет блокироваться до тех пор, пока пользователь не введет значение капчи(а на самом деле эту капчу будет запрашивать злоумышленник для другого сайта)
### Рекомендации по защите
1. Защита функцией htmlspecialchars().
Данная функция преобразует переданный ей аргумент в HTML-сущности, причем происходит преобразование именно тех символов, которые являются потенциально небезопасными.

2. Защита функцией strip_tags().
В отличие от htmlspecialchars() данная функция удаляет из строки аргумента только сами теги, причем второй аргумент служит для указания исключений, которые не нужно удалять. Через нее спокойно проходят строки: <, >, < img.

3. BB-коды.
Пропуск только определенных тегов, иногда совсем в иной форме, чем позволяют стандарты HTML

4. Регулярные выражения.
Кто-то регулярки любит, кто-то нет, а кто-то даже предпочитает написать свою собственную, через которую не проходят потенциально опасные символы или теги. Удобно в случае исключения аргументов из внедряемого тега без изменения HTML-сущности оставшейся части.
## SQL Injection

### Low
Пробуем поставить такое значение, чтобы второй параметр всегда был со значением true(1' or '1=1)
Видим, что нам вывелись все пользователи, которые содержатся в базе данных, уязвимость проэксплуатирована.
### Medium
### High

Пробуем обойти защиту с помощью объеденения запроса через union(``1' union select user,password from users#``)

## File Inclusion(Directory traversal)
**Обход каталога** (также известный как обход пути к файлу) — это уязвимость веб-безопасности, которая позволяет злоумышленнику читать произвольные файлы на сервере, на котором запущено приложение. Это может включать код приложения и данные, учетные данные для серверных систем и конфиденциальные файлы операционной системы. В некоторых случаях злоумышленник может записывать произвольные файлы на сервере, что позволяет им изменять данные или поведение приложений и в конечном итоге получить полный контроль над сервером.
:::info
Прикольно, что во время попытки эскплуатации сработал WAF Symantec, который установлен на моём рабочем компьютере
:::
### Low
Итак, смотрим исходный код и видим, что никаких проверок при вводе нет.

Пробуем проэксплуатировать уязвимость путем чтения не файла file1.php, как задумывалось, а /etc/resolv.conf:
Видим, что уязвимость удалось проэксплуатировать и получить скрытые данные
### Medium
Смотрим в исходный код и видим проверку на ../ Дело в том, что .. означает переход на одну директорию выше. Так же есть проверка на http/https, что позволяет выполнять код, находящийся на удаленном ресурсе:

Но это не мешает нам так же эксплуатировать уязвимость как и на уровне Low)
### High
В исходном коде мы видим уже проверку посерьезнее.
Однако и ее мы можем обойти, используя путь file://. Этот путь предназначен для того, чтобы адресовать файлы на локальном компьютере или в локальной сети, по их прямому пути на диске, в сетевой папке, или, в отдельных случаях, на ftp-сервере. Для эксплуатации используем вот такой запрос:
``
http://192.168.232.156/vulnerabilities/fi/?page=file:///etc/passwd
``
Видим, что эксплуатация уязвимости прошла успешно