Автор: Андрей Пинчук | Certified Senior AEM Developer

Представьте ситуацию: вы спокойно спите и видите свой третий сон, как вдруг раздается телефонный звонок — недовольный клиент жалуется, что вся система недоступна. Согласитесь, подобные события — дискомфорт для жизни AEM-разработчика, всей команды и провайдера решения. Ничего не попишешь, ранний подъем и поиск решения впереди.

Чтобы в вашей профессиональной жизни не встречалось таких нерадостных моментов, расскажу о типичных проблемах безопасности и как от них лучше застраховаться.

Придерживаться буду такого плана:

1. Безопасность на уровне Author;
2. Безопасность на уровне Publish;
3. Безопасность диспатчера;
4. CSRF защита фреймворка;
5. 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 ^[1]:4502/.json может сбросить весь репозиторий в формате JSON представление.

Чтобы ваша работа на AEM стала более безопасной, фокусируйтесь на возможностях конкретных пользователей.

Не забудьте пройти по Adobe Security Checklist ^[2], и пускай с вашим проектом на AEM все будет стабильно хорошо.

Автор: Axamit_digital

Источник ^[3]