Найкращі способи захисту Angular-застосунків

Цей матеріал є продовженням статті про фундаментальні принципи безпеки в застосунках на Angular. Тут ми детально розглянемо сучасні найкращі практики для захисту Angular-застосунків.

1. Інтерполяція захистить вас від міжсайтового скриптингу

Використовуйте інтерполяцію {{}}, аби вберегти свій код від потенційно небезпечних символів та екранувати ненадійний HTML та CSS в шаблонах.

Подібно до Vue та React, безпека в Angular реалізується за допомогою кількох механізмів, серед яких інтерполяція рядків. Автоматично всі дані вважаються потенційно небезпечними, тому всі сучасні фронтенд-бібліотеки, зокрема й Angular, слідують кращим практикам кодування будь-якого стороннього тексту в HTML.

У матеріалі про безпеку в Angular є детальне пояснення, чому рекомендується використовувати фігурні дужки (синтаксис інтерполяції рядків) в Angular для екранування будь-яких даних з ненадійних джерел. Такі дані роблять застосунок вразливим до міжсайтового скриптингу (XSS).

2. Використовуйте innerHTML обережно

Якщо вам треба динамічно додати HTML до компонента, прив'яжіть його генерацію до [innerHTML]. Тоді дані будуть оброблені як HTML у своєму контексті, до того ж будуть очищені (видаляться всі небезпечні теги, а отже шахрайські скрипти не зможуть виконуватись). Зверніть увагу, що процес очищення відрізняється від кодування.

В чому відмінність між очищенням та кодуванням і їхніми результатами?

Після кодування рядки замінюються їхніми текстовими варіантами, які можуть об'єднуватись з певним HTML-тегом. Наприклад, якщо для обробки передається тег <script>, Angular може показати його, попередньо закодувавши дужки. Такий підхід використовується у багатьох бібліотеках та фреймворках, які слідують найкращим практикам безпеки.

Сам процес виглядає так: фреймворк знаходить символи-мнемоніки HTML , кодує їх та записує в DOM ось так: & lt;script& gt;. Потім браузер інтерпретує контекст та виводить тег <script>.

На відміну від кодування, очищення або фільтрація — більш радикальні способи знайти небезпечні символи та видалити їх з тексту, який потрапляє в DOM.

Для результату кодування чи очищення вирішальним фактором стає контекст.

Звернемось до документації Angular, аби дізнатись більше про контексти з огляду безпеки:

Angular оголошує такі контексти безпеки:

