Безопасная архитектура аутентификации для Angular

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

Начинайте с активов и путей нападения, а не с библиотеки аутентификации. Нанесите на карту браузер, веб-источник размещения, сервер-посредник для интерфейса (BFF), API, поставщика идентификации, сторонние службы, каналы администраторов, cookie, токены, личные данные и доказательства для аудита. Учтите XSS, CSRF, кражу токена, подделку входа через CSRF, злоупотребление перенаправлением, фиксацию сеанса, перебор учётных записей, скомпрометированные зависимости, вредоносные расширения, общие устройства, одновременные вкладки, повтор запроса и внутренний доступ. Затем выберите архитектуру сеанса, остаточными рисками которой организация способна управлять и понятно объяснять их.

Сначала очертите активы, участников и границы доверия

Начертите каждую границу доверия и поток данных: перенаправление для авторизации, обратный вызов, обмен кода, создание сеанса, вызов API, обновление, дополнительное подтверждение личности, выход, отзыв и аудит. Для каждой границы запишите исполнителя вызова, учётные данные, ожидаемого издателя и получателя, способ передачи, веб-источник, защиту от повтора, предельное время, поведение ошибки и правила журналирования. Диаграмма последовательности часто выявляет предположения, теряющиеся внутри настроек SDK.

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

Определите цели безопасности и восстановления: допустимый срок сеанса, завершение по бездействию, условия дополнительного подтверждения, смену устройства и клиента системы, реагирование на захват учётной записи, задержку отзыва, доступность, конфиденциальность, срок хранения аудита и порядок работы поддержки. Назовите ответственных за поставщика идентификации, BFF, правила API, интеграцию интерфейса, заголовки безопасности, секреты, наблюдение и решения во время событий. Постройте модели угроз для показательных путей и повторно проверяйте границы при изменении веб-источников, поставщиков, встроенного содержимого, мобильных клиентов или регуляторных обязанностей.

Выбирайте модель сеанса по модели угроз

BFF с тем же веб-источником может не передавать токены доступа и обновления OAuth в JavaScript, а браузеру выдать непрозрачный cookie сеанса. Настройте cookie с атрибутами Secure, HttpOnly, подходящим правилом SameSite, узкими границами Path и узла, сменой значения и истечением срока на сервере. BFF добавляет инфраструктуру, состояние, ответственность за CSRF, авторизацию посредника, требования к мощности и поведение при отказе, однако может существенно сократить пути кражи токена.

Общедоступный клиент только в браузере может получать токены через Authorization Code с PKCE, если развёртывание и поставщик идентификации поддерживают необходимые средства контроля. Такой клиент не способен сохранить секрет. Отдавайте предпочтение краткосрочным токенам доступа в памяти, узко определённым получателям, привязке к отправителю там, где она доступна, смене токенов обновления по рекомендациям поставщика и осознанному восстановлению после перезагрузки. Постоянное хранилище браузера увеличивает опасность от внедрённого кода, расширений, общих устройств, резервных копий и устаревших сеансов; выбирайте его лишь по явному анализу угроз и удобства.

Cookie и токены на предъявителя отказывают по-разному, и ни один из этих способов не делает XSS безвредным. Cookie с HttpOnly может противостоять прямому чтению, но внедрённый код всё равно способен выполнять аутентифицированные действия со страницы; доступный для чтения токен можно также украсть и повторно использовать в другом месте. Опишите, какие угрозы уменьшает каждое средство, какие остаются и насколько быстро работают обнаружение и отзыв. Не используйте собственную криптографию, самодельные форматы токенов, учётные данные в URL или один перехватчик, который незаметно определяет всю модель безопасности.

Применяйте стандартные пути OIDC и проверяйте каждую границу

Используйте OpenID Connect для аутентификации, а OAuth — для делегированного доступа к API. Для браузерных клиентов применяйте Authorization Code с PKCE вместо неявного потока. Создавайте для каждой операции значения state, nonce и проверки PKCE с высокой энтропией, привязывайте их к браузерному контексту, начавшему операцию, требуйте точного совпадения зарегистрированных URI перенаправления и удаляйте служебные данные авторизации из видимых URL и истории, как только это позволяет протокол.

Используйте поддерживаемую библиотеку, соответствующую стандартам, и закрепите доверенную настройку издателя. В составляющей, ответственной за проверку, проверяйте издателя, получателя, подпись, разрешённые алгоритмы, срок действия, время начала действия, nonce, ответ авторизации и тип токена. API должен принимать только токены, выпущенные именно для него, и сверять области доступа или утверждения с серверными правилами ресурса. Не используйте ID-токен как общий токен доступа к API и не доверяйте ролям лишь потому, что интерфейс их раскодировал.

