Подтвердить что ты не робот

Почему кросс-домен Ajax является проблемой безопасности?

Почему было решено, что использование XMLHTTPRequest для выполнения вызовов XML не должно выполнять вызовы через границу домена? Вы можете получить JavaScript, изображения, CSS, iframe и любой другой контент, который я могу представить из других доменов. Почему 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 позволяет публиковать сообщения с учетными данными (куки) на целевом сайте и читать данные, отправленные с сайта, а также отправлять учетные данные для лиц, вы можете организовать какой-либо javascript, который будет представлять ряд форм, включая формы подтверждения, в комплекте с любыми генерируемыми случайными ключами, которые были созданы для предотвращения XSRF. Таким образом, вы можете просмотреть целевой сайт, например, банк, и веб-сервер банка не сможет сказать, что он не просто обычный пользователь, отправляющий все эти формы.

4b9b3361

Ответ 1

Почему Ajax HTTP-запросы не разрешают пересекать границы домена.

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

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

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

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

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

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

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

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

Ответ 2

Важное различие между POST:

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

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

  • Ясно видно пользователю.
  • Атака застрянет в этой точке, потому что страница ответа из my-bank.com примет управление. Ни один банк не выполнит передачу одним нажатием.

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

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

Суть заключается в том, что никакая инъекция или вмешательство в страницы не нужны.

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

CORS (совместное использование ресурсов Cross Origin), который сейчас обсуждается, среди прочего, говорит о отправке/отсутствии отправки файлов cookie.

Ответ 3

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

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

EDIT: есть интересная дискуссия, связанная с приведенным выше поиском:

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

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

Ответ 4

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

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

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

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

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

Этот тип атак называется Cross Site Request Forgery (XSRF). Об этом больше на Wikipedia.

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

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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