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

Разработка для обеспечения безопасности контента в приложениях Angular.

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

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

Содержание

• Сообщения об уязвимостях.
• Рекомендованные практики.
• Предотвращение межсайтового скриптинга (XSS).
• Доверие безопасным значениям.
• Уязвимости на уровне HTTP.
• Аудит приложений Angular.

Вы можете запустить пример в реальном времени в Plunker и скачать код оттуда.

Сообщения об уязвимостях

Чтобы сообщить об уязвимостях в самом Angular, напишите нам по адресу security@angular.io.

Для получения дополнительной информации о том, как Google обрабатывает проблемы с безопасностью, см. Философию безопасности Google.

Рекомендованные практики

• Следите за новыми выпусками библиотек Angular. Мы регулярно обновляем библиотеки Angular, и эти обновления могут исправить дефекты безопасности, обнаруженные в предыдущих версиях. Проверьте журнал изменений Angular журнал изменений для обновлений, связанных с безопасностью.

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

• Избегайте API Angular, помеченных в документации как «Риск безопасности». Для получения дополнительной информации см. раздел Доверие безопасным значениям на этой странице.

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

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

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

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

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

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

Очистка и контексты безопасности

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

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

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

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

Пример очистки

Следующий шаблон связывает значение htmlSnippet, один раз, интерполируя его в содержимое элемента, и один раз, привязывая его к свойству innerHTML элемента:

<h3>Binding innerHTML</h3>
<p>Bound value:</p>
<p class="e2e-inner-html-interpolated">{{htmlSnippet}}</p>
<p>Result of binding to innerHTML:</p>
<p class="e2e-inner-html-bound" [innerHTML]="htmlSnippet"></p>

Интерполированное содержимое всегда экранируется — HTML не интерпретируется, и браузер отображает угловые скобки в текстовом содержимом элемента.

Для интерпретации HTML привяжите его к свойству HTML, такому как innerHTML. Но привязка значения, которое может контролироваться злоумышленником, к innerHTML обычно приводит к уязвимости XSS. Например, код, содержащийся в <script> теге, выполняется:

export class InnerHtmlBindingComponent {
  // For example, a user/attacker-controlled value from a URL.
  htmlSnippet = 'Template <script>alert("0wned")</script> <b>Syntax</b>';
}

Angular распознаёт значение как небезопасное и автоматически очищает его, удаляя <script> тег, но сохраняя безопасное содержимое, такое как текстовое содержимое <script> тега и <b> элемент.

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

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

Политика безопасности содержимого

Политика безопасности содержимого (CSP) — это техника защиты от XSS. Для включения CSP настройте свой веб-сервер на возвращение соответствующего Content-Security-Policy HTTP-заголовка. Подробнее о политике безопасности содержимого см. на веб-сайте HTML5Rocks в разделе Введение в политику безопасности содержимого.

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

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

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

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

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

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

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

• bypassSecurityTrustHtml
• bypassSecurityTrustScript
• bypassSecurityTrustStyle
• bypassSecurityTrustUrl
• bypassSecurityTrustResourceUrl

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

<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>

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

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);

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

<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>

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);
}

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

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

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

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

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

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

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

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

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

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

Angular's http имеет встроенную поддержку клиентской части этого метода в своем XSRFStrategy. По умолчанию CookieXSRFStrategy включено автоматически. Перед отправкой HTTP-запроса CookieXSRFStrategy ищет cookie с именем XSRF-TOKEN и устанавливает заголовок с именем X-XSRF-TOKEN со значением этого cookie.

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

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

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

Или вы можете реализовать и предоставить полностью настраиваемый XSRFStrategy:

Дополнительная информация о CSRF в проекте Open Web Application Security Project (OWASP) доступна на страницах Cross-Site Request Forgery (CSRF) и Руководство по предотвращению атак CSRF. Статья Стэнфордского университета Robust Defenses for Cross-Site Request Forgery содержит подробную информацию.

Также посмотрите понятное объяснение Дэва Смита выступления о XSRF на AngularConnect 2016.

Включение скрипта с другого сайта (XSSI)

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

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

Библиотека Angular's Http распознаёт эту конвенцию и автоматически удаляет строку ")]}',\n" из всех ответов перед дальнейшим парсингом.

Дополнительную информацию можно найти в разделе XSSI этого блога Google о безопасности веб-сайтов.

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

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