2010-03-31 3 views
11

По умолчанию защита сообщения CSRF формы в Rails создает токен аутентификации для пользователя, который изменяется только при изменении сеанса пользователя. Один из наших клиентов проверил аудит безопасности нашего сайта и отметил, что это проблема.Является ли защита CSRF по умолчанию Rails небезопасной?

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

Но мне кажется, что если бы у нас была такая уязвимость XSS, злоумышленник мог так же легко захватить cookie сеанса другого пользователя и войти в систему как пользователь. Или даже просто звоните в наш REST Api из сценария, поскольку на него нападают пользователи. Возможность установки атаки CSRF в такой ситуации не кажется хуже, проблема заключается в уязвимости XSS.

Я что-то пропустил? Есть ли реальная проблема с защитой CSRF по умолчанию в Rails?

+0

Обратите внимание, что уязвимость в CSRF для Rails была обнаружена и существует в Rails версии 3.0.3 и ниже. См. Http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails. Обновите до 3.0.4, чтобы устранить эту проблему. –

+0

В качестве побочного примечания, файлы cookie сеанса должны быть установлены на «HttpOnly», поэтому они не могут быть украдены XSS. –

ответ

11

Вы совершенно правы. Защита, основанная на токенах CSRF, является наиболее распространенной и до тех пор, пока вы тестируете приложение для XSS, все должно быть в порядке.

Есть случаи, когда CSRF можно остановить, независимо от XSS. Например, для вашего форума смены пароля требуется, чтобы они знали текущий пароль. Хакер не сможет подделать этот запрос, если он не знает текущий пароль, спорный вопрос.

Другой метод - потребовать, чтобы Captcha решался для этого запроса. Я рекомендую использовать reCapthca.

+0

Технически, если у вас есть форма, которая требует ввода пользователем пароля в дополнение к другим данным, вы не защищаете от CSRF или XSS, а украденных сеансов. Атака CSRF заключается в возможности выполнять команды на другом сайте с использованием учетных данных текущего сеанса браузера. –

+0

Обратите внимание, что если у вас есть уязвимость XSS и форма, требующая от пользователя ввода пароля, отличного от OTP, злоумышленник получил пароль пользователя! –

+0

@ Микко Ранталайнен, который будет фишировать, а не CSRF. Вы можете использовать xss для перезаписи тела страницы на форум, который принимает пароль. Но если есть форма, запрашивающая пароль на какой-либо другой странице, XSS не может использоваться для чтения этого пароля, потому что ее нельзя прочитать с помощью XHR. – rook