Защита SPA от проблем с безопасностью

Существует много информации о веб-безопасности. Но когда я читал эти материалы, я заметил, что некоторые сведения не являются актуальными, или они были написаны специально для традиционных веб-приложений с серверным рендерингом, или автор рекомендовал анти-паттерны. В этой серии статей я расскажу о проблемах веб-безопасности, о которых должны знать все веб-разработчики, уделяя особое внимание приложениям на стороне клиента, а именно одностраничным приложениям (SPA). Кроме того, я не собираюсь углубляться в тонкости веб-безопасности, криптографии и сетевых технологий. Вместо этого я сосредоточусь на основных выводах и списках дел высокого уровня. Я также приведу ссылки на ресурсы, где вы сможете углубиться в эту тему.

Итак, почему мы беспокоимся о веб-безопасности? Когда в наших приложениях есть уязвимости, это открывает путь для злоумышленников. В чужих руках использование уязвимостей может привести к риску для вашего приложения, данных, репутации и прибыли. По словам моего коллеги Аарона Пареки, все сводится к одному — ответственности. И мы не хотим подвергать себя, свои приложения и свои компании ответственности. Если вы чувствуете угрозу, самое время прочитать дальше и определить, как усилить защиту вашего приложения.

Используйте OWASP Top 10 для выявления наиболее распространенных уязвимостей

Если вы только начинаете задумываться о безопасности, вы, возможно, не слышали о проекте Open Web Application Security Project (OWASP). OWASP — это группа, которая занимается тем, чтобы сделать Интернет более безопасным местом. Они ведут и публикуют список наиболее распространенных веб-уязвимостей под названием «OWASP Top Ten» и подготовили новую десятку на 2021 год; их инфографика показывает, как изменился список наиболее распространенных веб-уязвимостей с 2017 по 2021 год.

CC-by Open Web Application Security Project

Поскольку это список веб-уязвимостей, весь список имеет отношение к нашей работе как веб-разработчиков. Однако несколько критических уязвимостей требуют повышенного внимания, а некоторые уязвимости менее уязвимы, когда фронтенд представляет собой SPA с бэкенд API на основе JSON.

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

Использование браузера и заголовков безопасности

Во-первых, нам нужно подготовить почву для части нашей стратегии по устранению уязвимостей, подняв вопрос о заголовках безопасности. В современных браузерах (прощай, Internet Explorer!!) уже встроено множество механизмов безопасности. Мы должны использовать встроенные механизмы безопасности и можем усилить их с помощью дополнительных заголовков безопасности. Заголовки безопасности — это заголовки HTTP-ответов, которые содержат инструкции о том, как должен вести себя браузер. Они определяются на вашем веб-сервере.

Существует довольно много заголовков безопасности, которые мы можем применить. Следует отметить, что SPA уникальны, поэтому не все заголовки безопасности применяются так же, как в традиционном веб-приложении с серверным рендерингом. Я буду называть заголовки безопасности, которые вы захотите использовать, когда мы будем обсуждать, как устранить конкретную уязвимость.

Погрузитесь глубже в заголовки безопасности

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

• Обзор лучших практик для заголовков безопасности
• Шпаргалка OWASP по HTTP-заголовкам ответов безопасности
• Краткое руководство по заголовкам безопасности от Web.dev

Безопасная передача данных с помощью TLS/SSL

Использование HTTPS должно быть неоспоримым стандартом, но существуют устаревшие системы, в которых приложения не используют HTTPS. Очень важно использовать безопасный протокол передачи гипертекста; в конце концов, аббревиатура HTTPS соответствующим образом образована от Hypertext Transfer Protocol Secure. И очень важно обеспечить безопасность всего стека, а не только при обслуживании внешнего сайта (не спрашивайте меня, откуда я знаю, что такое может быть).

Когда вы не используете современную защиту транспортного уровня в своей прикладной системе, вы подвергаете себя атакам «посредник посередине» (MITM). В этом типе атак злоумышленники перехватывают связь между незащищенными системами, чтобы перехватывать данные или выдавать себя за общающиеся стороны.

