Защита NodeJS CSRF с включенными Express, GraphQL и CORS

Вы можете сгенерировать клиентскую сторону cookie (используя window.crypto), затем попросить JS прочитать его и отправить в заголовке, сервер просто должен проверить, что они совпадают. Но это уязвимо из-за того, что файл cookie не является HttpOnly (потому что ваш JS должен его прочитать!). По этой причине этот метод не лучший, но он лучше, чем ничего.

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

На самом деле нет ничего плохого в том, чтобы иметь маршрут API, который генерирует токен для каждого запроса, хотя это приводит к удвоению плотности запросов (вам нужен новый токен для каждого запроса!). Причина этого в том, что злоумышленник не может прочитать ответ с внешнего сайта (CORS предотвратит это). Тогда вы не будете уязвимы для использования файлов cookie, поскольку вы вообще никогда не храните файлы cookie.

Редактировать: Я вижу, вы намекаете на то, что CORS * включен для этой конечной точки, чтобы она была общедоступной. Если ваш API действительно общедоступен, вам, вероятно, лучше будет использовать аутентификацию OAuth2 / JWT, так как CSRF становится неактуальным, поскольку аутентификация происходит не из файлов cookie.

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

Вы также можете сохранить файл cookie из запроса getCsrfToken() и оставить его действительным в течение некоторого времени, но сделать его HttpOnly, поскольку он был выпущен API, API будет отвечать за получение действительного токена CSRF.

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

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

Ваша последняя идея (при условии, что вы хотите настоящую анонимность), вероятно, лучшая. При условии, что пользовательский агент заслуживает доверия, заголовки referer и Origin не могут быть изменены, поэтому, если вы счастливы заблокировать свой API только для доменов, на которых работает ваш JS, тогда выполнение проверки referer / Origin на стороне сервера не будет быть легко обойденным злоумышленником. Это не лучшая практика, но практически эффективна.

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

Последнее, что следует отметить, это то, что CSRF является альтернативным вектором атаки XSS, но если у вас есть уязвимости XSS, защита CSRF обычно устаревает, поэтому убедитесь, что вы сначала защищаете XSS, прежде чем внедрять защиту CSRF.