GWT - Работа с XSRF / CSRF - PullRequest
2 голосов
/ 25 мая 2011

Правильно ли, что если я передам самогенерируемый sessionID с каждым RPC-запросом и проверю только этот sessionID вместо идентификатора, переданного в заголовке cookie, сеанс не может быть взломан вредоносными сайтами? Я знаю, что вы также должны отправить этот идентификатор сеанса в файл cookie, а затем сравнить его с идентификатором, отправляемым при каждом запросе для обнаружения атаки XSRF, но мой способ должен по крайней мере защитить от атак XSRF, не так ли?

EDIT

Я знаю, что GWT 2.3 заботится о XSRF, предоставляя поддержку токенов XSRF. К сожалению, я застрял с GWT 2.2 и поэтому должен разобраться с ним сам.

Ответы [ 2 ]

3 голосов
/ 01 июня 2011

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

Однако при таком подходе я бы знал, что злоумышленник все еще может скомпрометировать ваш самостоятельно созданный sessionID и использовать его, как только выяснит механизм.

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

1 голос
/ 20 июня 2011

Возможно, вы захотите взглянуть на Проект CSRF Guard OWASP . Они используют фильтр, который проверяет каждый запрос к серверу на наличие требуемого токена CRSF. Это вполне настраивается - вы можете указать различные аспекты вашей защиты, например:

  • URL, которые не требуют защиты
  • форма входа в которую токен CRSF генерируется (при входе в систему)
  • поведение при возможной атаке (переадресация, регистрация) и т. д.

Это эффективное решение, которое не требует изменения кода, когда последняя версия также поддерживает вызовы AJAX (RPC) на сервер. Поэтому я считаю, что это определенно вариант, чтобы попробовать (в настоящее время я разрабатываю это решение для довольно большого приложения GWT).

Наконец, я верю, что вы уже создали свою защиту против XSS. Поскольку защита XSRF может быть аннулирована, если XSS возможен (не говоря уже о том, что атаки XSRF обычно запускаются через XSS).

...