Вы можете подумать, что призыв использовать HTTPS не нужен, поскольку это стандарт для хостинга веб-приложений, но криптографические сбои, приводящие к небезопасной связи, являются второй наиболее распространенной уязвимостью в десятке OWASP! Обратите внимание, что недостаточно установить любой старый механизм HTTPS на ваш веб-сервер. Вам нужна последняя версия TLS. Ваши облачные провайдеры могут даже заставить вас обновить версию TLS, если она старая, и это хорошо!

— xkcd

Каковы здесь выводы? В частности, вам нужно убедиться, что у вас есть действующие сертификаты, что вы используете последнюю версию TLS и что вы используете SSL/TLS во всем своем стеке. Возможно, все эти шаги уже предусмотрены вашим провайдером облачного хостинга. Вы также должны убедиться, что добавили заголовок безопасности HTTP Strict Transport Security (HSTS) на веб-сервер, который добавляет дополнительный уровень безопасности помимо перенаправления HTTPS.

Погрузитесь глубже в безопасность транспортного уровня

Посмотрите эти ресурсы, если вы хотите узнать больше о безопасности транспортного уровня и о том, как настроить перенаправление HTTPS и HTST.

• Глава книги Okta API Security о безопасности транспортного уровня
• Шпаргалка OWASP по защите на транспортном уровне
• Руководство по TLS из MDN
• Начало работы с HTTPS и сертификатами с Let’s Encrypt

Поддерживайте свой фреймворк и внешние зависимости в актуальном состоянии

Вы знали, что это произойдет, хотя мы можем сетовать на работу, связанную с обновлением. Совет обновлять свои зависимости звучит как «Не забывайте пользоваться зубной нитью», но это необходимо (так же, как и чистка зубов). Уязвимые и устаревшие компоненты занимают шестое место в списке OWASP Top Ten. И в последнее время в новостях появлялись значительные уязвимости, связанные с зависимостями. Так что в глубине души вы знаете, что зарывание головы в песок — не лучший план действий.

Важно отметить, что мы должны обновлять устаревшие компоненты и следить за тем, чтобы случайно не зависеть от уязвимых зависимостей. Мы должны зафиксировать версии зависимостей в нашем package.json, а затем сгенерировать и обеспечить использование файла блокировки. Это означает запуск npm ci вместо npm i для принудительного использования точных версий, определенных в package-lock.json. Если вы используете Yarn, вы будете использовать yarn install --frozen-lockfile. Таким образом, обновление версий будет намеренным действием.

Вот и все. Просто сделайте это. Это важно. Устаревшие компоненты — это источник ответственности.

Погрузитесь глубже в вопросы поддержания компонентов в актуальном состоянии

Ознакомьтесь с пошаговым руководством по управлению зависимостями для разработчиков JavaScript от команды OWASP — NPM Security best practices.

Безопасная загрузка ресурсов

Кросс-оригинальные ресурсы представляют собой особую проблему для SPA; речь идет о ресурсах, которые использует ваше веб-приложение и которые не размещены на том же сервере, что и ваше веб-приложение. Когда все ресурсы, необходимые фронтенду, доступны через один и тот же источник, мы уверены, что ресурсы безопасны. Надеемся, что мы не подставляем себя под удар! По крайней мере, не намеренно, верно?!

Типичная схема настройки URL-адресов для связи SPA с внутренними API может выглядеть следующим образом.

https://myfavekdramas.com

а URL-адрес внутреннего API имеет следующий вид

https://apis.myfavekdramas.com

Но URL API является поддоменом, поэтому запрос является кросс-оригинальным. Большинство браузеров (и снова BUH-BYE Internet Explorer!) защищают нас, разрешая только определенные кросс-оригинальные запросы. Мы можем настроить доступ к ресурсам, включив кросс-оригинальный обмен ресурсами (CORS).

