2010-04-09 4 views
10

ОБНОВЛЕНИЕ: GWT 2.3 вводит лучший механизм для борьбы с атаками XSRF. См http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.htmlGWT RPC - Достаточно ли этого для защиты от CSRF?


механизм RPC GWT в делает следующие вещи на каждом HTTP Request -

  1. Sets два пользовательских заголовков запроса - X-GWT-перестановками и X-GWT-Module-Base
  2. Наборы контент-тип как text/x-gwt-rpc; charset = utf-8

HTTP-запрос - это всегда POST, а на стороне сервера методы GET генерируют исключение (метод не поддерживается).

Кроме того, если эти заголовки не установлены или имеют неправильное значение, сервер не обрабатывает обработку с исключением «возможно, CSRF?». Или что-то в этом роде.

Вопрос: достаточен ли для предотвращения CSRF? Есть ли способ установить пользовательские заголовки и изменить тип контента в чистом методе подделки на основе межсайтового запроса?

ответ

6

Если этот GWT RPC используется браузером, он на 100% уязвим для CSRF. Тип содержимого можно установить в элементе html <form>. X-GWT-Permutation и X-GWT-Module-Base не включены в черный список Flash banned headers. Таким образом, можно использовать атаку CSRF с использованием flash. Единственным элементом заголовка, которому вы можете доверять для защиты CSRF, является «референт», но это не всегда лучший подход. По возможности используйте защиту CSRF на основе токенов.

Вот некоторые подвиги, которые я написал, которые должны пролить свет на неясную атаку, которую я описываю. Флеш-эксплойт для этого будет выглядеть примерно так: this и here - это эксплойт js/html, который изменяет тип содержимого.

Мой эксплойт был написан для Flex 3.2 и правила были изменены в Flex 4 (Flash 10) Вот latest rules, большинство заголовков можно обрабатывать только для запросов POST.

флэш-скрипт, который использует navigateTo() для CSRF: https://github.com/TheRook/CSRF-Request-Builder

+2

XmlHttpRequest, Flash и множество других технологий могут устанавливать пользовательские заголовки браузеров, но политика с одинаковым исходным кодом запускается и предотвратит создание другого сайта. Если на сервере нет lenient crossdomain.xml или возвращается Access-Control-Allow-Origin на произвольные веб-сайты, как будет работать запрос? Это оставляет нас только с формами/изображениями/iframe и т. П., Когда политика с одинаковым исходным кодом не применяется. Но я не знаю, как они могут настраивать пользовательские заголовки HTTP. Итак, как он уязвим? –

+0

.. и да, я согласен с защитой csrf на основе токенов, это лучший способ, но я хотел бы понять недостаток с их подходом. –

+0

@sri Очень хороший вопрос. Чтобы избавиться от этого эксплойта, вам нужно использовать малоизвестное свойство вспышки. Я опубликовал 2 эксплойта, которые делают то, что я описываю, я призываю вас использовать их. (Если у вас нет уязвимого программного обеспечения, по крайней мере, вы можете видеть, что запрос POST отправляется в другой домен, но сценарий не может «видеть» ответ из-за SOP) – rook

0

Я не уверен, если есть простой способ (я бы очень интересно узнать, что, тоже!), Но, по крайней мере, там, кажется, быть некоторыми продвинутыми способами для получения произвольных запросов на межсайтовый сайт с произвольными заголовками: http://www.springerlink.com/content/h65wj72526715701/ Я не купил бумагу, но реферат и введение звучат очень интересно.

Возможно, кто-то здесь уже прочитал полную версию статьи и может немного расшириться?

+0

Я поставил на флеш исходный код, который я написал, который изменяет заголовки HTTP и сообщение, чтобы использовать уязвимость csrf. – rook

+0

@rook: но, пожалуйста, повторно разместите его. – user2284570

3

Я знаю, что задал этот вопрос, но после нескольких дней исследований (спасибо указателям от Rook!), Я думаю, что у меня есть ответ.

Что GWT обеспечивает из коробки, не защитит вас от CSRF. Вы должны предпринять шаги, зафиксированные в Security for GWT Applications, чтобы оставаться в безопасности.

GWT RPC устанавливает заголовок «content-type» в «text/x-gwt-rpc; charset = utf-8». В то время как я не нашел способ установить это с помощью HTML-форм, это тривиально делать это во flash.

Пользовательские заголовки - X-GWT-Permutation и X-GWT-Module-Base - немного сложнее. Они не могут быть установлены с использованием HTML. Кроме того, они не могут установить с использованием Flash, если ваш сервер не разрешает его в crossdomain.xml. См. Flash Player 10 Security.

Кроме того, когда SWF файл хочет отправить пользовательские заголовки HTTP в любом , кроме своего собственного хозяина происхождения, должен быть файл политики на сервере HTTP, к которому запрос посылается , Этот файл политики должен перечислять хост файла SWF происхождения (или большего набора хостов), поскольку разрешено отправлять пользовательские запросы заголовкам на этот хост.

Теперь RPC GWT поставляется в двух вариантах. Существует старый формат RPC с произвольной сериализацией и новый, основанный на JSON де-RPC. AFAICT, клиентский код всегда задает эти заголовки запроса. Старый RPC стиля не применяет эти заголовки на стороне сервера, и поэтому возможна атака CSRF. Новый стиль de-RPC применяет эти заголовки, и поэтому может или не удастся атаковать их.

В целом, я бы сказал, если вы заботитесь о безопасности, убедитесь, что вы посылаете в свой запрос сильные жетоны CSRF, а не полагайтесь на GWT, чтобы предотвратить его.

+0

@sri. Вот новые правила для настройки заголовков: http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html Вы можете устанавливать их только на POST, а общие - черные перечисленные, в соответствии со всей информацией, которую вы опубликовали, элемент заголовка «X-GWT-Permutation» может управляться для запросов POST с использованием метода, который я использовал в моем эксплойте загрузки межсайтового файла. – rook

+0

Проверьте этот примерный код, который изменяет элемент заголовка 'pragma: no-cache': http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html#URLRequestHeader%28%29 Если у вас возникли проблемы с компиляцией моего кода, попробуйте собрать этот пример. – rook

+0

Ваш ответ был именно тем, что я искал, но это датируется с 2010 года. Я пытаюсь написать атаку PoC CSRF против RPC старого стиля, используя современную версию flash. Знаете ли вы, возможно ли это? Поскольку у цели _doesn't_ есть _crossdomain, xml_. Похоже, мой клиент Flash отправляет запрос на _crossdomain, xml_ на сервер, понимает, что такого файла нет, а затем не начинает выдавать мою полезную нагрузку CSRF. Были ли новые версии Flash по существу предотвращали такую ​​атаку даже на RPC старого стиля? – Juicy

4

GWT 2.3 вводит лучший механизм для борьбы с атаками XSRF. См. GWT RPC XSRF protection

+1

обновил вопрос, так что любой, кто посещает эту страницу, может легко найти его. Благодаря! –

+0

ли какая-либо независимая сторона подтвердила, что текущая (GWT 2.8.1) XsrfTokenServlet реализация обеспечивает безопасный способ защиты от XSRF? – user1050755

Смежные вопросы