Руководства по безопасности
Оставили файл с секретом в публичной директории? Проверьте свой webroot
Лежит ли файл с токеном или учётными данными в вашей публичной веб-директории (webroot)? Классическая ошибка, когда любой может скачать его по URL, ловушка размножения шаблона, где у каждого сайта одна и та же дыра, и как проверить свой сервер и закрыть её — через операционную призму этого сайта.
Для всех, кто держит несколько сайтов на общем/арендном хостинге или VPS, развёртывая в публичные директории (public/, public_html/, htdocs/ и т. д.). Без шагов атаки — только аудит своего сервера и закрытие дыр. О защите самого .env см. защита .env на общем хостинге.
Взгляд этого сайта: где вы это кладёте — ЭТО и есть контроль доступа
Секреты утекают больше из-за ошибок размещения, чем из-за хитрых атак. Webroot — это «место, откуда любой может скачать по URL». Положите секрет туда — и даже сильнейший пароль сервера бессмыслен. Основа этого сайта — держать секреты вне и webroot, и git (→ безопасное хранение секретов). Идея проста: публичная директория — это публичная полка. Кладите на неё только то, что не жалко показать.
public/ = скачивается любым через URL
Можно класть
изображения, CSS, JS — публичные ассеты
Никогда не класть
.env, token.json, .sql, .git, .bak
Выше корня приложения = не раздаётся
Кладите сюда
секреты, токены, учётные данные, резервные копии. Права 600 (чтение только владельцем). Недостижимо по URL.
Почему случаются «забытые файлы в публичной директории»
Распространённый паттерн — файл, положенный для удобства, или приехавший внутри заготовки, тихо остающийся публичным.
Например, JSON, хранящий токен доступа для стороннего интегрирования, долго лежит под public/ — и если он из общего шаблона, тот же файл скопирован в то же место на многих сайтах, поэтому у них всех одна и та же дыра. Исправить один сайт бессмысленно, если остальные открыты. Так же опасны: забытый .env, резервные копии базы данных (.sql), директория .git, резервные копии редактора (*.bak) и временные файлы (связано: обход пути · весь .env наружу).
Аудит своего сервера
Сначала механически выявите «любые похожие на секрет файлы в моей собственной публичной директории». Это инспекция своих собственных активов, а не подглядывание в чужой сайт.
Поищите под публичными директориями похожие на секрет файлы
public/ (JSON с токеном/учётными данными, .env, ключи, временные файлы).Предполагайте размножение — расширьте на каждый хост и сайт
Решите по каждому файлу, действительно ли он должен быть публичным
# audit under your own public directories (inspecting your own assets)
find ~ -path '*/public/*' \( -iname '*token*.json' -o -iname '*credential*.json' \
-o -iname '*.bak' -o -iname '*.sql' -o -iname '.env*' \) 2>/dev/null
# an exposed .git directory is dangerous too
find ~ -path '*/public/*/.git' -maxdepth 8 2>/dev/nullЧто делать, когда найдёте один
Сделайте три вещи как набор — удалить, отозвать, перенести. Пропустите любую — и дыра не закрыта полностью.
Удалить из webroot, чтобы URL не мог его скачать
Отозвать/переиздать любой ключ или токен, который мог утечь
Держать секреты вне webroot с правами 600
Размещение, в которое попадают (опасно)
- JSON-токен для интеграции лежит в
public/ - файл-секрет, приехавший в заготовке, остаётся публичным
- резервные копии (
.sql/.bak) или.gitоставлены под публичной директорией - исправить один сайт и считать «решено»
Правильное размещение
- публичная директория держит только то, чем можно публично делиться
- секреты живут вне webroot с правами 600
- чувствительные расширения запрещены к раздаче
- найти один и проверить каждый хост и сайт
Сделайте «только публично-безопасное» постоянным правилом
Правила лучше разовых исправлений. Решите, что публичная директория — это публичная полка, и как правило никогда не кладите туда секреты, резервные копии, данные системы контроля версий (.git) или файлы конфигурации. Обновляя заготовку, уберите секрет из самого шаблона — иначе каждый сайт, который вы массово создадите дальше, продолжит копировать ту же дыру.
Что делает сам этот сайт
Основа этого сайта — держать секреты — ключи, токены, строки подключения — вне и публичной директории, и репозитория кода. Артефакты развёртывания содержат только собранные публичные ассеты; секреты держатся как переменные окружения среды выполнения, в месте, которое не раздаётся. Причина: класс инцидента этой статьи — учебниковое «один забытый файл, и один URL утекает всё». Мы проектируем само размещение как контроль доступа и прогоняем этот аудит в том же ритме, что и инвентаризацию реагирования на уязвимости.
Читать дальше
- Стеки: защита .env на общем хостинге · руководство по реагированию на уязвимости (инвентаризация)
- Глоссарий: файлы .env и секреты · обход пути
- Инцидент: весь .env наружу
- Хранение: безопасное хранение секретов
FAQ
QПочему опасно класть файлы в публичную директорию?
Всё в публичной веб-директории (webroot — public/, public_html/ и т. д.) может скачать любой, кто обратится к её URL. Забытый JSON с токеном/учётными данными, .env, резервная копия или файл ключа извлекаются раньше, чем кто-то заметит, что ведёт к немедленному вреду. В публичной директории должно лежать только то, что безопасно делать публичным.
QЕсли нашёл один на сайте, проверять ли остальные?
Да. Если вы массово создаёте сайты из общего шаблона или заготовки, тот же забытый файл обычно размножен по всем. Найдите один и проверьте каждый сайт и хост того же происхождения.
QЧто делать, когда найду один?
1) Удалить файл из webroot, чтобы он возвращал 404 по URL. 2) Обновить/отозвать любой токен или ключ, который мог утечь (считайте, что утёк). 3) Впредь держать секреты вне webroot с правами 600 (чтение только владельцем). Сделайте все три как набор.