Если ваша производственная среда похожа на приведенные выше URL, а локальная разработка использует разные порты для front-end и back-end, у вас может возникнуть соблазн включить CORS, чтобы разрешить все виды запросов. В отличие от других мер безопасности, рассмотренных в этом посте, ваш браузер уже защищает вас самым строгим образом. Включение CORS ослабляет это ограничение.

Поэтому рекомендуется включать CORS надлежащим образом с продуманным использованием списков разрешений. Используйте прокси по мере необходимости (например, для локальной разработки). Здесь также применима концепция наименьших привилегий, и сохранение жесткого контроля помогает уменьшить уязвимости безопасности.

Погружение в кросс-оригинальный обмен ресурсами

Хотите лучше понять, когда применяются правила CORS или как настроить правила allowlist? Прочитайте эти ресурсы для глубокого погружения.

• Устранение распространенных проблем с CORS и JavaScript
• Справочник MDN по CORS
• Учебник по CORS от Auth0

Защитите свои файлы cookie от кражи

На самом деле, эти советы применимы и за пределами веб-разработки. Но поскольку в этом посте мы говорим о веб-разработке, мы пропустим стратегии по защите физических файлов cookie от мародеров и снова сосредоточимся на заголовках безопасности.

Печенье может содержать всевозможные лакомства, такие как шоколадные чипсы и лакомые кусочки данных, которые так нравятся агитаторам! Современные передовые методы аутентификации предпочитают использовать для аутентификационных маркеров память браузера или веб-рабочих, а не файлы cookie, и файлы cookie никогда не должны использоваться для секретов, однако в файлах cookie все еще может храниться конфиденциальная информация. Чтобы защитить файлы cookie, мы можем использовать атрибуты.

Cookies должны быть временными. В частности, файлы cookie с конфиденциальной информацией должны быть как можно более недолговечными. Когда вы или ваш бэкенд выпекает cookie, добавление атрибута Max-Age определяет долговечность cookie.

Есть еще несколько атрибутов, которые можно добавить! Добавление атрибута httpOnly означает, что браузер отправляет cookie только для HTTP-запросов, и JavaScript не сможет получить доступ к cookie. Установка атрибута httpOnly — это отличный первый шаг для защиты ваших cookie от вредоносного скрипта, который может прочитать ваши cookie.

Наличие атрибута httpOnly означает, что JavaScript не может получить доступ к cookie, но это не означает, что ваш браузер тщательно выбирает, какие cookie отправить на каждый HTTP-запрос! Он просто отправляет их все, что приводит к возможности возникновения уязвимости!

Именно здесь в игру вступает атрибут SameSite. Вы можете контролировать время отправки cookies, используя атрибут SameSite и устанавливая одно из трех значений:

Установив атрибут SameSite, вы больше не сможете использовать сценарий, подобный этому.

Вдумчиво относитесь к файлам cookie и применяйте принципы наименьших привилегий. Защита cookie-файлов — это важный шаг в уменьшении других уязвимостей.

Углубитесь в защиту файлов cookie

Узнайте больше о защите файлов cookie, просмотрев эти замечательные ресурсы.

• Объяснение файлов cookie SameSite от web.dev
• Веб-документы MDN по куки-файлам SameSite

Узнайте больше о веб-безопасности

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

Не терпится узнать больше? Ознакомьтесь со следующими ресурсами.

• Руководство для начинающих по безопасности приложений
• Как настроить лучшую безопасность веб-сайта с помощью Cloudflare и Netlify
• Паттерны безопасности для микросервисных архитектур
• Безопасность и веб-разработка
• OWASP Top Ten 2021: Похожие шпаргалки

Не забывайте следить за нами в Twitter и подписываться на наш канал YouTube, чтобы получить еще больше отличных уроков. Мы также будем рады услышать вас! Если у вас есть вопросы или вы хотите поделиться тем, какой учебник вы хотели бы увидеть следующим, пожалуйста, комментируйте ниже.