Предотвращение CSRF с помощью Express API и внешнего интерфейса React
Я читал о CSRF в течение последних нескольких дней и чувствую, что хорошо понимаю, что это такое и как его предотвратить. Я создаю небольшое приложение Express/React, которое будет иметь безопасную область администратора для обновления содержимого приложения, и я хочу, чтобы оно было защищено от CSRF.
Я понимаю, что сервер обычно генерирует токен CSRF, а затем отправляет его клиенту вместе с запрошенным представлением (страницей) (затем токен может быть скрыт в теге ввода HTML-формы). Однако мой Express API не обслуживает HTML, это REST API, который возвращает только данные JSON. Пользовательский интерфейс построен с помощью React, работающего на другом порту, отличном от сервера.
Мой вопрос; Где безопасно хранить токен, сгенерированный на сервере?
Например, если я войду в систему как администратор, нажав «/api/login», сгенерирую токен и отправлю его обратно клиенту в ответе API, что мне теперь с ним делать?
Первоначальный план состоял в том, чтобы использовать Redux для хранения токена, но, прочитав этот пост, Безопасен ли Redux?, звучит не идеально.
Я рассматривал возможность использования переменных окружения React, но также читал, что они доступны в сборке.
Очевидно, что localStorage тоже плохая идея...
Я действительно изо всех сил пытаюсь найти решение этой проблемы, используя инструменты, которые я реализую, т.е. Express/React.
Любая помощь, ссылки, советы, критика будут оценены, я хочу научиться создавать приложения с учетом безопасности.
Привет @Nick, спасибо за ответ. Основываясь на вашем комментарии, я только что нашел пакет npm под названием react-cookies, это то, что вы использовали / рекомендовали?
Я никогда не слышал об этом. Я полагаю, что существует библиотека внутренних узлов под названием «csurf», которая будет создавать токены CSRF и иметь возможность отправлять файлы cookie. Некоторые библиотеки выборки (например, axios) на самом деле автоматически находят токены CSRF в файлах cookie и преобразовывают их в заголовки при отправке обратно на сервер.
Хорошо, большое спасибо, как только я найду способ сделать это, я напишу ответ на этот вопрос, если никто не ответит на него первым. Спасибо друг
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 1
Я понимаю, что сервер обычно генерирует токен CSRF.
Сервер должен сгенерировать два токена CSRF.
а затем отправить его клиенту вместе с запрошенным представлением (страницей) (затем токен может быть скрыт в теге ввода HTML-формы).
Один токен обычно отправляется в виде файла cookie, другой может быть отправлен в виде заголовка HTTP. Его не нужно отправлять внутри тела HTML в качестве тега ввода HTML-формы (или любой другой части тела), хотя его можно отправить таким образом.
Мой вопрос; Где безопасно хранить токен, сгенерированный на сервере?
Вам не нужно хранить токен на сервере. Вы можете, но вам не нужно.
Первоначальный план состоял в том, чтобы использовать Redux для хранения токена.
Магазин Redux находится на клиенте, в памяти браузера. Теоретически один компонент React (который извлекает второй токен CSRF из ответа сервера) может временно хранить токен в хранилище, чтобы другой компонент React мог получить его оттуда и поместить в следующий запрос, прежде чем он будет отправлен на сервер.
Очевидно, что localStorage тоже плохая идея...
Да
Любая помощь, ссылки, советы, критика будут оценены, я хочу научиться создавать приложения с учетом безопасности.
Ссылки
С Express очень часто используется это промежуточное ПО. Шаги можно найти здесь.
Критика
Строго говоря, это не по теме в контексте вопросов и ответов, связанных с CSRF, но...
Пользовательский интерфейс построен с помощью React, работающего на другом порту, отличном от сервера.
Это намекает на возможность использования react-scripts, которые начинают webpack-dev-server. Это хорошо для разработки, но не для развертывания в производстве. Однако это отдельная тема, передача артефактов сборки приложения React (файл .html, пакеты скриптов) веб-клиентам не имеет ничего общего с атакой CSRF и ее смягчением.
Я хочу научиться создавать приложения с учетом безопасности
Затем вы можете рассмотреть возможность использования одного веб-сервера вместо двух (интерфейс для обслуживания приложения React и сервер для обслуживания ответов API). Использование одного сервера приводит к производственному развертыванию, которое не только менее сложное и дорогостоящее, но и более безопасное, поскольку два сервера имеют большую поверхность атаки, а с одним сервером вам не нужно ослаблять безопасность с помощью CORS.
Спасибо @winwin1 за этот разбор, который дал мне много пищи для размышлений. Последний абзац особенно интересен, так как есть так много руководств, которые готовы помочь вам настроить запуск внешнего сервера для React, даже не упоминая о последствиях для безопасности. Ваш взгляд очень освежает и практически не упоминается ни в одном из ресурсов, которые я использовал для изучения разработки React. Спасибо за информацию
Я предпочитаю для SPA использовать токен CSRF cookie-to-header. По сути, до тех пор, пока ваш внешний интерфейс может быть сохранен в файле cookie вашим бэкэндом, ваш внешний JS сможет прочитать этот файл cookie и отправить его обратно в виде отдельного заголовка на серверную часть. Злоумышленники не смогут этого сделать, потому что они не видят файлы cookie. typeofnan.dev/…