Основной вопрос о CSRF-атаках - PullRequest
0 голосов
/ 21 января 2011

Я перехожу с программирования на «веб-программирование», так что это может показаться слишком простым

Мой вопрос касается HTTP-запроса, на который «сайт жертвы» отвечает некоторой «непубличной / конфиденциальной» информацией, такой как HTML, XML или JSON.

А сайт-жертва просто полагается на файлы cookie сеанса для проверки подлинности, прежде чем ответить «непубличной» информацией для запроса http.

Если на сайте хакера есть JS, который отправляет HTTP-запрос ajax на «сайт жертвы», а пользователь уже вошел на «сайт жертвы» и, следовательно, имеет cookie для сайта жертвы в браузере.

Будет ли ответ на запрос ajax "сервером-жертвой", и если да, сможет ли JS-хакеры опубликовать эту "непубличную" информацию обратно на сайт хакеров.

Как можно предотвратить это?

Ответы [ 3 ]

2 голосов
/ 21 января 2011
  1. Вы не можете сделать запрос через AJAX в другой домен, кроме того, в котором выполняется JS с AJAX.

    Если сайт жертвы - example.com, а сайт хакера - example2.com, то файл JS из example2.com не может сделать запрос AJAX на другой сайт, отличный от example2.

  2. Файлы cookie с сервера жертвы, которые есть у клиента, не будут отправляться на сервер хакера в HTTP-запросе. Файлы cookie могут быть украдены, если на сайте жертвы есть XSS, который можно использовать для отправки файлов cookie с этого сайта хакерам.

0 голосов
/ 21 января 2011

ajax в строгом смысле (xmlhttprequest), как правило, обычно считается ограниченным одним и тем же доменом, но многое (если не все) зависит от того, как браузеры реализуют модель безопасности.Одна вещь, которую я заметил, заключается в том, что Firefox будет выдавать междоменный запрос даже с обычным (не междоменным) ajax, но он блокирует поступление всего ответа (похоже, он прерывает запрос, что приводит к коду ответа http 206).это означает, что, по крайней мере, в Firefox «вызовы записи» должны быть защищены от CSRF-атак даже для обычного ajax.

рядом с такими сбоями браузера, как большинство браузеров также поддерживают ' междоменное совместное использование ресурсов ', которое также можно использовать с xmlhttprequests.когда все сделано правильно, междоменный ajax может быть довольно безопасным.

, но принятие CORS, похоже, затрудняется успехом ' jsonp ';динамически вставленные сценарии, содержащие данные в формате json, обернутые в параметр обратного вызова, которые не ограничены одним и тем же принципом домена.сделать это безопасным способом (т. е. запретить злоумышленнику динамически вставлять и выполнять сценарий с сайта-жертвы для вошедшего в систему пользователя, для которого cookie-файлы действительно будут отправляться), несколько сложнее (требующий токен, подобный сеансу, в каждом запросекоторого нет в cookie).

вывод: операции чтения с использованием традиционного ajax безопасны, для записи и jsonp вам придется проделать дополнительную работу, чтобы быть в безопасности.если вы действительно хотите перейти на несколько доменов, вам, вероятно, следует рассмотреть CORS как альтернативу jsonp.

0 голосов
/ 21 января 2011

В Википедии есть несколько быстрых советов: http://en.wikipedia.org/wiki/Csrf

Сократите время жизни ваших файлов cookie сеанса.Если вы вышли из системы после 15 минут бездействия, у вас меньше шансов стать жертвой проблем.Не очень дружелюбно, но это стоит учитывать, исходя из ценности ваших данных.

Проверьте Referer: заголовки, чтобы увидеть, что они пришли с вашего сайта.Не хорошо.Даже не хорошо.Но это что-то.

Используйте пользовательское содержимое формы, чтобы не дать злоумышленникам создать простую форму. POST: Понимание токена подлинности Rails Этот механизм хорош, и если ваша инфраструктура поможет вам в этомпочти безболезненно с твоей стороны.Если ваш фреймворк вам не помогает, то это еще одна причина рассмотреть более хороший фреймворк.:)

...