Безопасность

В этой статье описывается встроенная защита Angular от распространенных уязвимостей веб-приложений и атак, таких как межсайтовые скриптовые атаки. Он не охватывает безопасность на уровне приложений, такую как аутентификация (Кто этот пользователь?) И авторизация (Что может сделать этот пользователь?).

Лучшие практики

• Будьте в курсе последних выпусков библиотеки Angular. Мы регулярно обновляем библиотеки Angular, и эти обновления могут исправлять дефекты безопасности, обнаруженные в предыдущих версиях. Проверьте журнал изменений Angular на наличие обновлений, связанных с безопасностью.
• Не изменяйте свою копию Angular. Частные, настроенные версии Angular, как правило, отстают от текущей версии и могут не включать важные исправления и улучшения безопасности. Вместо этого, поделитесь своими улучшениями Angular с сообществом и сделайте запрос на извлечение.
• Избегайте использования Angular API, помеченного в документации как «Угроза безопасности». Для получения дополнительной информации см. Раздел «Надежные безопасные значения» на этой странице.

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

Межсайтовый скриптинг (XSS) позволяет злоумышленникам внедрить вредоносный код в веб-страницы. Такой код может, например, украсть пользовательские данные (в частности, данные для входа в систему) или выполнить действия, чтобы выдать себя за пользователя. Это одна из самых распространенных атак в сети.

Чтобы блокировать атаки XSS, вы должны предотвратить попадание вредоносного кода в DOM (объектную модель документа). Например, если злоумышленники могут заставить вас вставить тег <script> в DOM, они могут запустить произвольный код на вашем веб-сайте. Атака не ограничивается тегами <script> - многие элементы и свойства в DOM позволяют выполнять код, например, <img onerror = "..."> и <a href="javascript:...">. Если данные, контролируемые злоумышленником, попадают в DOM, следует ожидать уязвимостей безопасности.

Модель безопасности межсайтовых скриптов Angular

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

Угловые шаблоны аналогичны исполняемому коду: HTML, атрибуты и выражения привязки (но не связанные значения) в шаблонах считаются безопасными. Это означает, что приложения должны предотвращать попадание значений, которые злоумышленник может сделать, в исходный код шаблона. Никогда не создавайте исходный код шаблона, объединяя пользовательский ввод и шаблоны. Чтобы предотвратить эти уязвимости, используйте автономный компилятор шаблона, также известный как внедрение шаблона

Санитарная обработка и безопасность

Санитарная обработка - это проверка ненадежного значения, превращение его в значение, которое безопасно вставить в DOM. Во многих случаях санитарная обработка вообще не меняет ценности. Санитарная обработка зависит от контекста: значение, которое является безвредным в CSS, потенциально опасно в URL.

Angular определяет следующие контексты безопасности:

• HTML используется при интерпретации значения как HTML, например, при привязке к innerHtml.
• Стиль используется при привязке CSS к свойству стиля.
• URL используется для свойств URL, таких как <a href>. </a>
• Ресурсный URL-адрес - это URL-адрес, который будет загружен и выполнен в виде кода, например, в <script src>.

Angular очищает ненадежные значения для HTML, стилей и URL; очистка URL-адресов ресурсов невозможна, поскольку они содержат произвольный код. В режиме разработки Angular выводит на консоль предупреждение о необходимости изменения значения во время очистки.

Прямое использование DOM API и явные вызовы очистки

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

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

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

Политика безопасности контента (CSP) - это метод глубокой защиты от XSS. Чтобы включить CSP, настройте веб-сервер так, чтобы он возвращал соответствующий HTTP-заголовок Content-Security-Policy. Узнайте больше о политике безопасности контента в разделе Введение в политику безопасности контента на веб-сайте HTML5Rocks.

Используйте автономный компилятор шаблонов

Автономный компилятор шаблонов предотвращает целый класс уязвимостей, называемых внедрением шаблонов, и значительно повышает производительность приложений. Используйте автономный компилятор шаблонов в рабочих развертываниях; не динамически генерировать шаблоны. Angular доверяет шаблону кода, поэтому генерация шаблонов, в частности шаблонов, содержащих пользовательские данные, обходит встроенные средства защиты Angular. Для получения информации о динамическом построении форм безопасным способом см. Страницу руководства Dynamic Forms.

Защита XSS на стороне сервера

HTML, созданный на сервере, уязвим для инъекционных атак. Внедрение кода шаблона в приложение Angular аналогично внедрению исполняемого кода в приложение: оно дает злоумышленнику полный контроль над приложением. Чтобы предотвратить это, используйте язык шаблонов, который автоматически экранирует значения, чтобы предотвратить уязвимости XSS на сервере. Не генерируйте угловые шаблоны на стороне сервера, используя язык шаблонов; это влечет за собой высокий риск внедрения уязвимостей при внедрении шаблонов.

Доверие безопасным ценностям

Иногда приложениям действительно необходимо включать исполняемый код, отображать <iframe> из некоторого URL-адреса или создавать потенциально опасные URL-адреса. Чтобы предотвратить автоматическую очистку в любой из этих ситуаций, вы можете сообщить Angular, что вы проверили значение, проверили, как оно было сгенерировано, и убедились, что оно всегда будет безопасным. Но будь осторожен. Если вы доверяете значению, которое может быть вредоносным, вы внедряете уязвимость безопасности в свое приложение. Если вы сомневаетесь, найдите профессионального эксперта по безопасности.

