---
# System prepended metadata

title: Untitled

---

Особенности работы отдела безопасности сетевых (WEB) приложений

#1

Подключение к ovpn

![](https://i.imgur.com/zWxpGd5.png)

Порты с сервисами и их версиями

![](https://i.imgur.com/R9PTOfV.png)

Порт 21

![](https://i.imgur.com/JOedXCd.png)

Порт 22

![](https://i.imgur.com/HbBVBk6.png)

Порт 2200

![](https://i.imgur.com/sT9c6Gd.png)

Порт 4433



CHECK 1

Отправляется запрос на /bitrix/tools/composite_data.php

Получаем значения PHPSESSID и bitrix_sess_id

Отправляем эти значений на другой адрес

Параметр FileUploader говорит о том что мы загружаем файл

Потом идет проверка, если код 200 и идет совпадение с параметром find("???????????????????????????"), тогда выводит сообщение что есть уязвимость

Уязвимость Cross-Site Scripting

CHECK 2

Создаёт буфер notVulnRecv

Создаёт три разных буфера

Отправляет пакет, если не удалось пишет false, если удалось читает ответ

Отправляет пакет sendValidProbe, если не удалось пишет false

Очищает recvMsg и пишет туда то, что есть в сокете. Если что то есть пишет Vulnerable, если нет false

Другие методы проверок

Метод “белого ящика” – тестировщику заранее известно все, включая исходный код. В этом случае проводятся проверки исходного кода на наличие потенциально опасного кодирования – статически по сигнатурам и динамически на уровне разработчиков (когда модули подвергаются тестированию на ввод некорректных данных). Для открытого ПО этот метод весьма актуален и позволяет выявить большое количество уязвимостей. Недостатком является статичность метода – при отсутствии сигнатуры в базе проверка не будет иметь эффекта. Так же при использовании сложного синтаксиса потенциальная уязвимость может быть просто не замечена. Данный метод эффективен для выявления ошибок обработки данных, но не позволяет взглянуть на ресурс глазами злоумышленника. Такое тестирование проводится средствами среды разработки или модулями анализа кода – например RATS, Yasca (open source).

Метод “серого ящика” – тестеру предоставляются все полномочия кроме непосредственного доступа к серверу. Проверки происходят на предмет повышения полномочий, выявления ошибок обработки данных, реакции на некорректные данные. Данный способ позволяет оценить корректность работы ресурса при вводе разных исходных данных, но, как и предыдущий метод, не позволяет инсценировать атаку на ресурс. Примером свободного инструмента, реализующего данный принцип, можно считать Whisker/libwhisker.

Метод “черного ящика” – тестировщик иммитирует действия потенциального злоумышленника любыми доступными ему способами. При таком способе тестирования проверяется как наличие уязвимостей приложения, так и действия персонала по противодействию атаке и реагированию на инцидент. При проведении подобного тестирования действиям персонала необходимо уделять особое внимание, так как в некоторых случаях способность адекватно реагировать на инцидент имеет решающее значение. Недостатком данного метода является то, что тестер должен иметь весьма высокую квалификацию для достижения эффективных результатов, а тестирование занимает достаточно продолжительное время. Для автоматизации подобного тестирования можно применить мощный open source инструмент Nikto.



