Наиболее распространенные уязвимости, на которые следует обратить внимание в приложениях Angular и React: внедрение шаблонов, XSSI, обход аутентификации и многое другое.

Защита приложений — не самая простая задача. Приложение состоит из множества компонентов: логика на стороне сервера, логика на стороне клиента, хранилище данных, транспортировка данных, API и многое другое. Со всеми этими компонентами для защиты создание безопасного приложения может показаться действительно сложной задачей.

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

Использование каждого языка, платформы или среды подвергает приложение уникальному набору уязвимостей. Первый шаг к устранению уязвимостей в вашем приложении — знать, что искать.

Сегодня давайте рассмотрим шесть наиболее распространенных уязвимостей, которые затрагивают приложения Angular и React, и способы их обнаружения и предотвращения. Уязвимости, о которых я расскажу в этом посте:

Обход аутентификации

Под аутентификацией понимается подтверждение личности перед выполнением конфиденциальных действий или доступом к конфиденциальным данным. Если аутентификация реализована в приложении неправильно, злоумышленники могут использовать эти неправильные настройки для получения доступа к функциям, которые им не положено.

Например, маршрутизация в Angular обычно выполняется с помощью файла AppRoutingModule. Прежде чем направлять пользователей на конфиденциальные маршруты в приложении, вы должны проверить, прошел ли пользователь аутентификацию и авторизован для доступа к этому ресурсу.

Подробнее о том, как правильно настроить аутентификацию в Angular и React, читайте в этих учебниках.

Верни меня обратно наверх.

Неправильный контроль доступа

Неправильный контроль доступа возникает каждый раз, когда контроль доступа в приложении реализован неправильно и может быть обойден злоумышленником. Проблемы с обходом аутентификации, по сути, являются типом неправильного контроля доступа. Однако управление доступом включает в себя больше, чем аутентификацию. В то время как аутентификация просит пользователя подтвердить свою личность: «Кто вы?», авторизация спрашивает приложение: «Что разрешено делать этому пользователю?». Надлежащая аутентификация и авторизация вместе гарантируют, что пользователи не смогут получить доступ к функциям за пределами их разрешений.

Существует несколько способов настройки авторизации для пользователей: управление доступом на основе ролей, управление доступом на основе владения, списки контроля доступа и многое другое. Вот несколько хороших постов для справки по реализации контроля доступа в Angular и React.

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

Верни меня обратно наверх.

Открытые перенаправления

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

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

Чтобы предотвратить открытые перенаправления, вам необходимо убедиться, что приложение не перенаправляет пользователей в вредоносные места. Например, вы можете полностью запретить внешние перенаправления, проверив URL-адреса перенаправления:

Есть много других способов предотвращения открытых перенаправлений, таких как проверка реферера запросов или использование индексов страниц для перенаправлений. Но поскольку проверить URL-адреса сложно, открытые перенаправления остаются распространенной проблемой в современных веб-приложениях.

Верни меня обратно наверх.

Подделка межсайтовых запросов

Подделка межсайтовых запросов (CSRF) — это техника на стороне клиента, используемая для атаки на других пользователей веб-приложения. Используя CSRF, злоумышленники могут отправлять HTTP-запросы, которые якобы исходят от жертвы, выполняя нежелательные действия от имени жертвы. Например, злоумышленник может изменить ваш пароль или перевести деньги с вашего банковского счета без вашего разрешения.

В отличие от открытых перенаправлений, существует надежный способ предотвращения CSRF: использование комбинации токенов CSRF и файлов cookie SameSite и отказ от использования GET-запросов для действий по изменению состояния. Например, Angular позволяет добавлять токены защиты от подделки в HTTP-запросы с помощью модуля HttpClientXsrfModule:

Верни меня обратно наверх.

Внедрение шаблона

Веб-шаблоны — это HTML-подобные файлы, которые предоставляют разработчикам возможность указать способ отображения страницы путем объединения данных приложения со статическими шаблонами. Эта функциональность позволяет разработчикам вставлять динамическое содержимое, полученное из базы данных или из HTTP-запроса, на веб-страницы.

Внедрение шаблона относится к внедрению в веб-шаблоны. В зависимости от разрешений скомпрометированного приложения злоумышленники могут использовать уязвимость внедрения шаблона для чтения конфиденциальных файлов, выполнения кода или повышения своих привилегий в системе. Например, вот небезопасное использование шаблона Angular, который позволяет злоумышленникам внедрять код через хэши URL:

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

Узнайте больше о том, как работают инъекции шаблонов и как их предотвратить в Angular и React.

Верни меня обратно наверх.

Включение межсайтового скрипта

Атаки с включением межсайтовых сценариев также называются XSSI. Эти атаки происходят, когда вредоносный сайт включает Javascript с сайта-жертвы для извлечения конфиденциальной информации из скрипта.

Политика единого источника (SOP) обычно контролирует доступ к данным из разных источников. Но SOP не ограничивает код JavaScript, а тег HTML <script> позволяет загружать код Javascript из любого источника. Это чрезвычайно удобная функция, которая позволяет повторно использовать файлы JavaScript в разных доменах. Но эта функция также представляет угрозу безопасности: злоумышленники могут украсть данные, записанные в файлах JavaScript, загрузив файлы JS своих жертв.

Например, представьте, что веб-сайт хранит и передает конфиденциальные данные для вошедших в систему пользователей через файлы Javascript. Если пользователь посещает вредоносный сайт в том же браузере, вредоносный сайт может импортировать этот файл JavaScript и получить доступ к конфиденциальной информации, связанной с сеансом пользователя, благодаря файлам cookie пользователя, хранящимся в браузере. Посмотрите пример этой уязвимости и узнайте, как их предотвратить в Angular и React.

Чтобы избежать XSSI-атак, не переносите конфиденциальные данные в файлы JavaScript. Вот пример того, как безопасно загрузить токен API в Angular, используя файлы JSON (которые ограничены SOP):

Верни меня обратно наверх.

Какие еще концепции безопасности вы хотели бы узнать? Я хотел бы знать. Не стесняйтесь общаться в Твиттере @vickieli7.

Теперь, когда вы знаете, как исправить эти уязвимости, защитите свое приложение Javascript, просканировав эти уязвимости! ShiftLeft CORE (https://www.shiftleft.io/shiftleft-core/) может найти эти уязвимости в вашем приложении, показать вам, как исправить эти ошибки, и защитить вас от проблем с безопасностью Javascript.