Для предотвращения CSRF-атак необходимо настроить как бэкэнд (ASP.NET Web API), так и веб-интерфейс (Angular).
Взято из https://angular.io/guide/security#xsrf:
Чтобы предотвратить XSRF, приложение должно убедиться, что пользовательский запрос исходит из реального приложения, а не с другого сайта. Сервер и клиент должны сотрудничать, чтобы предотвратить эту атаку.
В обычном методе защиты от XSRF сервер приложений [backend] отправляет случайно сгенерированный токен аутентификации в файле cookie. Код клиента считывает cookie и добавляет произвольный заголовок запроса с токеном во все последующие запросы. Сервер сравнивает полученное значение cookie со значением заголовка запроса и отклоняет запрос, если значения отсутствуют или не совпадают.
Этот метод эффективен, потому что все браузеры реализуют одну и ту же политику происхождения. Только код с веб-сайта, на котором установлены файлы cookie, может считывать файлы cookie с этого сайта и устанавливать пользовательские заголовки для запросов к этому сайту. Это означает, что только ваше приложение может прочитать этот токен cookie и установить собственный заголовок. Вредоносный код на evil.com не может.
Имея это в виду, вот еще одна цитата из Angular HttpClient Docs, которая объясняет, как вы можете это реализовать.
Взято из https://angular.io/guide/http#security-xsrf-protection:
При выполнении HTTP-запросов перехватчик считывает токен из cookie-файла, по умолчанию XSRF-TOKEN, и устанавливает его в качестве HTTP-заголовка X-XSRF-TOKEN. Поскольку только код, выполняемый на вашем домене, может считывать cookie, бэкэнд может быть уверен, что HTTP-запрос поступил от вашего клиентского приложения, а не от злоумышленника.
По умолчанию перехватчик отправляет этот заголовок при всех изменяющихся запросах (POST и т. Д.) На относительные URL-адреса, но не на запросы GET / HEAD или на запросы с абсолютным URL-адресом.
вашему серверу необходимо установить токен в файле cookie для чтения в JavaScript, который называется XSRF-TOKEN, при загрузке страницы или при первом запросе GET. При последующих запросах сервер может проверить, что файл cookie соответствует HTTP-заголовку X-XSRF-TOKEN, и, следовательно, быть уверенным, что только код, работающий в вашем домене, мог отправить запрос. Маркер должен быть уникальным для каждого пользователя и должен проверяться сервером; это мешает клиенту создавать свои собственные токены. Установите для токена дайджест файла cookie аутентификации вашего сайта с солью для дополнительной безопасности.
Ключевые моменты, на которые следует обратить внимание:
- Когда угловое приложение загружено, оно должно сначала выполнить API-вызов к вашему бэкэнду, чтобы получить токен аутентификации, который сохраняется в виде файла cookie с именем «XSRF-TOKEN». Вероятно, где-то в корневом компоненте (app.component.ts) ngOnInit () звучит как хорошее место.
- По умолчанию токен аутентификации будет автоматически добавляться в заголовок http на все изменяющиеся запросы, такие как POST. (Обратите внимание на то, что это недокументировано: Angular 6 не добавляет заголовок X-XSRF-TOKEN в запрос http ). Если вы не вернете файл cookie с пользовательским именем, вам придется использовать HttpClientXsrfModule от Angular.
- Учитывая это, ваш веб-API ASP.NET также должен проверять XSRF-TOKEN при получении запросов.
Что касается вашего второго вопроса, перехват файлов cookie осуществляется через XSS.
Уязвимости XSS обычно возникают, когда приложение принимает пользовательский ввод и выводит его на страницу без проверки, кодирования или экранирования.
Angular по умолчанию очищает входные данные для тегов. Однако это при условии, что вы делаете вещи «угловым путем». Если вы используете сторонние библиотеки, такие как jQuery, для манипулирования DOM, а не с помощью модуля Angular renderer2, вы можете потерять эту защиту.
Взято из: https://angular.io/guide/security#xss:
Точно так же, если вы взаимодействуете с другими библиотеками, которые манипулируют DOM, у вас, скорее всего, не будет такой же автоматической очистки, как с угловыми интерполяциями. Избегайте прямого взаимодействия с DOM и вместо этого используйте угловые шаблоны, где это возможно.
В случаях, когда это неизбежно, используйте встроенные функции угловой очистки. Очистите ненадежные значения с помощью метода DomSanitizer.sanitize и соответствующего SecurityContext.
Чтобы повысить безопасность, вы также должны очистить все изменяющиеся запросы (например, PUT или POST) в своем бэкэнде.
Трудно предоставить вам примеры кода, потому что ваш вопрос кажется более теоретическим.
Я надеюсь, что вы прочтете те ссылки, которые я указал выше. Они определенно более подробны и хорошо объяснены. Я надеюсь, что это, по крайней мере, укажет вам правильное направление, с чего начать.