Улучшить эту документацию Просмотреть исходный код $sce

Обзор

$sce — это сервис, предоставляющий AngularJS услуги строгого контекстного экранирования.

Строгое контекстное экранирование

Строгое контекстное экранирование (SCE) — это режим, в котором AngularJS ограничивает привязку только отображением надёжных значений. Его цель — помочь в написании кода, который (а) по умолчанию безопасен, и (б) значительно упрощает аудит на наличие уязвимостей, таких как XSS, clickjacking и т.д.

Обзор

Для систематического предотвращения ошибок XSS, AngularJS по умолчанию обрабатывает все значения как ненадежные в HTML или чувствительных URL-привязках. При привязке ненадежных значений AngularJS автоматически выполняет проверки безопасности (санитаризация, белые списки, в зависимости от контекста) или генерирует исключение, если не может гарантировать безопасность результата. Это поведение сильно зависит от контекста: HTML можно санировать, но URL шаблонов — нельзя, например.

Рассмотрим, к примеру, директиву ng-bind-html. Она отображает своё значение напрямую как HTML: мы называем это *контекстом*. При получении ненадежного ввода AngularJS попытается санировать его перед отображением, если доступен санитайзер, и в противном случае сгенерирует исключение. Чтобы обойти санизацию и отобразить ввод как есть, вам необходимо пометить его как надёжный для данного контекста перед попыткой привязки.

Начиная с версии 1.2, AngularJS по умолчанию включает SCE.

На практике

Вот пример привязки в привилегированном контексте:

<input ng-model="userHtml" aria-label="User input">
<div ng-bind-html="userHtml"></div>

Обратите внимание, что ng-bind-html привязано к userHtml, контролируемому пользователем. Без SCE это приложение позволяет пользователю отображать произвольный HTML в DIV, что является ошибкой XSS. В более реалистичном примере можно отображать комментарии пользователей, статьи блога и т.д. с помощью привязок. (HTML — всего лишь один пример контекста, где отображение ввода, контролируемого пользователем, создаёт уязвимости безопасности.)

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

Как гарантировать, что каждый фрагмент кода, использующий этот тип привязок, привязан к значению, санированному вашей библиотекой (или возвращённому как безопасному для отображения вашим сервером)? Как гарантировать, что вы случайно не удалили строку, санирующую значение, или не переименовали некоторые свойства/поля и не забыли обновить привязку к санированному значению?

Чтобы обеспечить безопасность по умолчанию, AngularJS гарантирует, что привязки проходят через эту санизацию или аналогичный процесс проверки, если нет веских оснований доверять данному значению в данном контексте. Это доверие формализуется с помощью вызова функции. Это означает, что как разработчик, вы можете считать все ненадежные привязки безопасными. Затем, чтобы проанализировать свой код на предмет проблем с безопасностью привязки, вам нужно только убедиться, что значения, которые вы помечаете как надёжные, действительно безопасны — потому что они получены от вашего сервера, санированы вашей библиотекой и т.д. Вы можете организовать свою базу кода, чтобы помочь с этим — возможно, разрешить выполнять эти действия только файлам в определённом каталоге. Гарантирование того, что внутренний API, предоставляемый этим кодом, не помечает произвольные значения как безопасные, затем становится более управляемой задачей.

В случае сервиса SCE AngularJS используется $sce.trustAs (и сокращённые методы, такие как $sce.trustAsHtml и т.д.) для создания надёжных версий ваших значений.

Как это работает?

В привилегированных контекстах директивы и код будут привязаны к результату $sce.getTrusted(context, value), а не непосредственно к значению. Представьте себе эту функцию как способ обеспечить необходимый контекст безопасности в ваших данных. Директивы используют $sce.parseAs вместо $parse для отслеживания привязок атрибутов, что выполняет $sce.getTrusted за кулисами для не-константных литералов. Также, при привязке без директив AngularJS автоматически поймёт контекст ваших привязок.

Например, ngBindHtml использует $sce.parseAsHtml(выражение привязки). Вот фактический код (несколько упрощённый):

