Как защитить мой вызов api от атаки CSRF

Question

Я работаю над приложением angular js и попытался сделать простую страницу входа в систему и попытался запросить мой API-интерфейс для аутентификации моего входа в систему. Вот что и как я планировал сделать.

Примечание: Я предполагаю, что сервер отвечает за проверку моего токена и запроса.

Обеспечение usernamepassword к серверу через API вызова. При получении аутентификации сервер будет генерировать token для моего приложения (через которое я сделал звонок). Я сохранил это в своем браузере COOKIE. Этот файл cookie (токен auth) будет использоваться в дальнейшем приложением, чтобы каждый HTTP-вызов был передан API.

Теперь этот подход работает для меня отлично, но я считаю, что он открыт для CSRF attack.

Чтобы избежать CSRF attack моего браузера, я предоставляю идентификатор APP или (идентификатор версии) в свой код, который также отправляется с файлом cookie в API для http call.

Идея использования этой версия идентификатора или идентификатора приложения, это может рассматриваться в качестве подписи моего кода, т.е. запрос исходит от подписанных (проверено) приложений, который отведенные token=cookie значения.

Я просто хочу знать, насколько лучше мой подход и насколько он безопасен для моей основной точки приложения и для моего основного (широкого проекта) приложения.

Здесь я пытаюсь показать с помощью грубой схеме

извинения за этот крошечный вид и плохой почерк диаграммы.

Answer 1

Бактериальные системы, такие как Laravel, имеют довольно красивое здание: csrf-protection.

Вы можете передать токену Угловому с помощью постоянной функции углов: $provide#constant.

Итак, после инициализации вашего приложения вы можете сказать: angular.module('myApp').constant('<?php echo csrf_token(); ?>'); и Laravel остальное. Если вы хотите реализовать такую ​​технику самостоятельно, вы должны изучить исходный код Laravel: https://github.com/laravel/framework/blob/a1dc78820d2dbf207dbdf0f7075f17f7021c4ee8/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php.

Answer 2

Добавление идентификатора приложения + идентификатора версии для каждого запроса не будет защищать вашу систему от атаки CSRF, если только они не находятся в настраиваемом заголовке, - и если это возможно, просто используйте X-Requested-With, потому что любой нестандартный заголовок защищен если вы не включили CORS с открытой политикой.

Причина, по которой проверка идентификатора приложения + версии, заданной в строке запроса или данных POST, заключается в том, что злоумышленник может легко получить эту информацию, чтобы добавить идентификатор идентификатора приложения + версии к своим запросам на межсайтовый сайт. Другим методом, который будет работать для вас, является метод Double Submit Cookies. Создайте случайную 128-битную строку с использованием CSPRNG, а затем установите это как значение cookie (например, CSRFCookie). По каждому запросу вашего API также передайте это значение. например в строке запроса: CSRFCookie=<generated value>. На стороне сервера вы просто проверяете соответствие значений. Злоумышленник не знает значения cookie, поэтому они не могут добавить одно и то же значение в строку запроса.

У этого метода есть некоторые незначительные уязвимости, только реально используемые в сценарии MITM или если вы не контролируете все поддомены. Краткий ответ: Use HTTPS only for all your subdomains and implement HSTS.