REST и CSRF (Подпрограмма запроса на межсайтовый запрос)

Возможно ли кросс-Site Request Forgery в отношении службы RESTful без имени?

Я не говорю о псевдо-REST, где сервер помнит, что вы вошли в систему через файл cookie. Я говорю о чистом no-application-state-on-server REST без файлов cookie.

Я использую SSL и базовую аутентификацию. Для каждого запроса должен быть этот заголовок авторизации. В смысле JSP нет "сеанса", хотя на уровне SSL есть какой-то сеанс.

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

Когда вторая страница делает запрос Ajax, браузер будет помещен в тот же заголовок авторизации? т.е. браузер скажет: "О, ты хочешь пойти ТАМ снова? Эй, у меня просто все еще есть ключ!"

Кроме того, не удалось ли вредоносный script выполнить запрос xhr, а затем в обратном вызове выполнить запрос из ioargs, получить заголовок авторизации и un-Base64 имя и пароль?

Ответ 1

Отказ от ответственности: я не эксперт по безопасности.

Использование HTTP Basic Auth не предотвращает атаки CSRF через запросы GET. Например. кто-то еще может включать тег img на своей странице HTML, который выполняет GET на каком-то известном URI, и ваш браузер с радостью отправит основную информацию об аутентификации. Если операция GET "безопасна" (что является правилом № 1 для чего-либо, требующего быть RESTful), это не создаст проблемы (за пределами траты впустую).

Ajax не является проблемой из-за политики одного и того же происхождения.

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

Ответ 2

Необходима ли защита CSRF, зависит от 2 факторов:

Выполняет ли запрос действие по изменению состояния (не то же самое, что REST API Statelessness) - Действия по изменению состояния - это любое действие, которое изменит состояние приложения. Например, удалить что-то, добавить что-то, обновить что-либо. Это действия, с помощью которых приложение изменит резервное состояние пользователя. Все почтовые запросы и несколько запросов на получение попадают в эту категорию. REST API могут иметь действия по изменению состояния.
Является ли проверка подлинности браузером (не ограничивается только файлами cookie) - CSRF происходит потому, что информация аутентификации включена в запрос браузера независимо от того, был ли запрос запущен пользователем или какой-либо другой открытой вкладкой. Поэтому любой вид аутентификации, в который браузер может самостоятельно включать информацию, нуждается в защите CSRF. Это включает как сеансы на основе файлов cookie, так и базовую аутентификацию.

Для всех запросов, которые подпадают под 2 категории, необходима защита CSRF.

Как ответил Стефан выше, запросы Ajax защищены из-за единой политики происхождения (SOP). SOP не позволяет другому домену читать контент, отправленный целевым доменом. Таким образом, вредоносный скрипт не может прочитать заголовок авторизации. Но SOP не запрещает другому домену отправлять запросы в целевой домен. Таким образом, вредоносный скрипт может отправлять запросы на изменение состояния целевому домену. Браузер будет включать информацию аутентификации и куки в этот запрос, поэтому сервер должен знать, был ли этот запрос от вредоносного домена или пользователя. Из-за этого требуется защита CSRF.