Вопрос по web-services, rest – Являются ли службы JAXRS restful подверженными CSRF-атакам, когда включено согласование типов контента?

4

У меня есть RESTful API с аннотациями, такими как @Consumes (MediaType.JSON) - в таком случае, будет ли CSRF-атака все еще возможна на таком сервисе? Я возился с защитой своих сервисов с помощью CSRFGuard на стороне сервера или с двойной передачей со стороны клиента. Однако когда я попытался отправить запросы POST, используя FORM с enctype = & quot; text / plain & quot ;, это не сработало. Техника объясняетсяВот Это работает, если у меня есть MediaType.APPLICATION_FORM_URLENCODED в моей аннотации потребления. Согласование содержимого полезно, когда я использую глаголы POST / PUT / DELETE, но GET все еще доступен, что может потребовать изучения.

Любые предложения или предложения будут хорошими, также, пожалуйста, дайте мне знать, если вам нужна дополнительная информация.

ура

Интересно, что никто не имеет мнения по этому поводу ... или мой вопрос не так ясен? хммм opensourcegeek

Ваш Ответ

2   ответа
9

JAX-RS предназначен для создания REST API, который должен быть без сохранения состояния. Подделка межсайтовых запросов НЕ является проблемой для приложений без сохранения состояния.

Способ подделки межсайтовых запросов заключается в том, что кто-то может заставить вас щелкнуть ссылку или открыть ссылку в вашем браузере, которая направит вас на сайт, на котором вы вошли, например на какой-нибудь онлайн-форум. Поскольку вы уже вошли на этот форум, злоумышленник может создать URL-адрес, скажите что-то вроде этого: someforum.com/deletethread?id=23454

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

Все потому, что программа аутентифицировала вас на основе файла cookie сеанса (даже на основе файла cookie "запомнить меня")

В RESTful API нет cookie, состояние не поддерживается между запросами, поэтому нет необходимости защищать от перехвата сеанса.

Обычно вы аутентифицируетесь с помощью RESTFul api, отправляя дополнительные заголовки. Если кто-то заставит вас щелкнуть URL-адрес, указывающий на API-интерфейс restful, браузер не будет отправлять эти дополнительные заголовки, так что риска нет.

Вкратце - если REST API спроектирован так, как и предполагалось, - без сохранения состояния, тогда нет риска подделки между сайтами и не требуется защита CSRF.

Это было бы плохим дизайном. Клиент API может быть каким-то приложением, а не браузером и вообще не будет ожидать получения файлов cookie. Использование файлов cookie в REST API - довольно плохая практика.
Безусловно, сейчас наш API защищен с использованием как базовой, так и основанной на форме аутентификации. Поэтому некоторые другие приложения, которые не являются браузерами, проходят базовую аутентификацию, они отправляют имя пользователя и маркер безопасности при каждом запросе через HTTPS. Это пользователи, сгенерированные системой, и они имеют доступ к части API. Однако в приложении на основе браузера мне нужно было аутентифицировать пользователя, используя аутентификацию на основе форм. Вы можете избежать обхода пользователями, чтобы получить принципал по каждому запросу, если он удерживается в сеансе после первой проверки. opensourcegeek
Ваш RESTful API может находиться за рамками безопасности, такими как spring security, что означает, что вам нужно будет проходить проверку подлинности в этой среде. В этом случае он пишет cookie, чтобы идентифицировать вас как аутентифицированного пользователя. Как только пользователь будет идентифицирован, будут доступны обычные сервисные вызовы для данных GET / POST / DELETE / PUT. Таким образом, в этом случае сама служба не остается без сохранения состояния, однако служба находится за структурой безопасности, которая имеет состояние. В любом случае, мой основной интерес состоял в том, чтобы проверить, смог ли кто-нибудь выполнить CSRF-атаку, когда включено согласование типов контента, так как я не смог ее взломать. opensourcegeek
0

Добавление другого ответа в качестве ответа Дмитрия смешивает состояние сервера и файлы cookie.

Приложение не остается без состояния, если ваш сервер хранит пользовательскую информацию в памяти по нескольким запросам. Это уменьшает горизонтальную масштабируемость, так как вам нужно найти & quot; правильный & quot; Сервер для каждого запроса.

Cookies - это особый вид HTTP-заголовка. Они часто используются для идентификации сеанса пользователя, но не каждый файл cookie означает состояние на стороне сервера. Сервер также может использовать информацию из файла cookie, не запуская сеанс. С другой стороны, использование других заголовков HTTP не обязательно означает, что ваше приложение автоматически сохраняет состояние. Если вы храните пользовательские данные в памяти вашего сервера, это не так. Разница между файлами cookie и другими заголовками заключается в том, как они обрабатываются браузером. Наиболее важным для нас является то, что браузер будет отправлять их при каждом последующем запросе. Это проблематично, если кто-то обманывает пользователя, чтобы он сделал запрос, который он не хочет делать.

Это проблема для API, который использует JSON? Да, в двух случаях:

  • The attacker makes the user submit a form with enctype=text/plain: Url encoded content is not a problem because the result can’t be valid JSON. text/plain is a problem if your server interprets the content not as plain text but as JSON. If your resource is annotated with @Consumes(MediaType.JSON) you should not have a problem because it won’t accept text/plain and should return a status 415. (Note that JSON may become a valid enctype one day and this won’t be valid any more).
  • The attacker makes the user submit an AJAX request: The Same Origin Policy prevents AJAX requests to other domains so you are safe as long as you don’t disable this protection by using CORS-headers like e.g. Access-Control-Allow-Origin: *.

Похожие вопросы