2013-08-13 3 views
1

Мы недавно обсуждали атаку CSRF. Мой член команды сказал, что следующая атака CSRF: 1. Атакующий отправляет поддельный файл html, который может содержать поддельный запрос, например, похитить cookie, жертве 2. Жертва сохраняет файл 3. Жертва открывает доверенный веб-сайт, затем откройте файл html 4. Запрос файла выполненнастоящая атака CSRF?

Он может работать на погоне, позволяя пользователю выйти из системы. Ниже приводится сценарий:

<!DOCTYPE html> 
<html> 
<body> 

<p>Create a link of an image: 
<a href="default.asp"> 
<img src="smiley.gif" alt="HTML tutorial" width="32" height="32"></a></p> 

<p>No border around the image, but still a link: 
<a href="https://chaseonline.chase.com/secure/LogOff.aspx"> 
<img border="0" src="smiley.gif" alt="HTML tutorial" width="32" height="32"></a></p> 

</body> 
</html> 

Он может по крайней мере сделать себя успешно. Тем не менее, я чувствовал, что это потому, что файл выполняется локально, что заставляет его работать. Если я открою настоящий вредоносный веб-сайт или страницу, это может не сработать. Может ли кто-нибудь дать мне какие-нибудь идеи?

Спасибо ~

ответ

2

Хорошо, допустим, вы используете веб-сайт для банка. Предположим, что у вас есть конечная точка, которая запрашивает POST запрос https://bank.example.com/transfer с данными формы, содержащей какую учетную запись для перевода и сумму перевода. Конечно, вы проверите cookie сеанса, чтобы убедиться, что запрос поступает от пользователя с действительным сеансом.

Теперь злоумышленный веб-сайт может создать форму, содержащую номер счета, на который они хотят, чтобы деньги были отправлены, и какую-то произвольную сумму денег. Теперь все, что им нужно сделать, это опубликовать всех посетителей вредоносного сайта на https://bank.example.com/transfer. Любая жертва, которая попадает на злонамеренный сайт после входа на ваш банковский сайт (и получения действительного сеансового файла cookie), теперь может иметь деньги, украденные у них.

Стандартное исправление для этой атаки заключается в том, чтобы потребовать, чтобы все конечные точки, которые вызывают важное изменение состояния, также отправляли случайный, одноразовый секретный ключ, который является отдельным для кеша cookie пользователя (как правило, включал ваш веб-сайт на которую вы ожидаете от запроса).

0

Позвольте мне также принять классический пример атаки CSRF, когда злоумышленник обманывает жертву, чтобы перевести деньги на свой счет, при условии, что у потерпевшего есть активная сессия с банком. Эта атака требует, чтобы запрос POST был отправлен от имени жертвы, в то время как у него есть законная сессия с банком. Злоумышленник может заставить жертву посетить страницу, содержащую следующий HTML:

<html> 
<body> 
     <form name="hack_form" action="http://CrapyBank.com/csrf.php?menu=400&TransferFunds=4000" method="POST"> 
      <input type="hidden" name="hack_param" value="hack"> 
     </form> 
     <script type="text/javascript">document.hack_form.submit();</script> 
</body> 
</html>