Руководство по безопасности Angular и аутентификации с помощью веб-токенов JSON

Angular - отличная платформа для создания гибких универсальных одностраничных приложений. Все стабильные выпуски Angular готовы к работе и развернуты большим количеством предприятий и пользователей по всему миру. Здесь мы сосредоточимся на аспектах безопасности Angular.

Веб-разработка заключается не в написании работающего кода, а в написании кода, надежного и не подверженного уязвимостям. Регулярно выявляется ряд общих уязвимостей для различных веб-приложений. Уязвимости могут просочиться через устаревшие зависимости, неправильные методы кодирования или нарушения при установке исправлений.

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

Регулярные обновления Angular и уязвимые зависимости

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

При огромном количестве сторонних библиотечных компонентов, доступных сегодня, разработка приложений без использования этих библиотек может оказаться сложной задачей. Иногда в библиотеках могут быть опубликованы уязвимости, которые злоумышленники могут злонамеренно использовать для ввода вредоносных данных или кода в приложения. Некоторые из хорошо известных уязвимостей включают CSRF, переполнение буфера, XSS и т. Д.

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

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

Всегда загружайте библиотеки из репозитория, например npm или GitHub
Используйте обновленные версии библиотек и избегайте устаревших пакетов
Отслеживайте уязвимости, выполняя аудит npm или используя инструмент анализа кода.
Регулярно посещайте ресурсы безопасности, такие как NVD (Национальная база данных уязвимостей) и CVE (Общие уязвимости и воздействия).

Предотвращение межсайтового скриптинга (XSS)

XSS позволяет злоумышленникам вводить клиентские скрипты на веб-страницы, к которым имеют доступ обычные пользователи. Этот код может нанести значительный ущерб. Например, можно украсть пользовательские данные или предпринять действия, выдающие себя за пользователя с намерением причинить вред. Вы можете узнать больше о XSS на сайте OWASP.

Angular Sanitization и контексты безопасности

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

Вот пример объявления в BrowserModule:

export const BROWSER_SANITIZATION_PROVIDERS: Array<any> = [
  {provide: Sanitizer, useExisting: DomSanitizer},
  {provide: DomSanitizer, useClass: DomSanitizerImpl},
];
@NgModule({
  providers: [
    BROWSER_SANITIZATION_PROVIDERS
    ...
  ],
  exports: [CommonModule, ApplicationModule]
})
export class BrowserModule {}

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

