REST и CSRF (подделка межсайтовых запросов)

Question

Возможна ли подделка межсайтовых запросов в отношении службы RESTful без состояния?

Я не говорю о псевдо-REST, когда сервер запоминает, что вы вошли через cookie. Я говорю о чистом REST без приложения-состояния на сервере без файлов cookie.

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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