но подобные атаки уже существуют и совсем не зависят от XMLHTTPRequest.

у было решено, что с помощьюXMLHTTPRequest для выполнения вызовов XML не должны делать вызовы через границу домена? Вы можете извлечь JavaScript, изображения, CSS, iframes и любой другой контент, который я могу придумать, из других доменов. Почему HTTP-запросы Ajax не могут пересекать границы домена? Это кажется странным ограничением, если принять во внимание, что единственный способ, которым я вижу, что он злоупотребляет, - это если кто-то вставит Javascript на страницу. Однако в этом случае вы можете просто добавить в документ элемент img, script или iframe, чтобы он запросил сторонний URL-адрес и отправил его на сервер.

[Редактировать]

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

XSRF (подделка межсайтовых запросов, также известная как CSRF, XSRF)

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

Публикация на стороннем сайте
<script type="text/javascript">
  $.post("http://some-bank.com/transfer-money.php", 
         { amount: "10000", to_account: "xxxx" })
</script>

Может быть достигнуто с

<body onload="document.getElementById('InvisbleForm').submit()"
    <div style="display:none">
        <form id="InvisbleForm" action="http://some-bank.com/transfer-money.php" method="POST">
            <input type="hidden" name="amount" value="10000">
            <input type="hidden" name="to_account" value="xxxxx">
        </form>
    </div>
</body>
JPunyon: почему вы оставляете уязвимость в новой функции

Вы не создаете больше неуверенности. Вы всего лишь причиняете неудобства разработчикам, которые хотят использовать его для пользы. Любой, кто хочет использовать эту функцию для зла (иначе удивительный), мог бы просто использовать другой способ сделать это.

Заключение

Я отмечаю ответ отbobince как правильно, потому что он указал на критическую проблему. Поскольку XMLHTTPRequest позволяет отправлять учетные данные (файлы cookie) на целевой сайт и считывать данные, отправленные обратно с сайта, наряду с отправкой учетных данных пользователей, вы можете организовать некоторый javascript, который будет представлять серию форм, включая формы подтверждения , дополните любые сгенерированные случайные ключи, которые были введены в действие, чтобы попытаться предотвратить XSRF. Таким образом, вы можете просматривать целевой сайт, например, банк, и веб-сервер банка не сможет сказать, что это был не обычный пользователь, отправляющий все эти формы.

 Shawn21 янв. 2009 г., 21:44
модифицировать эти атаки, потому что они на самом деле являются атаками xsrf. xss, когда вы вводите скрипт на сайт законных страниц
 Kirill Kobelev12 окт. 2012 г., 07:28
@ Кибби, ты здесь? Я хочу отредактировать ваше сообщение, чтобы сделать его более понятным. В некоторых случаях я не совсем понимаю ваш английский. Будете ли вы отзыв?
 Kirill Kobelev13 окт. 2012 г., 01:19
Я решил написать свой ответ. Можете ли вы взглянуть?
 Kibbee12 окт. 2012 г., 14:41
@KirillKobelev Редактирование выглядит хорошо для меня. Приятно видеть, что этот старый вопрос все еще жив и здоров.
 Sever02 окт. 2015 г., 15:02
«Потому что XMLHTTPRequest позволяет вам отправлять с учетными данными (куки) на целевой сайт и читать данные, отправленные обратно с сайта». Затем злоумышленник просто использует, например, заголовок ('Access-Control-Allow-Origin: *') и может прочитать данные, отправленные обратно с сайта, создать формы для отправки и т. Д. Или что-то неправильно понять?

Ответы на вопрос(9)

Решение Вопроса

Поскольку запросы AJAX (а) отправляются с учетными данными пользователя, и (б) позволяют вызывающей стороне читать возвращенные данные.

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

Вы можете просто добавить элемент img, script или iframe в документ

Ни один из этих методов не позволяет вызывающей стороне читать возвращенные данные.