• HTML, який отримується при інтерпретації значення як HTML (наприклад, при прив'язці до innerHtml;
• стилі, які отримуються при прив'язці CSS до властивостей стилю;
• URL, який використовується для властивостей URL (наприклад <a href>);
• URL, який буде завантажено та виконано як код, наприклад у <script src>

Зверніть увагу на особливу обробку тих URL, які не фільтруються.

3. Ніколи не використовуйте шаблони, згенеровані з користувацького вводу

Використання користувацького вводу для генерації шаблону потенційно небезпечне.

Треба звести до мінімуму чи навіть зовсім обмежити ситуації, коли ви формуєте шаблон з результатів користувацького вводу шляхом конкатенації, а не використовуєте інтерполяцію чи рекомендовану композицію компонентів в застосунку на Angular. Якщо колись ви натрапите на такий підхід у кодовій базі, обов'язково проведіть рефакторинг.

Ви повинні уникати подібного коду:

@Component({
  template:`
  <div class="job-ad">
    <h4>{{data.headline}}</h4>

    {{data.body}}
  </div>
  `
}) + potentialUserUnput

export class HeroJobAdComponent implements AdComponent {
  @Input() data: any;
}

Зверніть особливу увагу на нетрадиційну конкатенацію рядка та шаблона. Значення змінної potentialUserInput потенційно містить небезпечні дані. Тож такого підхіду однозначно варто уникати.

Для повної картини можна виконати подібний код в пісочниці Angular. Там ви побачите, що буде після використання користувацького вводу в шаблонах напряму:

В офіційному посібнику з рекомендацій безпеки в Angular вказано:

Ніколи не генеруйте код шаблону шляхом конкатенації результатів користувацького вводу. Аби уникнути таких вразливостей, використовуйте офлайн-компілятор шаблонів (посилання: https://angular.io/guide/security#offline-template-compiler)

Angular рекомендує використовувати власний компілятор для компіляції шаблонів перед виконанням в офлайн-режимі. Це допомагає уникнути вразливостей, викликаних небезпечною генерацією шаблонів.

Запустити компіляцію можна так:

ng build --aot
ng serve --aot

Зверніть увагу, що в останніх версіях Angular (v9 та вище), які компілюються з Ivy, значення прапора компіляції (aot) перед виконанням встановлено як true автоматично. Так Angular уникає ін'єкціїї шаблонів.

{
  "projects": {
    "my-existing-project": {
      "architect": {
        "build": {
          "options": {
            ...
            "aot": true,
          }
        }
      }
    }
  }
}

4. Ніколи не використовуйте нативний DOM API для взаємодії з HTML-елементами

Уникайте прямих DOM-маніпуляцій. Віддавайте перевагу механізму шаблонів в Angular, а також власному API Angular для DOM-маніпуляцій. До небажаних методів взаємодії належать:

• node.appendChild();
• використання об'єкта document для взаємодії зі сторінкою;
• використання jQuery API.

Нативні API в Angular також не завжди безпечні, адже через них можна напряму звертатись до елементів (наприклад, ElementRef API). ElementRef в Angular спричиняє проблеми з безпекою, якщо використовується для прямого доступу до DOM-елемента та виконанні деяких дій над ним.

Такі та інші взаємодії поза API Angular потенційно ведуть до вразливостей.

5. Не використовуйте шаблонізатори для шаблонів, що генеруються на сервері

Не варто звертатись до сторонніх шаблонізаторів для створення або модифікації даних шаблонів в застосунках з рендерингом server-side .

Якщо ви колись створювали вебзастосунки через Node.js, то, мабуть, мали справу з шаблонізаторами на кшталт EJS, Pug, Handlebars або іншими. Вони використовуються для управління шаблонами, що рендеряться на сервері для шару View, і можуть мати певні фічі для їх динамічної генерації.

Однак такі технології разом з серверним рендерингом Angular не варто використовувати — це може призвести до потенційного впливу зловмисного коду на шаблон. Такий вплив стає можливим, тому що дані додаються поза Angular API, тобто їх ніяк не очистити. Це той самий рівень ризику, що й конкатенація для створення шаблону.

6. Перевірте ваш Angular-проєкт на компоненти, що провокують вразливості

Завжди перевіряйте open-source залежності проєкту, а також внутрішні компоненти на проблеми безпеки. Використовуйте платформу Snyk або CLI, аби знайти, виправити та відстежити вразливості.

Якщо ви використовуєте сторонні бібліотеки чи фреймворки (на зразок Angular та його екосистеми зі сторонніми модулями та компонентами), пам'ятайте про можливі вразливості, що впливають на основний функціонал бібліотеки. І не забувайте про вразливості у сторонніх модулях Angular.

Використання компонентів з відомими вразливостями — один з десяти найпопулярнішиї ризиків за версією OWASP.

На зображенні нижче є перелік модулів Angular з відомими вразливостями, які ви можете перевірити, запустивши npm install чи npm audit з назвою модуля. Судячи зі звіту про безпеку JavaScript-фреймворків, деякі з модулів налічують мільйони завантажень щороку, але їхні вразливості досі не виправлені.

Захищаємо вебзастосунки

Якщо ви використовуєте npm audit — це вже правильний шлях. Однак ви все ще не контролюєте усі можливі вразливості:

• Ви можете пофіксити всі вразливості проєкту зараз, але що трапиться, коли буде знайдено нову вразливість для якогось Angular-модуля? Ви не знатимете, чи впливає вона на ваш застосунок, задеплоєний на Vercel, Netlify тощо.
• npm audit відстежує лише відомі вразливості, які мають офіційний CVE-код (тобто входять до БД загальновідомих вразливостей ПЗ). Натомість Snyk відстежує понад 23 вразливості безпеки модулів Angular (npm audit про жодну з цих вразливостей не повідомляє).

Snyk розв'язує обидві проблеми, до того ж інструмент безкоштовний. Як розпочати роботу з ним?

Зареєструйтесь, аби отримати спеціальний токен та додати ваш проєкт з GitHub або Bitbucket. Тепер Snyk може автоматично знайти вразливості та створити пул-запити з виправленнями за вас.

Інший швидкий спосіб розпочати роботу з Snyk — використати Snyk CLI:

npm install -g snyk
snyk test

Джерело.

Snyk допомагає з'ясувати, коли та на яку версію модуля варто перейти, аби уникнути вразливостей.

Якщо ви в пошуках інструменту для відстеження проблем з продуктивністю, то Snyk — саме те, що ви шукали. Він сповістить вас та пофіксить проблеми з безпекою, що виникають в залежностях з відкритим сирцевим кодом.

Якщо ви хочете заглибитись в тему безпеки та вразливостей, рекомендуємо прочитати далі:

• Для тих, хто займається активною розробкою на AngularJS, матеріал про 10 фундаментальних принципів безпеки в AngularJS;
• Якщо вам цікаво порівняти Angular vs React з огляду безпеки, перегляньте звіт про безпеку JavaScript-фреймворків.