В этой статье описываются встроенные средства защиты Angular от распространенных уязвимостей и атак веб-приложений.
Angular был стандартной структурой для многих бизнес-приложений благодаря своим многочисленным преимуществам, таким как простота тестирования, архитектура MVC, безопасность, двусторонняя привязка данных, модульность, возможность повторного использования и многие другие. Недавно я начал работать над Angular и решил, что буду читать по одной странице Angular Docs каждый день. Я был очарован тем, как Angular обеспечивает безопасность для распространенных атак, таких как межсайтовый скриптинг (XSS), подделка межсайтовых запросов (CSRF), включение межсайтовых скриптов (XSSI) . Это увлечение в сочетании с необходимостью поделиться этой информацией заставило меня написать свою первую статью на Medium (ура ...).
Я хочу сделать статью достаточно подробной, поэтому я не буду освещать всю тему в этой статье, так как она довольно длинная, и я, очевидно, не хочу утомлять вас до смерти. Итак, давайте разделим эту статью на две части, где часть 1 посвящена предотвращению межсайтового скриптинга (XSS), а часть 2 касается. с доверием безопасным значениям и уязвимостями уровня HTTP.
Предотвращение межсайтового скриптинга (XSS)
Межсайтовый скриптинг (XSS) позволяет злоумышленникам внедрять вредоносный код в веб-страницы. Такой код может затем, например, украсть пользовательские данные или выполнить вредоносные действия. Это одна из самых распространенных атак в Интернете.
Чтобы заблокировать XSS-атаки, вы должны предотвратить проникновение вредоносного кода в вашу DOM (объектную модель документа). Если злоумышленники могут обманом заставить вас вставить тег <script> в DOM, они могут запустить произвольный вредоносный код на вашем веб-сайте. Эта атака не ограничивается только <script> тегами, но многие элементы и свойства в DOM допускают выполнение кода, например <img onerror="..."> и <a href="javascript:...">
Модель безопасности межсайтового скриптинга Angular
Angular обрабатывает все значения как недоверенные по умолчанию, чтобы блокировать ошибки XSS. Когда значение вставляется в DOM из шаблона через свойство, атрибут, стиль, привязку класса или интерполяцию, Angular очищает и ускользает от ненадежных значений.
Контексты дезинфекции и безопасности
Санитарная обработка - это проверка ненадежного значения, превращающая его в значение, которое можно безопасно вставить в модель DOM. Во многих случаях дезинфекция вообще не меняет значение. На самом деле дезинфекция зависит от контекста: безвредное значение в CSS может быть потенциально опасным в URL-адресе.
Angular определяет следующие контексты безопасности:
- HTML используется при интерпретации значения как HTML, например, при привязке к innerHTML.
- Стиль используется при привязке CSS к свойству стиля.
- URL используется для свойств URL, например
<a href>. - URL ресурса - это URL-адрес, который будет загружен и выполнен как код, например, в
<script src>.
Angular очищает ненадежные значения для HTML, стилей и URL-адресов; очистка URL-адресов ресурсов невозможна, поскольку они содержат произвольный код. Angular выводит предупреждение консоли, когда ему нужно изменить значение во время очистки.
Теперь давайте рассмотрим пример, чтобы понять, что делает очистка и как она ведет себя в двух разных сценариях.
Следующий шаблон связывает значение htmlSnippet один раз путем интерполяции его в содержимое элемента и один раз путем привязки к свойству innerHTML элемента.

Интерполированное содержимое всегда экранируется, т. Е. HTML не интерпретируется, и браузер отображает угловые скобки в текстовом содержимом элемента.
Чтобы HTML-код можно было интерпретировать, привяжите его к свойству HTML, например innerHTML. Но привязка значения, которое злоумышленник может контролировать, к innerHTML является одной из основных причин XSS уязвимость. Например, код, содержащийся в теге ‹script›, выполняется:

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

Давайте посмотрим на некоторые предостережения в Angular Sanitization:
- Прямое использование DOM API и явные вызовы очистки:
Встроенные в браузер DOM API не защищают вас автоматически от уязвимостей системы безопасности. Если вы взаимодействуете с другими библиотеками, которые манипулируют DOM, вы, вероятно, не будет такой же автоматической очистки, как при интерполяции Angular. В неизбежных случаях, когда нам нужен пользовательский ввод, мы можем использовать встроенные функции очистки Angular для очистки нашего ввода. - Политика безопасности контента:
Политика безопасности контента (CSP) - это метод глубокой защиты для предотвращения XSS. Чтобы включить CSP, настройте свой веб-сервер так, чтобы он возвращал соответствующий HTTP-заголовок Content-Security Policy. - Защита от XSS на стороне сервера:
HTML, созданный на сервере, уязвим для атак с использованием инъекций. Чтобы предотвратить это, используйте язык шаблонов, который автоматически экранирует значения, чтобы предотвратить XSS-уязвимости на сервере.
Спасибо, ребята, это часть 1 рекомендаций по безопасности. Надеюсь, вы сегодня узнали что-то новое. В следующей части я расскажу, как можно обойти автоматическую очистку и многое другое.
Пожалуйста, дайте мне знать, как блог находится в комментариях, и, конечно, вы можете задавать вопросы, если вы чего-то не поняли. Я хотел бы помочь.