Спроектируйте нестандартные пути: пользователь отменяет действие, обратный вызов открывается в другой вкладке, отсутствует state, сервер авторизации недоступен, требуется согласие или MFA, часы различаются, ключи меняются, выбран неверный клиент системы или перенаправление продолжается после развёртывания. Используйте отдельный маршрут обратного вызова с минимумом зависимостей и безопасным текстом ошибки. Проверяйте смешивание ответов разных издателей, повтор кода, открытое перенаправление, подделку входа через CSRF, связывание учётных записей, поведение параметра prompt, восстановление прямой ссылки и выход у поставщика по его профилю соответствия.

Согласуйте истечение, обновление и одновременные запросы

Явно моделируйте время сеанса: истечение токена доступа, абсолютный предел серверного сеанса и предел бездействия, право на обновление, расхождение часов, последнюю проверку и необходимый уровень уверенности. Обновляйте достаточно рано для завершения важной работы, но добавляйте случайное смещение, чтобы развёртывание или общее время истечения не вызвали наплыв обновлений. Таймер клиента лишь помогает интерфейсу; сервер остаётся достоверным источником и может отозвать или отклонить сеанс при любом запросе.

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

Сохраняйте незавершённую работу, не ослабляя правила сеанса. После истечения приостановите чувствительные операции, оставьте разрешённые местные черновики, повторно аутентифицируйте пользователя, заново получите его возможности и серверные версии, а перед отправкой сверьте изменения. Дополнительное подтверждение личности должно быть привязано к задуманному рискованному действию и быстро терять силу. Проверяйте истечение во время загрузки, платежа, потоковой передачи, работы без сети, предварительной загрузки маршрута, SSR, замедления фоновой вкладки, сна устройства, одновременных вкладок, смены ключей, отозванного токена обновления и истечения времени ожидания после подтверждения сервером.

Рассматривайте XSS как событие уровня всего сеанса

Любой произвольный программный код, выполняющийся в веб-источнике приложения, может действовать с правами пользователя. Angular считает значения, привязанные к шаблону, недоверенными и очищает их в соответствии с контекстом безопасности, но прямые API DOM, сторонние виджеты, динамическая загрузка программного кода, небезопасный HTML и bypassSecurityTrust* могут перейти эту границу. Никогда не создавайте шаблоны Angular из данных пользователя. Оставляйте AOT включённым, проверяйте каждый обход доверия и создавайте доверенные значения как можно ближе к небольшому проверенному источнику.

Внедряйте многоуровневую защиту с помощью строгой политики безопасности содержимого (CSP) и принудительного применения Trusted Types там, где они поддерживаются. До написания политики составьте перечень программного кода, стилей, встроенных рамок, соединений, фоновых процессов браузера, форм и навигации; избегайте широких шаблонов и постоянного режима только для отчётов. Правильно создавайте nonce для каждого ответа или применяйте совместимую с размещением стратегию контрольных сумм и проверяйте кэширование CDN. Закрепляйте версии зависимостей, просматривайте и уменьшайте их, защищайте путь сборки и выпуска, удаляйте неиспользуемый код и изолируйте стороннее содержимое в ограниченных рамках или веб-источниках.

Уменьшайте ценность первоначального доступа через XSS: по возможности не передавайте долгосрочные учётные данные в JavaScript, сокращайте срок сеанса в чувствительных продуктах, требуйте серверной авторизации и дополнительного подтверждения для опасных действий, применяйте идемпотентность и подтверждение операций и скрывайте лишние данные, уже присутствующие на странице. Наблюдайте нарушения CSP и Trusted Types, не считая отчёты безупречным средством обнаружения. Проверяйте сохранённое, отражённое и DOM-внедрение, форматированный текст, URL, SVG, Markdown, предварительный просмотр файлов, локализацию, аналитику, виджеты поддержки, результат SSR и страницы ошибок.

Проектируйте защиту CSRF, CORS и источников вместе

CSRF имеет значение всякий раз, когда браузер автоматически добавляет аутентификацию, особенно cookie. Применяйте многоуровневую защиту: подходящее правило SameSite, токен против CSRF, привязанный к сеансу, серверную проверку доверенных Origin или Referer там, где это уместно, и собственные заголовки запросов для изменений через API. Поддержка XSRF в Angular помогает передавать значение из cookie в заголовок, но сервер должен выдать и проверить токен, а веб-источники развёртывания — соответствовать настройке.

CORS определяет, какие веб-источники браузера могут читать или отправлять определённые запросы между источниками; это не аутентификация и не авторизация API. Разрешайте точные источники, методы и заголовки; никогда не сочетайте доступ с учётными данными и отражённым произвольным источником. В испытаниях охватите предварительный запрос, перенаправления, ошибки, поведение CDN, кэш и Vary: Origin. Проверяйте источник и аутентификацию WebSocket отдельно. Не используйте GET для операций, изменяющих состояние, и отклоняйте простые запросы из других источников, когда договор API ожидает JSON и заголовки CSRF.

