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

Обзор

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

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

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

Обзор

Для систематического блокирования ошибок 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(контекст, значение), а не к самому значению напрямую. Представьте себе эту функцию как способ обеспечить необходимый контекст безопасности в ваших данных. Директивы используют $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 шаблона. Чтобы загружать шаблоны с других доменов и/или протоколов, вы можете либо добавить их в белый список, либо оборачивают их в надёжное значение.

Обратите внимание: политика браузера Политика одинакового происхождения и политика совместного использования ресурсов из других доменов (CORS) применяются дополнительно и могут ещё больше ограничивать возможность успешной загрузки шаблона. Это означает, что без соответствующей политики CORS загрузка шаблонов с другого домена не будет работать во всех браузерах. Кроме того, загрузка шаблонов с file:// URL не работает в некоторых браузерах.

Это кажется слишком избыточным

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

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

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

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

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

В настоящее время в AngularJS нет привязок CSS или JS-контекстов, поэтому соответствующие функции $sce.trustAs пока не применимы. Это может измениться.

Формат элементов в resourceUrlWhitelist/Blacklist

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

• 'self'
  • The special string, 'self', can be used to match against all URLs of the same domain as the application document using the same protocol.
• String (except the special value 'self')
  • The string is matched against the full normalized / absolute URL of the resource being tested (substring matches are not good enough.)
  • There are exactly two wildcard sequences - * and **. All other characters match themselves.
  • *: matches zero or more occurrences of any character other than one of the following 6 characters: ':', '/', '.', '?', '&' and ';'. It's a useful wildcard for use in a whitelist.
  • **: matches zero or more occurrences of any character. As such, it's not appropriate for use in a scheme, domain, etc. as it would match too much. (e.g. http://**.example.com/ would match http://evil.com/?ignore=.example.com/ and that might not have been the intention.) Its usage at the very end of the path is ok. (e.g. http://foo.example.com/templates/**).
• RegExp (see caveat below)
  • Caveat: While regular expressions are powerful and offer great flexibility, their syntax (and all the inevitable escaping) makes them harder to maintain. It's easy to accidentally introduce a bug when one updates a complex expression (imho, all regexes should have good test coverage). For instance, the use of . in the regex is correct only in a small number of cases. A . character in the regex used when matching the scheme or a subdomain could be matched against a : or literal . that was likely not intended. It is highly recommended to use the string patterns and only fall back to regular expressions as a last resort.
  • The regular expression must be an instance of RegExp (i.e. not a string.) It is matched against the entire normalized / absolute URL of the resource being tested (even when the RegExp did not have the ^ and $ codes.) In addition, any flags present on the RegExp (such as multiline, global, ignoreCase) are ignored.
  • If you are generating your JavaScript from some other templating engine (not recommended, e.g. in issue #4006), remember to escape your regular expression (and be aware that you might need more than one level of escaping depending on your templating engine and the way you interpolated the value.) Do make use of your platform's escaping mechanism as it might be good enough before coding your own. E.g. Ruby has Regexp.escape(str) and Python has re.escape. Javascript lacks a similar built in function for escaping. Take a look at Google Closure library's goog.string.regExpEscape(s).

Refer $sceDelegateProvider for an example.

Покажите мне пример использования 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);
});