Это вторая статья из серии статей о веб-безопасности для SPA. В предыдущем посте мы заложили основу для размышлений о веб-безопасности и применения механизмов безопасности в нашем стеке приложений. Мы рассмотрели десятку лучших OWASP, использование безопасной передачи данных с помощью SSL/TLS, использование заголовков безопасности для улучшения встроенных механизмов браузера, обновление зависимостей и защиту cookies.
Готовы продолжить и сделать свой SPA более безопасным? В этом посте мы используем представленные концепции для устранения некоторых известных веб-уязвимостей.
Практика чистоты данных для смягчения последствий XSS
Межсайтовый скриптинг (XSS) — это уязвимость, которая продолжает беспокоить веб-разработчиков. Эта уязвимость представляет собой тип инъекционной атаки и настолько распространена, что занимает 3-е место в списке OWASP Top Ten.
Как работает эта уязвимость? Вкратце, XSS происходит, когда код загрязняет данные, а вы не применяете меры предосторожности.
Хорошо, но что это значит? Классический пример — веб-сайт, который позволяет пользователю вводить данные, например, добавлять комментарии или отзывы. Предположим, что форма ввода принимает все, что вводит пользователь, и не обеспечивает надлежащую защиту пользовательских данных перед их хранением и отображением другим пользователям. В этом случае она подвержена риску XSS.
Представьте себе слишком драматичный, но в остальном невинный сценарий:
- Веб-сайт позволяет добавлять комментарии к любимой K-драме.
- Агитатор добавляет комментарий
<script>alert('Crash Landing on You stinks!');</script>.- Этот ужасный комментарий сохраняется в базе данных как есть.
- Поклонник K-драмы открывает сайт.
- Ужасный комментарий добавляется на сайт, добавляя тег
<script></script>в DOM.- Поклонник К-драмы возмущен предупреждением JavaScript, говорящим, что их любимая К-драма отвратительна.
Итак, это, безусловно, ужасно. Прежде всего потому, что мы все знаем, что «Crash Landing on You», на самом деле, прекрасен. Кроме того, такой сценарий подвергает ваш сайт опасности колоссального взлома, при котором инъекционная атака может натворить всяких бед. С помощью JavaScript атака может перехватить файлы cookie, покопаться в локальном хранилище браузера в поисках аутентификационной информации, получить доступ к файловой системе, сделать вызовы на другие сайты и причинить еще больше вреда.
В данном случае мы показали пример очень наглядно, используя тег <script></script>, чтобы нам было легче об этом говорить, но атака может использовать все, что запускает JavaScript, например, добавление элемента HTML с JS, встроенным в атрибут, добавление JS в URL ресурсов, встраивание JS в CSS и так далее. Это настоящий кошмар!
Как избежать подобных махинаций? Существует несколько различных защитных тактик, но главная из них заключается в том, чтобы обеспечить хорошую гигиену данных путем экранирования и санации.
Под экранированием понимается замена определенных символов в HTML, чтобы они читались как текстовые строки, например, замена <b> на <b>). При экранировании браузер больше не рассматривает значение как часть кода. Это просто текст или данные. Хотя здесь речь идет о XSS, экранирование является хорошей практикой в целом, поскольку оно защитит вас от SQL-инъекции, другого типа инъекционных атак.
— xkcd
Санирование удаляет код, который может быть вредоносным, сохраняя при этом некоторые безопасные HTML-теги. Основным примером использования санитарии вместо удаления кода является ситуация, когда вы хотите разрешить отображение разметки, например, если на вашем сайте есть текстовый редактор.
Нам еще многое предстоит обсудить в отношении межсайтового скриптинга, включая типы XSS и специфику методов борьбы с ними, поэтому следите за последующей статьей с более подробной информацией, включая встроенные механизмы защиты от XSS, предусмотренные в некоторых SPA-фреймворках.
Погружение в XSS
Не терпится прочитать больше о XSS? Ознакомьтесь с этими ресурсами, рассказывающими о том, как работает межсайтовый скриптинг:
- Глава книги по безопасности API о санитарной обработке данных от Okta
- Ресурс по межсайтовому скриптингу от Port Swigger Web Security Academy
Проверяйте подлинность запросов для смягчения CSRF
Подделка межсайтовых запросов (CSRF) — это еще одна известная уязвимость, занимающая первое место в десятке OWASP Top Ten, Broken Access Control. CSRF позволяет злоумышленникам использовать вашу личность для выполнения несанкционированных действий. Звучит довольно плохо, верно? Ну, да, вы правы.
Эксплойт работает следующим образом.
- Вы заходите на сайт K-Drama, чтобы проголосовать за несколько недавно просмотренных сериалов.
- Затем, потеряв рассудок, вы открываете письмо со спамом и нажимаете на ссылку, чтобы перевести деньги агитатору, утверждающему, что он ваш давно потерянный школьный возлюбленный. (О чем вы только думали!)
- По ссылке вы попадаете на вредоносный сайт со встроенной в него скрытой формой.
- Скрытая форма отправляет HTTP POST-запрос с ужасными комментариями на сайт K-Drama вместе с активной сессионной cookie.
- Поскольку у вас активная аутентифицированная сессия на сайте K-Drama, POST завершается так, как будто это вы добавляете ужасные комментарии к «Hospital Playlist»!
К счастью, в этом примере несанкционированное действие не является необратимым или разрушительным. Вы можете удалить ужасные комментарии, и вы можете объяснить, что на самом деле это не вы разместили такие комментарии для ужасных поклонников «Hospital Playlist». Однако вы можете представить, насколько опасным и вредоносным был бы этот эксплойт, если бы целью было что-то фундаментальное, например, банк!
Единственным способом защиты от CSRF является обеспечение легитимности запроса.
К счастью, в нашем распоряжении уже есть некоторые инструменты и действия, о которых мы рассказывали ранее, например:
- Предпочитать токены в HTTP-заголовках для аутентифицированных HTTP-вызовов и в идеале хранить эти токены в памяти.
- Настройте жесткий контроль CORS.
- Защищайте свои куки!
Эти механизмы настолько хороши, что некоторые говорят, что больше ничего не нужно делать для SPA!
Однако CSRF основывается на том, что ваш бэкенд не проявляет должного усердия при проверке подлинности запросов и позволяет принимать полезную нагрузку не в формате JSON. Хакеры очень умны, и вам может понадобиться разрешить <form> полезную нагрузку в вашем бэкенде, поэтому вам могут понадобиться дополнительные меры защиты. Если вам нужны дополнительные меры защиты, вы можете добавить уникальный CSRF-токен для связи между вашим фронтендом и бэкендом. Бэкэнд должен проверить стандартные средства аутентификации и авторизации и убедиться в легитимности CSRF-токена.
Токен генерируется бэкендом и отправляется на фронтенд. Затем фронтенд использует маркер при последующих обращениях к бэкенду, добавляя его в качестве пользовательского HTTP-заголовка.
Для SPA получение CSRF-токена от сервера — самая сложная задача. В традиционных веб-приложениях это не проблема. Но в SPA вы обращаетесь к внутреннему API только после загрузки приложения. Вам также нужна защита CSRF перед входом в систему, если вы не делегируете аутентификацию стороннему поставщику аутентификации. 😎
Рекомендуется, чтобы ваш клиент вызывал конечную точку на вашем бэкенде для получения CSRF-токена. Конечная точка должна быть очень бдительной в отношении подтверждения происхождения вызывающего абонента и очень строго следить за списком разрешений CORS.
Погрузитесь глубже в CSRF
Существует множество защит браузера, которые помогают нам смягчить CSRF. Просмотрите эти ссылки, если хотите узнать больше о CSRF.
- Предотвращение атак подделки межсайтовых запросов (CSRF) от Auth0
- Шпаргалка по предотвращению подделки межсайтовых запросов от OWASP
- Понимание CSRF от команды Express
Узнайте больше о распространенных веб-атаках
Следите за следующей статьей из этой серии, в которой мы глубже изучим CSRF и узнаем, как Angular помогает защититься от него.
Готовы узнать больше? Ознакомьтесь со следующими ресурсами.
- Сравнение куки и токенов для безопасной аутентификации
- Защита ваших веб-приложений от межсайтового скриптинга (XSS)
- OWASP Top Ten 2021: Похожие шпаргалки
Не забывайте следить за нами в Twitter и подписываться на наш канал YouTube, чтобы получить еще больше отличных уроков. Мы также будем рады услышать вас! Если у вас есть вопросы или вы хотите рассказать, какой учебник вы хотели бы увидеть следующим, пожалуйста, комментируйте ниже.