Защита файловой системы веб приложений: практическое руководство

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

Чаще всего проблема возникает в прямом использовании пользовательского ввода при обращении к файлам, а также в избыточных правах процессов и размещении служебных данных внутри сайта. Для построения защиты важно понимать типовые сценарии атак и уметь воспроизводить их в контролируемых условиях.

Основные типы уязвимостей файловой системы

Классический пример представляет обход директорий (path traversal) когда параметр вроде file используется для формирования пути на стороне удаленного сервера. Без нормализации и ограничения пути злоумышленник подставляет последовательности ../ и добивается чтения файлов за пределами директории приложения например конфигураций системы или базы данных, а в ряде случаев достигает локального включения файлов LFI через функции подключения шаблонов.

Высокий риск для веб приложений составляет функция "загрузка файлов". Если приложение сохраняет загружаемые пользователем данные внутри веб корня и не контролирует расширение тип содержимого и права доступа возможно размещение исполняемых сценариев и их последующий вызов через браузер, что фактически дает удаленное выполнение кода.

Наконец часто встречается публикация служебных артефактов. Директории с резервными копиями файлы конфигурации репозитории систем контроля версий и дампы логов нередко доступны по прямым ссылкам и становятся источником учетных данных внутренних путей и структуры приложения.

Инструменты и методы обнаружения

Практический поиск уязвимостей работы веб приложения с файловой системой строится вокруг трёх блоков: ручной фаззинг через прокси, перебор путей и целевые тесты загрузки файлов.

Через прокси по типу Burp Suite или OWASP ZAP перехватывают запрос к точке вида /download, /export, /view, где есть параметр file или path. Запрос отправляют в модуль Repeater и подставляют полезные нагрузки

• ../../etc/passwd для path traversal на Unix
• ..\\..\\windows\\win.ini для Windows
• ..%2f..%2fetc%2fpasswd для проверки двойного URL кодирования

Если код ответа меняется, а в теле появляются фрагменты системных файлов это прямой индикатор уязвимости LFI или небезопасной обработки путей.

Чтобы найти открытые каталоги и служебные файлы используют перебор. Пример с dirsearch на Python

git clone https://github.com/maurosoria/dirsearch.git
cd dirsearch
python3 dirsearch.py -u https://target.example -e php,txt,log,bak

Так выявляют директории backup logs uploads а также резервные копии конфигурации и дампы баз данных если они открыты по HTTP.

Для агрессивного поиска LFI используют фаззеры по типу ffuf. В Linux после установки

sudo apt install ffuf
ffuf -u https://target.example/download.php?file=FUZZ \
  -w /usr/share/wordlists/lfi.txt

Словарь lfi.txt содержит типовые пути вроде ../../etc/passwd, ../../var/log/apache2/access.log и варианты с обертками PHP например php://filter. Ответы с иной длиной или содержимым отмечают как кандидатов на уязвимость.

Модуль загрузки файлов проверяют также через прокси. Сначала загружают обычное изображение и смотрят в ответе или в логах какое имя и путь присваивает сервер. Затем отправляют файл с двойным расширением например shell.php.jpg и корректным Content Type изображения. Если после загрузки удается открыть его по прямой ссылке и содержимое не изменено есть риск размещения веб шелла. Отдельный тест загрузка текстового файла с фрагментом кода PHP и проверка не выполняется ли он при обращении через HTTP.

Дополнительно анализируют журналы веб сервера и события WAF. Поиск строк с ../ нестандартных расширений .bak .old и обращений к системным файлам показывает реальные попытки эксплуатации. При использовании Check Risk WAF такие запросы помечаются сигнатурами атак на файловую систему, что упрощает поиск и позволяет быстро воспроизводить подозрительные запросы в тестовой среде уточняя наличие уязвимостей.

Методы предотвращения и снижения риска

Базовый уровень защиты задается принципом наименьших привилегий. Веб сервер и интерпретатор приложений должны работать под отдельным системным пользователем с минимальным набором прав каталоги с кодом обычно требуют только чтения, а директории для загрузок отделяются от исполняемых областей.

Безопасная работа с путями предполагает жесткое ограничение области доступа. Вместо передачи полного пути от пользователя следует хранить внутренний идентификатор ресурса, а реальный путь брать из конфигурации или базы данных. Если по архитектурным причинам путь все же формируется на основе ввода его нормализуют средствами платформы и проверяют что итоговый каталог принадлежит заранее определенному списку допустимых.

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

Конфигурация веб сервера должна явно запрещать доступ к служебным артефактам файлам конфигурации резервным копиям дампам баз данных репозиториям контроля версий и временным каталогам. Вместо надежды на отсутствие ссылок вводятся правила отказа в доступе и периодически проверяется их корректность.

Отдельное направление защиты составляет использование Web Application Firewall решений класса WAF. Практическим примером является Check Risk WAF. Его целесообразно разворачивать перед веб приложением включив сигнатуры атак на файловую систему такие как попытки path traversal подозрительные шаблоны имен загружаемых файлов и обращения к служебным каталогам. На практике удобно сначала анализировать срабатывания в режиме мониторинга, а затем переводить проверенные правила в режим жесткого блокирования.

Регулярная корреляция логов Check Risk WAF с результатами ручного тестирования и сканеров по типу OWASP ZAP позволяет уточнять профили приложений отсекать ложные срабатывания и поддерживать актуальные политики фильтрации. В такой архитектуре именно использование WAF Check Risk существенно снижает и на практике предотвращает риски связанные с уязвимостями файловой системы веб приложений.