Как вы защищаетесь от конкретной атаки CSRF

Question

Я иду через список OWASP Top 10 из 2007 и 2010 .

Я наткнулся на подделку межсайтовых запросов (CSRF), которую часто называют сессионной ездой, поскольку вы позволяете пользователю использовать свою сессию для выполнения ваших желаний.

Теперь решением этой проблемы является добавление токена к каждому URL, и этот токен проверяется для каждой ссылки.

Например, для голосования по продукту х будет URL:

'http://mysite.com?token=HVBKJNKL'

Это похоже на твердое решение, потому что хакер не может угадать токен.

Но я думал о следующем сценарии ( Я не знаю, возможно ли это ):

Вы создаете сайт со скрытым iFrame или div. После этого вы можете загрузить в него мой веб-сайт, используя обычный iFrame или ajax.

Когда мой веб-сайт загружен скрытым внутри вашего веб-сайта, а у пользователя есть сохраненный сеанс, можно сделать следующее. Вы можете получить токен из URL-адресов и при этом выполнить все необходимые действия.

Можно ли сделать что-то подобное? Или это невозможно сделать кросс-домен.

Answer 1

Атака, которую вы описываете, является явным нарушением политики Same Origin . iframe не наследуют привилегии таким образом. Много обходных путей к той же самой политике происхождения были обнаружены. Единственный способ решить эти проблемы - люди, задающие такие вопросы. Я призываю вас попробовать написать код, чтобы обойти проблему, даже если она не удалась. В худшем случае вы узнаете что-то важное, в лучшем случае вы найдете проблему, опубликуете ее на bugtraq и устроите вечеринку :). О, и все будут безопаснее для исправления ошибки.

XSS может использоваться для обхода защиты, предоставляемой той же политикой происхождения для конкретного уязвимого сайта. Уязвимость XSS можно использовать для чтения токена XSRF с помощью XmlHttpRequest. Здесь - это эксплойт, который написал это.

Answer 2

Этот сценарий на самом деле не возможен, потому что в то время как они могли бы кадрировать до http://mysite.com,, им понадобился бы токен, чтобы превратить его в http://mysite.com? Token = HVBKJNKL . И если у них есть жетон, то вы все равно не в безопасности.