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

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

HTTP запросов с сайта к файлам, расположенным в папках core и connectors (да и в manager тоже), быть не должно! Ни запросов пользователя, ни запросов компонентов!

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

    К слову!

    Евгений Борисов как-то рассказывал про уязвимость в коннекторах, которая наделала много шума несколько лет назад. Тогда проверка токена строилась на isset(). Если токен есть — проходи, причём значение не важно. Это для информации тем, кто верит в непогрешимость кодеров MODX.

    Ну и осталась папка 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() базовая аутентификация никак не влияет.

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

    19 октября 2018, 09:04   304     7

    Комментарии ()

    1. Vladimir 19 октября 2018, 16:20 # +1
      Спасибо.
      :v
      1. Сергей Шлоков 19 октября 2018, 16:55 # +1
        Володь, ты мой главный читатель. :q
        1. Vladimir 19 октября 2018, 16:58 # +1
          Если да, кивните.
          ленятся люди «кивнуть» ))
          1. Сергей Шлоков 19 октября 2018, 17:09 # 0
            Некоторые в телеграме «кивнули». :)
      2. Андрей 11 ноября 2018, 15:12 # 0
        Спасибо. Полезное знание. но вас не все читают…
        1. Сергей Шлоков 11 ноября 2018, 15:37 # 0
          Значит они меньше знают. :r
          1. Андрей 11 ноября 2018, 15:46 # 0
            Точняк :v

        Вы должны авторизоваться, чтобы оставлять комментарии.

        Выделите опечатку и нажмите Ctrl + Enter, чтобы отправить сообщение об ошибке.