Проєктування безпечної автентифікації для 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 і джерел, обсяг виходу, відкликання, кешовані дані, вкладки, пристрої й об’єднані сеанси.
• Працюйте з безпечними доказами: пов’язуйте події безпеки без секретів, виявляйте зловживання, вимірюйте вплив на користувача й затримку відкликання, відпрацьовуйте події, випускайте поетапно та перевіряйте повернення.