Чтобы пометить значение как доверенное, введите DomSanitizer и вызовите один из следующих методов:

• bypassSecurityTrustHtml
• bypassSecurityTrustScript
• bypassSecurityTrustStyle
• bypassSecurityTrustUrl
• bypassSecurityTrustResourceUrl

Помните, является ли значение безопасным, зависит от контекста, поэтому выберите правильный контекст для предполагаемого использования значения. Представьте, что следующий шаблон должен привязать URL к вызову javascript: alert (...):

Код TypeScript:

<h4>An untrusted URL:</h4>
<p><a class="e2e-dangerous-url" [href]="dangerousUrl">Click me</a></p>
<h4>A trusted URL:</h4>
<p><a class="e2e-trusted-url" [href]="trustedUrl">Click me</a></p>

Демонстрация в реальном времени:

Смотрите Pen KYrqEX от w3resource ( @ w3resource ) на CodePen .

Обычно Angular автоматически очищает URL-адрес, отключает опасный код и в режиме разработки записывает это действие на консоль. Чтобы предотвратить это, пометьте значение URL-адреса как надежный URL-адрес с помощью вызова bypassSecurityTrustUrl:

Код TypeScript:

constructor(private sanitizer: DomSanitizer) {
  // javascript: URLs are dangerous if attacker controlled.
  // Angular sanitizes them in data binding, but you can
  // explicitly tell Angular to trust this value:
  this.dangerousUrl ='javascript:alert("Hi there")';
  this.trustedUrl = sanitizer.bypassSecurityTrustUrl(this.dangerousUrl);
  
  

Демонстрация в реальном времени:

См. Конструктор перехода Pen с помощью w3resource ( @ w3resource ) в CodePen .

Если вам нужно преобразовать пользовательский ввод в доверенное значение, используйте метод контроллера. Следующий шаблон позволяет пользователям вводить идентификатор видео YouTube и загружать соответствующее видео в <iframe>. Атрибут <iframe src> является контекстом безопасности URL-адреса ресурса, поскольку ненадежный источник может, например, осуществлять контрабанду при загрузке файлов, которую могут выполнять ничего не подозревающие пользователи. Поэтому вызовите метод на контроллере для создания надежного URL-адреса видео, в результате чего Angular разрешит привязку в <iframe src>:

Код TypeScript:

<h4>Resource URL:</h4>
<p>Showing: {{dangerousVideoUrl}}</p>
<p>Trusted:</p>
<iframe class="e2e-iframe-trusted-src" width="640" height="390" [src]="videoUrl"></iframe>
<p>Untrusted:</p>
<iframe class="e2e-iframe-untrusted-src" width="640" height="390" [src]="dangerousVideoUrl"></iframe>

Демонстрация в реальном времени:

См. Pen jRQwvm от w3resource ( @ w3resource ) в CodePen .

Код TypeScript:

updateVideoUrl(id: string) {
  // Appending an ID to a YouTube URL is safe.
  // Always make sure to construct SafeValue objects as
  // close as possible to the input data so
  // that it's easier to check if the value is safe.
  this.dangerousVideoUrl ='https://www.youtube.com/embed/' + id;
  this.videoUrl =
      this.sanitizer.bypassSecurityTrustResourceUrl(this.dangerousVideoUrl);
}

Демонстрация в реальном времени:

См. Pen jRQwQw от w3resource ( @ w3resource ) в CodePen .

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

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

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

В подделке межсайтовых запросов (CSRF или XSRF) злоумышленник обманом заставляет пользователя посетить другую веб-страницу (например, evil.com) со злонамеренным кодом, который тайно отправляет вредоносный запрос на веб-сервер приложения (такой как example- bank.com).

Предположим, что пользователь вошел в приложение на example-bank.com. Пользователь открывает электронное письмо и щелкает ссылку на evil.com, которая открывается в новой вкладке.

Страница evil.com немедленно отправляет вредоносный запрос на example-bank.com. Возможно, это запрос на перевод денег со счета пользователя на счет злоумышленника. Браузер автоматически отправляет файлы cookie example-bank.com (включая файлы cookie для аутентификации) вместе с этим запросом.

Если на сервере example-bank.com отсутствует защита XSRF, он не может определить разницу между законным запросом от приложения и поддельным запросом evil.com.

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

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

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

HttpClient от Angular имеет встроенную поддержку клиентской части этого метода. Подробнее об этом читайте в руководстве HttpClient.

Для получения информации о CSRF в открытом проекте обеспечения безопасности веб-приложений (OWASP) см. Шпаргалку по предотвращению подделки межсайтовых запросов (CSRF). Документ Стэнфордского университета «Надежная защита для подделки межсайтовых запросов» является богатым источником подробностей.

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

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

Эта атака успешна только в том случае, если возвращаемый JSON исполняется как JavaScript. Серверы могут предотвратить атаку, добавив префикс всех ответов JSON, чтобы сделать их неисполняемыми, по соглашению, используя общеизвестную строку ")]} ',".

HttpClient библиотека Angular распознает это соглашение и автоматически удаляет строку ")]} '," из всех ответов перед дальнейшим анализом.

Аудит Angular приложений

Ангулярные приложения должны следовать тем же принципам безопасности, что и обычные веб-приложения, и должны проверяться как таковые. Специфичные для углов API, которые должны проверяться в обзоре безопасности, такие как методы bypassSecurityTrust, помечены в документации как чувствительные к безопасности.

Предыдущая: Многоразовые анимации
Далее: Анимация перехода маршрута