Базовая HTTP аутентификация

Вчера в Telegram канале MODX была дискуccия на тему — зачем ставить базовую аутентификацию на папки core, connectors и manager, если при запросах к ним отдаётся 403? Давайте попробуем прояснить данный вопрос.

Все три указанные папки являются системными. Т.е. они не содержат файлы и картинки, к которым нужно обращаться напрямую с сайта. Ну может кто-то на фронте использует ExtJS из manager. Но думаю, таких разработчиков единицы.

• Папка core — это ядро системы, в которой располагаются файлы самой системы и установленных компонентов.
• В папке manager находится всё необходимое для работы админки. Если присмотреться, то можно увидеть полноценную структуру сайта, но только для администраторов. Свои ассеты, шаблоны, скрипты, шаблонизатор Smarty.
• В папке connectors находится точка входа для всех запросов админки — данные для дерева ресурсов, элементов, файлов, при сохранении ресурсов и т.д. Это диспетчер, который перенаправляет все аякс запросы на соответствующие системные процессоры. Попробуйте в админке нажать F5 и посмотрите в консоли, сколько запросов идёт на коннектор.

Давайте сделаем запрос в каждую из этих папок. Начнём с папки manager — site.ru/manager. В ответ нам откроется страница входа с полями для логина и пароля. Ок.
Запрашиваем site.ru/connectors. И видим такой ответ:

{"success":false,"message":"Доступ запрещён.","total":0,"data":[],"object":{"code":401}}

Т.е. мы видим, что в этих папках отработали какие-то скрипты. Это потому, что в них находятся файлы index.php, которые и обрабатывают запрос.

Дальше пробуем последний запрос site.ru/core. Сервер нам выдает «403 Forbidden». У него в правилах доступа в файле .htaccess указано «Deny from all». Т.е. доступ к папкам и файлам запрещён.

Давайте теперь проанализируем полученные результаты. Начнём с папки manager. Как я уже говорил, в нём лежит структура страниц админки. В ней ничего особо интересного для взлома нет — вся логика в процессорах, которые расположены в core, к которым обращаются через коннектор. Но было бы полезно с точки зрения безопасности закрыть доступ к странице логина от всяких брутфорсеров.

Что у нас с connectors? Точка входа — index.php. И тут важная задача — отфильтровать правильные запросы от посторонних. А правильные запросы — это запросы из админки. Для их идентификации используется токен HTTP_MODAUTH, который должен присутствувать с запросе. Если его подсмотреть в сессии, то можно спокойно сделать, например, запрос типа site.ru/connectors/?&action=resource/getNodes&node=rood&HTTP_MODAUTH=ТОКЕН. Но умельцы уже несколько раз находили дырки в данном механизме проверки. В результате — срочный апдейт безопасности сайта. Последняя дыра в коннекторе phpthumb явилась причиной взломов тысячи сайтов.

Ну и осталась папка core. Вроде бы с ней всё понятно. Она должна быть закрыта от всех запросов. Но стоит в гугле забить, например, «inurl:core/components/ace» и вот те на, несчётное количество сайтов со всей подноготной ядра. И никаких тебе 403.

Поэтому лучше перестраховаться. И самый простой вариант — базовая HTTP аутентификация. Чем она поможет? При любых запросах в выше указанные папки, сервер просит аутентифицироваться. Т.е. послали запрос на site.ru/manager, site.ru/core или site.ru/connectors, будьте добры ввести логин и пароль. А если вы уже прошли базовую аутентификацию при входе в админку, то все запросы к коннектору вам в текущем сеансе разрешены. Вам уже не нужно вводить пароль на каждый запрос из админки на коннектор.

Тут важно понимать, что базовая аутентификация не даёт 100% гарантии защиты. Она доступна для брутфорса. И если нацелились конкретно на ваш сайт, то вопрос защиты переходит к серверу — настроен ли он для отражения такой атаки. Для NGINX обычно используют fail2ban. Но от роботов/ботов HTTP аутентификация спасёт на 100%. Есть ещё один вариант — настроить доступ по IP, если он постоянный.

У некоторых разработчиков возникает вопрос — не закрывает ли базовая аутентификация доступ скриптам? Можно ли обращаться к классам системы или компонентов и тем же процессорам из других скриптов? Ответ легко открывается, если понимать, что базовая аутентификация работает при запросе к HTTP серверу, а скрипты работают на уровне файловой системы, т.е. на другом физическом уровне, где работают уже права доступа. Таким образом, на include/require, loadClass() и runProcessor() базовая аутентификация никак не влияет.

Надеюсь, статья оказалась полезной. Если да, кивните.