(За исключением сценариев, где он специально настроен на это, для разрешенных междоменных сценариев - или где кто-то совершил ужасную хитрость.)

Вы можете проводить XSS-атаки, не используя это вообще. Публикация на стороннем сайте

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

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

 Shawn22 янв. 2009 г., 02:58
это отличный ответ, но в последнем абзаце я все еще не думаю, что это атака xss. XSS-атака - это то, где вы внедряете JavaScript на сайт законных сайтов.
 bobince22 янв. 2009 г., 16:28
Извините, HTML-инъекция. Боже, я, катушки, иногда печатаю мысли. SQL-инъекция - намного худший уровень атаки ...
 Shawn22 янв. 2009 г., 14:54
SQL-инъекция - не самый распространенный способ получения xss, это незашифрованный пользовательский текст, отправленный с сервера.
 bobince22 янв. 2009 г., 12:47
SQL-инъекция, безусловно, является наиболее распространенным способом получения XSS, но не единственным. Эффект от возможности междоменной работы AJAX будет таким же, как в результате внедрения SQL-кода.
 Kirill Kobelev13 окт. 2012 г., 01:19
Я написал свой собственный ответ. Можете ли вы взглянуть?

Важная разница между POST:

<body onload="document.getElementById('InvisbleForm').submit()" ...

и Ajax заключается в том, что после выполнения любого POST браузер заменит страницу, а после выполнения вызова Ajax - нет. Результат POST будет:

Четко видно пользователю.На этом этапе атака застрянет, потому что страница ответа отmy-bank.com возьму на себя управление. Ни один банк не осуществитодин щелчок-передачи.

Сценарий XSRF, если междоменный Ajax будет разрешен, будет выглядеть следующим образом:

Пользователь как-то посещаетwww.bad-guy.com.Если нет открытой страницы дляmy-bank.com в другом случае браузера атака не удалась.Но если такая страница открыта и пользователь уже ввел свое имя пользователя / пароль, это означает, что в кеше браузера есть файл cookie для этого сеанса.Код JavaScript на странице отwww.bad-guy.com делает вызов Ajaxmy-bank.com.Для браузера это обычный HTTP-вызов, он должен отправить куки my-bank наmy-bank.com и он их отправляет.Банк обрабатывает этот запрос, потому что он не может отличить этот звонок от обычной активности пользователя.Тот факт, что код JavaScript может прочитать ответ, не важен. В случае атаки это может быть необязательно. Что действительно важно, так это то, что пользователь перед компьютером не будет знать, что это взаимодействие происходит. Он будет смотреть на красивые картинки наwww.bad-guy.com стр.Код JavaScript делает несколько других вызововmy-bank.com если это необходимо.

Суть в том, что никаких инъекций или подделки страниц не требуется.

Лучшим решением может быть позволить сам вызов, но не отправлять куки. Это очень простое решение, которое не требует каких-либо масштабных разработок. Во многих случаях Ajax-вызов идет в незащищенное местоположение, и не отправка файлов cookie не будет ограничением.

CORS (Cross Source Resource Sharing), который сейчас обсуждается, помимо прочего, говорит об отправке / не отправке куки.

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

Две самые большие проблемы возникают, когда он используется в сочетании с межсайтовым скриптингом (XSS) и подделкой межсайтовых запросов (CSRF). Оба являются серьезными угрозами (именно поэтому они попали в первую десятку OWASP и в SANS 25).

Единственный способ, которым я мог видеть, что это злоупотребляло, было бы, если бы кто-то вводил JavaScript

Это XSS. Слишком много приложений по-прежнему уязвимы, и, если модели безопасности браузера не препятствуют X-домену AJAX, они открывают своих пользователей значительному вектору атаки.

Вы можете просто добавить элемент img, script или iframe в документ, чтобы он запрашивал сторонний URL

Да, но те отправят HTTP_REFERRER и (другими способами) могут быть заблокированы для предотвращения CSRF. Вызовы AJAX могут легче подделывать заголовки и позволяют использовать другие способы обхода традиционных средств защиты CSRF.

 Shawn21 янв. 2009 г., 21:45