var ngBindHtmlDirective = ['$sce', function($sce) {
  return function(scope, element, attr) {
    scope.$watch($sce.parseAsHtml(attr.ngBindHtml), function(value) {
      element.html(value || '');
    });
  };
}];

Влияние на загрузку шаблонов

Это относится как к директиве ng-include, так и к templateUrl, указанным директивами директив.

По умолчанию AngularJS загружает шаблоны только с того же домена и протокола, что и документ приложения. Это делается путём вызова $sce.getTrustedResourceUrl на URL шаблона. Чтобы загружать шаблоны с других доменов и/или протоколов, вы можете либо включить их в белый список, либо оборачивать их в надёжные значения.

Обратите внимание: политика «одинакового происхождения» браузера (Same Origin Policy) и политика совместного использования ресурсов разных происхождений (CORS) (Cross-Origin Resource Sharing (CORS)) применяются дополнительно к этому и могут дополнительно ограничить, будет ли шаблон успешно загружен. Это означает, что без соответствующей политики CORS загрузка шаблонов с другого домена не будет работать во всех браузерах. Кроме того, загрузка шаблонов с file:// URL не работает в некоторых браузерах.

Это кажется слишком большим объёмом накладных расходов

Важно помнить, что SCE применяется только к выражениям интерполяции.

Если ваши выражения являются константными литералами, они автоматически считаются надёжными, и вам не нужно вызывать $sce.trustAs на них (например, <div ng-bind-html="'<b>implicitly trusted</b>'"></div>) просто работает. $sceDelegate также будет использовать сервис $sanitize, если он доступен при привязке ненадежных значений к $sce.HTML контексту. AngularJS предоставляет реализацию в angular-sanitize.js, и если вы хотите её использовать, вам также необходимо использовать модуль ngSanitize в своём приложении.

Включённый $sceDelegate поставляется с разумными значениями по умолчанию, что позволяет загружать шаблоны в ng-include с домена вашего приложения, не зная о SCE. Он блокирует загрузку шаблонов с других доменов или загрузку шаблонов по протоколу http с документа, предоставленного по протоколу https. Вы можете изменить эти значения, установив собственные пользовательские белые списки и чёрные списки для сопоставления таких URL.

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

Какие типы надёжных контекстов поддерживаются?

Контекст	Примечания
$sce.HTML	Для HTML, который безопасно использовать в приложении. Директива ngBindHtml использует этот контекст для привязок. Если встретится небезопасное значение, и сервис $sanitize доступен (реализован модулем ngSanitize), это значение будет санировано вместо вывода исключения.
$sce.CSS	Для CSS, который безопасно использовать в приложении. В настоящее время привязки не требуют этого контекста. Не стесняйтесь использовать его в своих директивах.
$sce.URL	Для URL-адресов, которые безопасно использовать в качестве ссылок. В настоящее время не используется (<a href=, <img src=, и некоторые другие санируют свои URL-адреса и не представляют собой контекст SCE.)
$sce.RESOURCE_URL	Для URL-адресов, которые не только безопасны для использования в качестве ссылок, но и содержимое которых безопасно включить в ваше приложение. Примеры включают ng-include, src / ngSrc привязки для тегов, отличных от IMG, VIDEO, AUDIO, SOURCE, и TRACK (например, IFRAME, OBJECT, и т.д.) Обратите внимание, что $sce.RESOURCE_URL делает более сильное утверждение о URL-адресе, чем $sce.URL (важно не только сам URL, но и то, что находится в конце его), и поэтому контексты, требующие значений, надёжных для $sce.RESOURCE_URL, можно использовать везде, где требуются значения, надёжные для $sce.URL.
$sce.JS	Для JavaScript-кода, который безопасно выполнить в контексте вашего приложения. В настоящее время привязки не требуют этого контекста. Не стесняйтесь использовать его в своих директивах.

