Юридический аудит

Открытые конфигурационные файлы на сайте

Открытые конфигурационные файлы — когда по прямой ссылке доступны .env, бэкапы, phpinfo и похожие служебные ресурсы. Это риск утечки доступов и данных клиентов; доступ закрывают сразу, секреты считают скомпрометированными.

Опубликовано: · Обновлено: · Проверено:

Открытые конфигурационные файлы
Служебные пути в публичном доступе Auteh · Proprietary — all rights reserved

Открытые конфигурационные файлы — ситуация, когда служебные ресурсы приложения отдаются по прямой ссылке из публичного корня сайта: .env, копии окружения, архивы, дампы, info‑страницы и похожие следы. Это не «мелкий косяк вёрстки», а потенциальная выдача ключей к инфраструктуре и данным.

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

Что обычно оказывается внутри

В таких файлах и выгрузках часто лежат:

  • пароли к базе и почте;
  • ключи облачных и платёжных сервисов;
  • токены CRM и рассылок;
  • пути к бэкапам и иногда фрагменты персональных данных.

Если это доступно из интернета, злоумышленнику не нужно месяцами подбирать админку.

Какие семейства проблем искать (по своему сайту)

Речь не об атаке на чужие ресурсы. По своему проекту базовый осмотр уместен. Частые схемы:

Что бывает открытоЧем опасно
.env и копии (.bak, .old)Секреты приложения
Бэкапы (sql, zip, tar)База или файлы целиком
Служебные info‑страницыВерсии, пути, настройки
Каталоги с листингомУдобный обзор для скачивания
Тестовые стенды на поддоменеТе же секреты «на черновике»

Точные имена зависят от стека. После миграции с другого сервера «временные» копии забывают особенно часто. Имеет смысл спросить у хостинга, закрыты ли служебные пути по умолчанию.

Что сделать в первый час

Что сделать в первый час

  1. Закройте доступ к файлу или каталогу (правила веб‑сервера, права, удаление лишнего из публичного корня).
  2. Считайте секреты скомпрометированными — смените пароли БД, ключи API, пароли почты и админок, которые там были.
  3. Проверьте копии рядом — старые .env, архивы в uploads, «бэкап для клиента» по прямой ссылке.
  4. Подключите того, кто держит сервер — нужны логи и поиск смежных дыр, не только одного файла.
  5. Оцените риск для заявок и клиентов — если могли утянуть базу, это сценарий для ответственного за данные, а не только правка nginx.

Не публикуйте скриншоты с секретами в общие чаты. Не оставляйте файл «до согласования бюджета» — закрытие доступа дешевле согласования.

Ложная безопасность

Убрали .env из выдачи — необходимо, но недостаточно, если тот же пароль остался в репозитории, тикете или письме подрядчику. Смена секретов обязательна. Тестовый dev.‑поддомен с копией боя без защиты нередко находят быстрее, чем ожидают.

Ограничьте практику выкладывать архивы в корень «ссылкой для клиента». Служебное не должно жить рядом с публичными медиа.

Добавьте в чек‑лист после миграции хостинга: нет ли старых копий .env, backup, dump и phpinfo по прямым путям; закрыт ли directory listing; не доступен ли .git извне. Одна миграция без этого пункта возвращает проблему через неделю.

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

Связь с персональными данными и проверками

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

Если сайт собирает заявки, после инцидента имеет смысл ещё раз сверить формы и политику: посетителю должно быть ясно, кто обрабатывает данные; внутри команды — что доступы ротировали. Это гигиена после утечки секретов, а не «калькулятор санкций».

Кому писать сразу

  • Хостинг или администратор сервера — закрыть путь и посмотреть логи.
  • Разработчик — убрать привычку класть бэкапы в публичную папку.
  • Ответственный за персональные данные — если могли затронуть базу клиентов.

Сначала доступ, потом разбор. Найдены — закрыть и сменить секреты в тот же день. Не найдены — всё равно зафиксируйте правило: служебное не живёт в публичном корне.

Типичная конфигурация после «срочной выгрузки для подрядчика»: архив положили в /uploads или корень, скинули ссылку в чат и забыли удалить. Через недели ссылка всё ещё отвечает. Добавьте в регламент деплоя явный пункт: после передачи бэкапа файл с публичного URL исчезает, секреты не пересылают скриншотом.

Итог: открытый конфиг — потенциальная выдача ключей от инфраструктуры. Закрытие доступа и ротация секретов в тот же день важнее длинного обсуждения «насколько это критично».

Смежные материалы: подготовка сайта к проверке, как проверить сайт по 152‑ФЗ.

Частые вопросы

Что чаще всего оказывается открытым?

Файлы вроде .env и копий, архивы и дампы, служебные info‑страницы, каталоги с листингом. Набор зависит от CMS и хостинга.

Если файл открылся у меня — его уже украли?

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

Это только IT или ещё про персональные данные?

Оба слоя. Утечка доступов к базе или почте бьёт по безопасности и по данным клиентов. На сайте это приоритет «чинить сегодня».

Можно ли проверить без программиста?

Базово — да, аккуратно по своим типичным служебным URL. Глубокую проверку и закрытие лучше отдать тому, кто администрирует сервер.

Что может проверить Auteh

Auteh анализирует публичную часть сайта и показывает признаки потенциальных проблем в выбранном направлении аудита. Результат — отчёт с найденными пунктами, а не юридическое заключение.

Источники