Когда люди думают об утечках данных, они часто представляют себе изощренную внешнюю атаку. На практике одна из распространенных точек входа выглядит гораздо проще:  файл, который вы разместили в публичной директории, а затем забыли про него. Бэкап, сделанный посреди работы, дамп базы данных, копия конфигурационного файла. Если кто-то знает URL, всё, что нужно — это браузер. Эта статья объясняет, почему так происходит, как спокойно проверить собственный сайт и какой принцип размещения помогает этого избежать: вообще не хранить такие файлы в публичной директории.

Почему появляются забытые файлы

На виртуальном хостинге всё, что находится внутри  публичной директории ( public_html  или аналогичной), как правило, доступно по URL. Всё, что вы туда помещаете, воспринимается точно так же, как и то, что вы опубликовали намеренно.

Забытые файлы обычно появляются в ходе рутинной работы:

  • Вы сделали архив перед обновлением или миграцией «на всякий случай» в той же папке
  • Вы выгрузили базу данных и использовали публичную папку как временное место перед скачиванием
  • Вы сохранили копию конфига под другим именем перед редактированием
  • Вы оставили тестовую страницу или черновик после проверки чего-либо

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

Что может быть раскрыто

Масштаб последствий во многом зависит от того, что содержит файл.

  •  Дампы баз данных: посты, записи пользователей и отправленные формы в одном месте. Пароли обычно хранятся в преобразованном (хешированном) виде, но адреса электронной почты, имена и другой контент часто читаются как есть
  •  Архивы всего сайта: если они включают конфигурационный файл, вместе с ними утекают данные для подключения к базе данных и ключи аутентификации
  •  Переименованные копии конфигов: настоящий конфигурационный файл исполняется как PHP, поэтому его содержимое не выводится на экран. Однако копия с измененным расширением  может отдаваться как обычный текст. Именно это упускают из виду чаще всего
  •  Файлы логов и отладки: внутренние пути и детали ошибок (рассматриваются в отдельной статье)

Третий пункт — типичное «слепое пятно». Мысль «Конфиг написан на PHP, поэтому его никто не сможет прочитать» перестает работать для переименованной копии.

Как проверить собственный сайт

Эту проверку нужно выполнять спокойно, на  собственном сервере и собственном сайте.

1. Проверьте файлы по расширению

Если у вас есть доступ по SSH, поищите в публичной директории расширения, которые обычно используются для бэкапов и дампов.

 cd ~/example.com/public_html
find . -type f \( -name "*.sql" -o -name "*.zip" -o -name "*.tar.gz" -o -name "*.bak" -o -name "*.old" -o -name "*.orig" -o -name "*~" \) -ls
 

Без SSH поможет обычный просмотр той же папки в SFTP-клиенте. Старые файлы, создание которых вы не помните, попадают в зону риска.

2. Убедитесь, доступен ли файл на самом деле

Существование файла и возможность  получить его снаружи — это разные вещи. Для всего подозрительного запросите его URL через браузер или  curl  и посмотрите на ответ.

 curl -s -o /dev/null -w "%{http_code}\n" https://example.com/path-to-the-file
 

Код  200  означает, что файл можно скачать извне. Код  403  или  404  означает как минимум то, что данный URL не отдает файл, но конфигурация сервера может отличаться для разных путей, поэтому не воспринимайте ответ «он не загрузился» как разрешение оставлять файл на месте.

3. Также проверьте поисковые системы

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

Что делать, если вы что-то нашли

Сначала  удалите файл или переместите его за пределы публичной директории. Затем:

  •  Проверьте, что в нем содержалось: для дампа или копии конфига выясните, какая именно информация там была
  •  Замените учетные данные, если они там были: если внутри находились пароли от базы данных или ключи аутентификации (соли) из  wp-config.php , удаления файла недостаточно. Допустите вероятность того, что файл был доступен какое-то время, и сгенерируйте новые значения
  •  Изучите логи доступа: посмотрите, есть ли в логах запросы к этому файлу. Если да, то его могли скачать. Если следов нет, это всё равно не доказывает обратное
  •  Если затрагивалась личная информация: в зависимости от масштаба могут применяться юридические обязательства (об этом будет рассказано в отдельной статье)

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

Принципы размещения: вообще не храните файлы в публичном пространстве

Разовая проверка менее эффективна, чем привычки, снижающие вероятность что-то забыть.

  •  Держите рабочие файлы вне публичной директории: используйте место, на которое не ссылается ни один URL, например прямо в домашней директории
  •  Храните бэкапы отдельно от сайта: не в публичной зоне того же сервера. Определите, у кого есть доступ к этому хранилищу
  •  Не храните копии под другими именами: сохранение  wp-config.php.bak  рядом с оригиналом навлекает проблемы. Используйте систему контроля версий или непубличное расположение
  •  Добавьте подтверждение очистки в каждую задачу: добавьте одну строчку в шаги по обновлению или миграции: «рабочие файлы удалены»
  •  Регулярно проводите аудиты: выполнение описанной выше проверки во время ежемесячного обслуживания сокращает количество мусора, который залеживается на сервере

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

Итоги

  • Всё, что находится в публичной директории, как правило, доступно по URL, поэтому забытый рабочий файл может стать точкой входа для утечки
  • Наибольший урон наносят дампы баз данных, архивы всего сайта и переименованные копии конфигов
  • Проверяйте собственный сайт по расширениям, по фактическому ответу сервера и через поисковые системы
  • Если вы нашли такой файл, удалите или переместите его, замените все учетные данные, которые там хранились, и проверьте логи доступа
  • В долгосрочной перспективе сделайте привычкой: держите файлы вне публичного пространства, подтверждайте очистку в конце каждой задачи и регулярно проводите аудит

Обслуживание сайтов неизбежно создает файлы. Относитесь к их удалению как к части той же самой задачи.