export enum SecurityContext { NONE, HTML, STYLE, SCRIPT, URL, RESOURCE_URL }
export abstract class DomSanitizer implements Sanitizer {
  abstract sanitize(context: SecurityContext, value: SafeValue|string|null): string|null;
  abstract bypassSecurityTrustHtml(value: string): SafeHtml;
  abstract bypassSecurityTrustStyle(value: string): SafeStyle;
  abstract bypassSecurityTrustScript(value: string): SafeScript;
  abstract bypassSecurityTrustUrl(value: string): SafeUrl;
  abstract bypassSecurityTrustResourceUrl(value: string): SafeResourceUrl;

Как вы могли заметить, есть два различных паттерна. Во-первых, это метод дезинфекции. Это идентифицирует «контекст», а также «ненадежное значение» и возвращает надежное значение.

Второй метод использует метод bypassSecurityTrustX, который фиксирует «ненадежное значение». Он основан на использовании значения и возвращает доверенный объект.

Метод Sanitize ()

В случае, если значение является доверенным для определенного контекста, метод sanitize предоставит безопасное значение в нем и будет использовать его напрямую. В противном случае значение в конечном итоге будет обработано, чтобы сделать его безопасным в зависимости от контекста безопасности.

Существуют три основные функции очистки ценностей:

Функция sanitizeHTML, которая очищает ненадежные значения HTML, анализируя их и проверяя свои токены.
Функция sanitizeStlye, которая очищает ненадежные стили или значения URL-адресов с помощью регулярных выражений.
Функция sanitizeURL, которая очищает ненадежные значения URL с помощью регулярных выражений.

Как отключить дезинфекцию

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

Вот пример:

import {BrowserModule, DomSanitizer} from '@angular/platform-browser'
@Component({
  selector: 'my-app',
  template: `
    <div [innerHtml]="html"></div>
  `,
})
export class App {
  constructor(private sanitizer: DomSanitizer) {
    this.html = sanitizer.bypassSecurityTrustHtml('<h1>DomSanitizer</h1><script>ourSuperSafeCode()</script>') ;
  }
}

Аутентификация в Angular с использованием веб-токенов JSON

Если вы собираетесь реализовать аутентификацию в Angular, лучше всего использовать систему аутентификации на основе JWT. Фактически, использование веб-токенов JSON - лучший выбор, если вы внедряете систему аутентификации в любом одностраничном приложении (SPA). Вкратце, JWT - это полезные данные JSON с цифровой подписью, закодированные в строковом формате, удобном для URL.

Полезная нагрузка, содержащаяся в токене, определяет сеанс пользователя. Это может означать, что он содержит данные, уникальные для пользователя, такие как userId или emailId. Чтобы подтвердить, что токен действителен, серверу необходимо проверить токен. Это означает, что серверу не нужно связываться с базой данных для проверки токена.

Токен становится недействительным по истечении срока его действия, и время истечения срока действия определяется при создании токена.

Краткое описание процесса аутентификации Angular

Когда пользователь создает учетную запись, сервер аутентификации создает новый токен и возвращает его клиентскому приложению.
Полезные данные токена назначают что-то уникальное для пользователя (например, userId) и дополнительные сведения, включая время истечения срока действия.
Интерфейс хранит этот токен где-то - предпочтительно в файле cookie, и добавляет токен в заголовок для всех запросов, которые он делает.
Сервер проверяет токен, и, если токен действителен, пользователь может получить доступ к запрошенному ресурсу.
Когда срок действия токена истекает, сервер декодирует и проверяет, соответствует ли полезная нагрузка данным в базе данных. Если да, создается новый токен.

Для получения дополнительной информации, относящейся к Angular, обратитесь к этой статье на Angular-University.io

Политика безопасности контента

CSP или политика безопасности контента - это дополнительный уровень безопасности, который помогает обнаруживать и блокировать определенные типы атак, включая XSS и внедрение данных. Целью таких атак является кража данных, распространение вредоносных программ и повреждение веб-сайтов.

Чтобы включить CSP, вам необходимо настроить свой веб-сервер так, чтобы он возвращал правильный HTTP-заголовок Content-Security-Policy. Вы можете найти подробные инструкции по включению CSP на сайте MDN.

Использование автономного компилятора шаблонов или компилятора AOT

Шаблоны Angular теоретически являются исполняемыми, поэтому теги HTML, выражения привязки и атрибуты в шаблонах считаются безопасными. Злоумышленник может совершить что-то вредоносное, если ему удастся проанализировать непредусмотренное значение в шаблоне.

Чтобы предотвратить такие нарушения, пользователи могут использовать автономные компиляторы шаблонов. Этот процесс также известен как внедрение шаблона.

Если вы используете Angular CLI, вы можете легко включить AOT:

ng build --aot
ng serve -aot

Избегайте прямого использования DOM API

К сожалению, встроенные в браузер DOM API не защищают приложение автоматически от уязвимостей. Например, «документ» - узел, доступный через «ElementRef», может содержать небезопасные методы.

Пользователи должны избегать прямого взаимодействия с DOM и использовать шаблоны Angular везде, где они доступны.

XSS-защита на стороне сервера

Проверка данных на стороне клиента обычно используется в косметических целях. Кто-то может попытаться сделать прямые вызовы API на серверную часть с намерением что-то сломать.

Все данные в коде на стороне сервера должны быть проверены и должны соответствующим образом ускользать, чтобы предотвратить уязвимости сервера XSS. Во многом это связано с тем, что внедрение кода шаблона в приложение Angular похоже на внедрение исполняемого кода непосредственно в приложение.

Рекомендуется, чтобы шаблоны Angular на стороне сервера не создавались с использованием языка шаблонов.

Уязвимости уровня HTTP

Angular поставляется со встроенной поддержкой, которая может помочь предотвратить пару распространенных уязвимостей HTTP - включение межсайтовых скриптов (XSSI) и подделку межсайтовых запросов (CSRF или XSRF).

Обе эти уязвимости необходимо блокировать в основном на стороне сервера. Однако Angular также помогает помощникам упростить интеграцию на стороне клиента.

Включение межсайтовых скриптов (XSSI)

XSSI, также известный как уязвимость JSON, позволяет веб-сайту злоумышленника получать доступ к данным с помощью JSON API. Такие атаки работают в старых браузерах, включая URL-адрес API через тег <script> после переопределения собственных конструкторов объектов JavaScript.

Серверы могут отражать такие атаки, используя префикс для всех ответов JSON и делая их неисполняемыми, используя строку «)]}’, \ n ».

Библиотека AngularHttpClient может читать и удалять строку «)]}’, \ n »из каждого ответа перед дальнейшим синтаксическим анализом.

Подделка межсайтовых запросов (XSRF)

XSRF, также известный как «атака в один клик» или «загрузка сеанса», представляет собой нарушение веб-сайта, при котором неавторизованные команды отправляются из веб-приложения, которому доверяет пользователь.

В обычных методах защиты от XSRF серверы приложений передают случайный токен аутентификации через cookie. Код получения считывает файл cookie и включает в токен настраиваемый заголовок запроса для каждого последующего запроса. Затем сервер сравнивает полученное значение cookie и значение заголовка запроса и отклоняет запрос в случае, если значения отсутствуют или не совпадают.

Причина, по которой этот метод эффективен, заключается в том, что все браузеры используют одну и ту же политику происхождения. Только код исходного веб-сайта может считывать файлы cookie с сайта и включать настраиваемые заголовки по запросу. Следовательно, только доверенное пользовательское приложение может прочитать файл cookie и добавить настраиваемый заголовок.

Сводка по безопасности Angular

Мы рассмотрели все детали безопасности, о которых вам нужно знать при создании компонентов в Angular. Важно серьезно относиться к безопасности (она не должна ограничиваться только интерфейсом). Что вы думаете о безопасности Angular? Дайте нам знать об этом в комментариях.

от Лимор Вайнштейн

Изначально опубликовано на GrapeCity.com