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

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


person Kibbee    schedule 21.01.2009    source источник
comment
изменение этих атак, потому что они на самом деле являются атаками xsrf. xss, когда вы вводите скрипт на легитимные страницы сайта   -  person Shawn    schedule 21.01.2009
comment
@Kibbee, ты здесь? Я хочу отредактировать ваше сообщение, чтобы оно было более понятным. В некоторых случаях я не совсем понимаю ваш английский. Вы сделаете обзор?   -  person Kirill Kobelev    schedule 12.10.2012
comment
@KirillKobelev Мне нравятся правки. Приятно видеть, что этот старый вопрос все еще жив и здоров.   -  person Kibbee    schedule 12.10.2012
comment
Решил написать свой ответ. Вы можете взглянуть, пожалуйста?   -  person Kirill Kobelev    schedule 13.10.2012
comment
Поскольку XMLHTTPRequest позволяет отправлять сообщения с учетными данными (куки) на целевой сайт и читать данные, отправленные обратно с сайта. Затем злоумышленник просто использует, например, заголовок ('Access-Control-Allow-Origin: *') и может читать данные, отправленные обратно с сайта, создавать формы отправки и т. Д. Или что-то неправильно понять?   -  person Sever    schedule 02.10.2015


Ответы (9)


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

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

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

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

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

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

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

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

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

person bobince    schedule 21.01.2009
comment
это отличный ответ, но в последнем абзаце я все еще не думаю, что это xss-атака. xss-атака - это когда вы вставляете javascript на веб-сайт легитимных сайтов. - person Shawn; 22.01.2009
comment
SQL-инъекция, безусловно, самый распространенный метод получения XSS, но не единственный. Эффект от возможности перекрестного домена AJAX будет таким же, как и от SQL-инъекции. - person bobince; 22.01.2009
comment
sql-инъекция - не самый распространенный метод получения xss, это незашифрованный пользовательский текст, отправленный с сервера. - person Shawn; 22.01.2009
comment
Извините, да, HTML-инъекция. Боже, я иногда пытаюсь печатать мысли. SQL-инъекция - гораздо худший уровень атаки ... - person bobince; 22.01.2009
comment
Я написал свой ответ. Вы можете взглянуть, пожалуйста? - person Kirill Kobelev; 13.10.2012

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

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

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

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

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

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

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

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

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

person Kirill Kobelev    schedule 12.10.2012

Что ж, видимо, ты не единственный, кто так думает ...

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 и т. Д.), Хотя я бы хотел, чтобы они были там, когда я писал код для своих сайтов :) И еще есть проблема совместимости ... Пройдет время, прежде чем это станет повсеместным.

person Andrew Rollings    schedule 21.01.2009
comment
Было бы неплохо, если бы они предложили это как обновление существующих браузеров, если бы они когда-либо решили, что мы должны иметь возможность выполнять междоменные вызовы AJAX. - person Kibbee; 21.01.2009
comment
Согласен :) Ненавижу дублировать функциональность на разных сайтах через локальные оболочки. - person Andrew Rollings; 21.01.2009

Когда вы отправляете HTTP-запрос на сервер, файлы 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). Дополнительную информацию об этом можно найти в Википедии.

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

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

person Baishampayan Ghose    schedule 21.01.2009
comment
Это проблема только в том случае, если банк специально просматривает сообщения только в поисках значений. Во многих случаях, кто бы ни реализовал сайт, просто просматривает запрос, который содержит как POST, так и GET. - person Kibbee; 21.01.2009
comment
Таким образом, вы можете сделать то же самое, заставив их загрузить следующий URL-адрес some -bank.com/ - person Kibbee; 21.01.2009
comment
Кроме того, вы можете создать скрытую форму в iframe и сделать так, чтобы действие указывало на some-bank .com / transfer-money.php, который автоматически заполняет его и заполняет через Javascript. Если банк не проверил реферера, он подумал бы, что пользователь делает правильный запрос. - person Kibbee; 21.01.2009
comment
Рефереры могут быть подделаны. Никогда не используйте реферер для аутентификации. Посмотрите CSRF, и вы узнаете, как предотвратить этот тип веб-уязвимостей. - person BacMan; 21.01.2009
comment
это можно сделать с помощью обычного javascript. не имеет ничего общего с вопросом opps - person Shawn; 21.01.2009

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

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

единственный способ увидеть, как злоупотребляют, - это если кто-то внедрит Javascript

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

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

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

person Mike Griffith    schedule 21.01.2009

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

person Shawn    schedule 21.01.2009

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

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

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

person Filip Dupanović    schedule 21.01.2009

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

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

person Kornel    schedule 21.01.2009

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

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

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

person user57660    schedule 21.01.2009
comment
но подобные атаки уже существуют и совершенно не зависят от XMLHTTPRequest. - person Kibbee; 21.01.2009