Обратите внимание, что a[href] и img[src] автоматически санируют свои URL-адреса и не передают их через $sce.getTrusted. В настоящее время в AngularJS нет привязок CSS-, URL- или JS-контекста, поэтому соответствующие функции $sce.trustAs пока не полезны. Это может измениться.

Формат элементов в resourceUrlWhitelist/чёрном списке

Каждый элемент в этих массивах должен быть одним из следующих:

• 'self'
  • Специальная строка, 'self', может использоваться для сопоставления со всеми URL-адресами одного домена приложения с использованием одного и того же протокола.
• Строка (кроме специального значения 'self')
  • Строка сопоставляется с полным нормализованным/абсолютным URL-адресом проверяемого ресурса (сопоставление по подстрокам недостаточно).
  • Существует ровно две последовательности подстановочных знаков - * и **. Все остальные символы соответствуют самим себе.
  • *: соответствует нулю или более вхождениям любого символа, кроме следующих 6 символов: ':', '/', '.', '?', '&' и ';'. Это полезный подстановочный знак для использования в белом списке.
  • **: соответствует нулю или более вхождениям любого символа. Поэтому он не подходит для использования в схеме, домене и т. д., так как он будет соответствовать слишком многим значениям. (например, http://**.example.com/ будет соответствовать http://evil.com/?ignore=.example.com/, и это, возможно, не было задумано.) Его использование в самом конце пути допустимо. (например, http://foo.example.com/templates/**).
• RegExp (см. замечание ниже)
  • Замечание: Хотя регулярные выражения мощные и предлагают большую гибкость, их синтаксис (и все неизбежные экранирования) делает их сложнее поддерживать. Легко случайно ввести ошибку при обновлении сложного выражения (по-моему, все регулярные выражения должны иметь хорошее покрытие тестами). Например, использование . в регулярном выражении верно только в небольшом количестве случаев. Символ . в регулярном выражении, используемом при сопоставлении схемы или поддомена, может соответствовать : или буквальному ., что, вероятно, не было задумано. Настоятельно рекомендуется использовать шаблоны строк и переходить к регулярным выражениям только в крайних случаях.
  • Регулярное выражение должно быть экземпляром RegExp (т. е. не строкой). Оно сопоставляется со всей нормализованной/абсолютной URL-ссылкой проверяемого ресурса (даже если в регулярном выражении не было кодов ^ и $). Кроме того, любые флаги, присутствующие в регулярном выражении (например, многострочный, глобальный, игнорировать регистр), игнорируются.
  • Если вы генерируете свой JavaScript из другого шаблонизатора (не рекомендуется, например, в проблеме #4006), не забудьте экранировать ваше регулярное выражение (и помните, что вам может потребоваться более одного уровня экранирования в зависимости от вашего шаблонизатора и способа интерполяции значения). Используйте механизм экранирования вашей платформы, так как он может быть достаточно хорош до написания собственного кода. Например, Ruby имеет Regexp.escape(str), а Python имеет re.escape. В Javascript отсутствует аналогичная встроенная функция экранирования. Посмотрите на библиотеку Google Closure goog.string.regExpEscape(s).

См. $sceDelegateProvider для примера.

Покажите пример использования SCE.

Могу ли я полностью отключить SCE?

Да, можете. Однако это настоятельно не рекомендуется. SCE предоставляет множество преимуществ в плане безопасности при небольших затратах на программирование. Будет намного сложнее взять приложение с отключенным SCE и либо обеспечить его безопасность самостоятельно, либо включить SCE на более позднем этапе. Это может быть целесообразно в случаях, когда у вас много существующего кода, написанного до введения SCE, и вы мигрируете их по одному модулю за раз. Также обратите внимание, что это параметр для всего приложения, поэтому, если вы пишете библиотеку, вы вызовете ошибки безопасности в приложениях, которые её используют.

Тем не менее, вот как вы можете полностью отключить SCE:

angular.module('myAppWithSceDisabledmyApp', []).config(function($sceProvider) {
  // Completely disable SCE.  For demonstration purposes only!
  // Do not use in new projects or libraries.
  $sceProvider.enabled(false);
});