Автор: Андрей Пинчук | Certified Senior AEM Developer
Представьте ситуацию: вы спокойно спите и видите свой третий сон, как вдруг раздается телефонный звонок — недовольный клиент жалуется, что вся система недоступна. Согласитесь, подобные события — дискомфорт для жизни AEM-разработчика, всей команды и провайдера решения. Ничего не попишешь, ранний подъем и поиск решения впереди.
Чтобы в вашей профессиональной жизни не встречалось таких нерадостных моментов, расскажу о типичных проблемах безопасности и как от них лучше застраховаться.
Придерживаться буду такого плана:
- Безопасность на уровне Author;
- Безопасность на уровне Publish;
- Безопасность диспатчера;
- CSRF защита фреймворка;
- DDoS атаки.
Базовые советы по защите Adobe Experience Manager
Мир проектов на AEM станет еще лучше, если каждый разработчик, будет владеть общим пониманием того, как можно в целом защитить платформу от утечки данных. Согласно схеме ниже, у нас есть автор, несколько паблишей и два или более диспатчеров (так называемые балансеры). По сути, этим трём уровням и стоит в первую очередь уделить внимание в плане защиты данных. Это классические правила работы, которые общеприняты в AEM-сообществе по всему миру.
1. Использовать HTTPS. AEM быстро развивается, предоставляет гибкие возможности для создания автора на другом более защищенном протоколе. Достаточно сгенерировать ключ “SSL Wizard”, создать путь к нему и, таким образом, использовать более защищенный протокол. В рекомендациях от Adobe — этот шаг как раз и является первоочередным в безопасности.
2. Установка пакетов с последними обновлениями. Стандартный процесс разработчика сводится к тому, что при работе над компонентами и сервисами решения приходится искать в Google. Цель этого шага — регулярно следить за Service pack & Hot Fixes. Тогда уходят очень многие проблемы, в том числе и связанные с сохранностью данных. Хотя это и не панацея, но важный момент — держать систему в актуальном состоянии.
3. Создание аккуратных страниц с сообщениями об ошибках. Если изначально сделать страницу с кратким описанием ошибки, клиент сразу увидит, что не работает, в то время как девелопер уже будет в процессе решения проблемы. Логично, что эта информация не пройдет мимо вас, но вы избежите паники от клиента и тестировщиков, путаницы в задачах.
4. Отказаться от установки пароля и логина на «admin-admin». Как бы не было смешно, но проблема с некачественными логином и паролем достаточно распространена даже в AEM. По итогу в погоне за скоростью или другими соображениями мы получаем максимально уязвимую систему. Как только вы обнаружили, что установлены примитивные данные для входа, постарайтесь убедить команду/начальство и поменять их на более надежные как можно скорее.
Безопасность на Author-уровне
Во-первых, пользуйтесь vpn. Использование Virtual Protected Network — это работа защищенной приватной сети для установки защищенного соединения между вами и сервером. Это простой и важный инструмент: так ваш трафик будет зашифрован, вычислить, откуда отправляете свои данные невозможно. Получается, с vPn никто не сможет получить доступ к вашему инстанс.
Такой подход подойдет удаленным разработчикам и всем тем, чья работа ведется из разных локаций с нестабильным интернет-соединением.
Во-вторых, ваш “автор” всегда должен быть закрыт, в том числе из Google. Так можно подобрать пароль и взломать систему: по неосторожности автор может быть проиндексирован. Чтобы проверить вашу уязвимость в поисковике, наберите в его строке свой домен и автора и путь к crx. Да, можно обращаться в Yandex или Google с просьбой удалить такую строку в выдаче. Но, пока вопрос решается, система уже будет общедоступная.
В-третьих, не недооценивайте привилегии пользователя “admin”, у которого чаще всего есть возможность совершать любые доступные операции.
Это особенно критично на момент, когда сотрудник прощается с компанией. Ведь у большинства бизнесов доступ к инстанс не персональный, а через один администраторский аккаунт. Логичнее сделать наоборот и быть в курсе конкретных изменений в системе от конкретного автора.
В версии AEM 6.1 появился новый подход, когда можно задать конкретные права для бандла или сервиса пользователя. Но все же лучше сделать именной профиль: и сотруднику приятно, и бизнесу проще отслеживать, у кого какие уровни доступа в систему. Такой подход актуален для уровней автора и паблиша.
Безопасность на Publish-уровне
Как правило, только спустя продолжительное время на проекте замечают, что не сделали проверку анонимного пользователя. И в то время, как у обычного пользователя могут быть ограничения по операциям, у анонимного — часто случается, намного больше прав на выполнение операций.
Фильтр Apache Sling Referrer — удобный и действенный механизм сделать безопасным ваше приложение. Например, отправляете метрики в AEM, вы видите в Inbox информацию об отправке данных. Если вы превышаете дефолтное значение, сторонняя система может отправить этот запрос. Это значит, что кто угодно не сможет направить запрос. Вы заносите домен в конфигурацию, она в момент запроса сверяет его с изначально занесенными данными и, если все совпадает, интеграция происходит.
С фильтром получится провести более гибкую настройку: указать можно запрос, метод, хост. Также там есть пустое значение или звездочка для более детальных запросов.
Безопасность на Dispatcher-уровне
Девелоперы сталкиваются с диспатчем в 10% случаев. Итак, это основной конфигурационный файл, где мы задаем тип урла (запрещающий / разрешающий).
Обычно разработчики делают маленький таск, создают правило и забыли, что оно добавит уязвимость. Чтобы никто не попытался атаковать ваш инстанс, нужно проверить url с селекторами на момент доступности.
Через конфигурационный файл можно указать обработку заголовков. Потому что чем более точно укажете заг, метод и т.д, такая детальная настройка точно ничего не поломает. Это элементарные примеры. Что если таких правил сотни и навигация по ним сложнее?
Самый простой способ — включить логирование. В зависимости от версии Apache, может чуть меняться механизм работы. Но вам система сразу подсветит, по какому url какое конкретно правило у вас отрабатывает и что все еще необходимо подправить.
Также в правилах можно указывать домены: это — отсылка к интерграции.
Раз диспатчер используется для кеширования, запросы выполняются в разы быстрее: не нужно никуда ходить и проверять, и можно сразу отдавать клиенту. Плюс такой способ сильно повышает безопасность вашего приложения.
Cross Site Request Forgery — подделка запроса.
Общий принцип работы CSRF: предположим, на сайте банка вы используете свой аккаунт. После авторизации у вас есть стандартная сессия с cookies в браузере, получаете письмо и переходите по ссылке на подозрительный сайт. На нем злоумышленник встроил форму, при заполнении которой ваши данные отправляются на сайт банка.
Дело — в HTTP протоколе. Злоумышленнику не нужно много данных: достаточного этого запроса. Сервер банка увидит: пришел запрос, есть cookies и сессия, все впорядке. Так работают типичные атаки.
Что может дать AEM, чтобы предотвратить подделки запросов
Классический пример защиты — генерация “секрета” в строку. Когда генерируется форма, этот секретный токен добавляется из скрытого поля. Если зайти на сайт злоумышленника, система обнаружит отсутствие токена или его невалидность и откажет в отправке данных. Иногда делают защиту от самих пользователей.
Теперь у вас обычный ajack, в которое скрытое поле не добавить. На стадии авторизации сервер возвращает вам cookie с название с SCRF, перекладываете ее в заголовок, отправляете на сервер. Так вы подписали запрос.
AEM сделает за вас все: сгенерирует ключи, токены, будет проверять отправку формы
Бывают кейсы, когда приложение пишут на React и есть сложный момент с интеграцией. В AEM учли эту ситуацию: достаточно сходить на inpoint и подписать это на проверку. Подходит, когда используете нестандартные компоненты и библиотеки.
Что еще можно сделать для защиты системы:
- Библиотеки, которые за это отвечают. Смысла добавлять нету, пока у вас ничего не ломается.
- На low level можно посмотреть все “секреты”. Это эдакая проверка ваших данных на валидность.
- Все просто: есть готовый api и вы уже защищены от такого вида атак.
Атака DDOS — вторая по популярности атака
Целью является — исчерпать физические возможности сервера. Делаются миллионы запросов по какому-то хосту. Когда их становиться бесконечно много, система и начинает физически не справляться. Как правило, атакуют мощно из нескольких источников, используют VPN. На 100% от такого не застрахован никто; но давайте не будем им помогать.
В каких случаях система уязвима:
- Конфигурируем систему с неправильным суффиксом;
- Много запросов на avs, диспатчер на паблише не может их форварднуть;
- Когда не запрещен вывод неограниченного количества узлов контента. В частности, рендерер JSON, который может пересекать древовидную структуру по нескольким уровням.
- localhost:4502/.json может сбросить весь репозиторий в формате JSON представление.
Чтобы ваша работа на AEM стала более безопасной, фокусируйтесь на возможностях конкретных пользователей.
Не забудьте пройти по Adobe Security Checklist, и пускай с вашим проектом на AEM все будет стабильно хорошо.
Автор: Axamit_digital