Нанесите настоящую структуру сайта на карту до выбора SameSite: узлы приложения и API, перенаправления поставщика идентификации, встроенные среды, собственные домены, старые поддомены и объединённый выход. Cookie для всего домена дают каждому поддомену влияние на общую границу учётных данных, поэтому отдавайте предпочтение границам одного узла и отделяйте недоверенные приложения. Проверяйте вредоносные веб-источники, соседние поддомены, отсутствующие и несоответствующие токены CSRF, источник со значением null, кэш предварительных запросов, перенаправления, подделку входа, отправку форм между сайтами и вызовы API вне браузера.

Завершайте нужные сеансы при выходе и отзыве

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

Используйте поддерживаемые механизмы выхода OpenID Connect, когда нужно завершить объединённый сеанс, и проверяйте перенаправление и состояние после выхода. Выход через передний канал, задний канал и по инициативе доверенной стороны (RP) имеет разные свойства доставки и доступности; не обещайте мгновенного глобального выхода, если среда его не обеспечивает. Меняйте или отменяйте сеансы после сброса пароля, восстановления учётной записи, смены роли или клиента системы, подозрения на кражу, действия администратора и изменения необходимого уровня уверенности.

Проектируйте отзыв с учётом и безопасности, и доступности. Кэшируйте правила или решения по токену лишь в пределах определённого срока устаревания, защищайте проверку действительности и хранилища сеансов от перегрузки и выбирайте продолжение или прекращение работы при отказе отдельно для каждого уровня риска. При необходимости показывайте пользователям активные сеансы и предоставляйте отзыв по устройству. Проверяйте выход без сети, недоступность поставщика, одновременные вкладки, кэш кнопки «Назад», одновременные обновление и отзыв, длительные запросы API, WebSocket, повторное использование украденного сеанса, переключение хранилища сеансов на резерв и возврат при переносе ключей или cookie.

Отслеживайте злоупотребления и отказы без записи секретов

Определите общий словарь событий безопасности для браузера, периферийного узла, BFF, API и поставщика идентификации: начало и результат входа, класс ошибки обратного вызова, создание и смену сеанса, результат обновления, отказ авторизации, дополнительное подтверждение, отклонение CSRF, подозрительный веб-источник, выход, отзыв, восстановление учётной записи и административное изменение. Передавайте идентификатор связи и безопасный псевдоним сеанса или участника, чтобы специалисты могли восстановить путь, не записывая учётные данные или личное содержимое форм.

Никогда не записывайте коды авторизации, токены доступа или обновления, cookie сеансов, секреты клиента, пароли, значения MFA, необработанные утверждения о личности, полные URL с чувствительными параметрами запроса или личные тела API. Скрывайте данные при сборе, а не только при показе, и управляйте доступом, сроком хранения, выгрузкой и удалением. Оповещайте о содержательных закономерностях: повторных расхождениях state или nonce, повторном использовании токена обновления, невозможной смене сеанса, всплесках отказов между клиентами системы, отказах CSRF, необычном восстановлении или новом нарушении CSP после выпуска; одновременно ограничивайте частоту диагностических событий, которыми управляет нападающий.

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

• Опишите доверие до написания кода: зафиксируйте активы, участников, веб-источники, перенаправления, учётные данные, издателей, получателей, защиту от повтора, авторизацию, восстановление, владельцев и остаточный риск.
• Осознанно выберите модель сеанса: сравните BFF того же веб-источника и браузерный клиент с токеном по XSS, CSRF, повтору, хранению, инфраструктуре, доступности, удобству, отзыву и эксплуатационным возможностям.
• Внедрите протокол без самодельных замен: используйте OIDC Authorization Code с PKCE, строгую проверку перенаправления и привязки операции, поддерживаемые библиотеки, проверку издателя и получателя и серверную авторизацию.
• Сдерживайте захват браузера: сохраняйте очистку Angular, проверяйте обходы доверия, применяйте CSP и Trusted Types, уменьшайте число сторонних средств, защищайте зависимости и сборки и ограничивайте ценность сеанса.
• Завершите жизненный цикл сеанса: согласуйте обновление, одновременные запросы, истечение, дополнительное подтверждение, защиту CSRF и источников, объём выхода, отзыв, кэшированные данные, вкладки, устройства и объединённые сеансы.
• Работайте с безопасными доказательствами: связывайте события безопасности без секретов, выявляйте злоупотребления, измеряйте влияние на пользователя и задержку отзыва, отрабатывайте события, выпускайте поэтапно и проверяйте возврат.