как вы можете подделать заголовок?

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

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

Например, можно попросить пользователя посетить сайт со следующим кодом JavaScript (при условии, что jQuery):

<script type="text/javascript">
  $.post("http://some-bank.com/transfer-money.php", 
         { amount: "10000", to_account: "xxxx" })
</script>

Теперь, если пользователь действительно вошел в банк во время выполнения вышеуказанного кода, злоумышленник мог перевести 10 000 долларов США на счет XXX.

Этот вид атак называется «Подделка межсайтовых запросов» (XSRF). Есть больше информации об этом наВикипедия.

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

В настоящее время обсуждается вопрос о разрешении междоменного XHR, но мы должны посмотреть, действительно ли это будет принято.

 Kibbee21 янв. 2009 г., 21:22
Таким образом, вы можете сделать то же самое, заставив их загрузить следующий URLsome-bank.com/...
 Shawn21 янв. 2009 г., 21:32
это можно сделать с помощью обычного JavaScript. не имеет ничего общего с опс
 BacMan21 янв. 2009 г., 21:31
Рефералы могут быть подделаны. Вы никогда не должны использовать реферер для аутентификации. Посмотрите CSRF, и вы узнаете, как вы можете предотвратить этот тип веб-уязвимости.
 Kibbee21 янв. 2009 г., 21:22
Это только проблема, если банк специально ищет в сообщении только значения. Во многих случаях тот, кто внедрил сайт, просто смотрит в «Запрос», который содержит как POST, так и GET.
 Kibbee21 янв. 2009 г., 21:25
Кроме того, вы можете создать скрытую форму в фрейме и указать действиеsome-bank.com/transfer-money.php, который автоматически заполняет и суммирует через Javascript. Если бы банк не проверял реферала, он бы подумал, что пользователь делает правильный запрос.

отказывающихся в обслуживании.

Кроме того, представьте себе межсайтовый скрипт, который крадет все ваши вещи на Facebook. Он открывает IFrame и переходит на Facebook.com

Вы уже вошли в Facebook (cookie), и он читает ваши данные / друзей. И делает больше гадостей.

 Kibbee21 янв. 2009 г., 21:12
но подобные атаки уже существуют и совсем не зависят от XMLHTTPRequest.

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

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

То, что я лично хотел бы видеть в будущем, - это надежная защита всех входящих запросов по умолчанию на веб-серверах, платформах и CMS, а затем явное определение ресурсов, которые будут анализировать запросы из внешних источников.

видимо, ты не единственный человек, который чувствует себя таким образом ...

http://www.google.com/search?q=xmlhttp+cross+site

РЕДАКТИРОВАТЬ: есть интересная дискуссия, связанная с вышеупомянутым поиском:

http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx

Похоже, что в настоящее время разрабатываются предложения по разрешению межсайтовых запросов xmlhttp (IE 8, FF3 и т. Д.), Хотя я хотел бы, чтобы они были там, когда я писал код для своих сайтов :) И тогда возникает проблема совместимости ... Пройдет какое-то время, прежде чем он станет повсеместным.

 Kibbee21 янв. 2009 г., 21:18
Было бы неплохо, если бы они предложили его в качестве обновления для существующих браузеров, если бы они когда-либо решили, что мы сможем выполнять междоменные вызовы AJAX.
 Andrew Rollings21 янв. 2009 г., 21:32
Согласен :) Я ненавижу дублировать функциональность сайтов через локальные оболочки.

<form> Вы можете публиковать данные, но не можете их прочитать. XHR Вы можете сделать оба.

Страница какhttp://bank.example.com/display_my_password безопасен против XSRF (при условии, что он только отображает, но не устанавливает пароль) и фреймов (они имеют одинаковую политику происхождения). Однако междоменный XHR будет уязвимостью.

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

Ваш ответ на вопрос