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

Question

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

Хорошей идеей является использование «объектно-реляционного картографа», подобного Idiorm :

$user = ORM::for_table('user')
->where_equal('username', 'j4mie')
->find_one();

$user->first_name = 'Jamie';
$user->save();

$tweets = ORM::for_table('tweet')
    ->select('tweet.*')
    ->join('user', array(
        'user.id', '=', 'tweet.user_id'
    ))
    ->where_equal('user.username', 'j4mie')
    ->find_many();

foreach ($tweets as $tweet) {
    echo $tweet->text;
}

Он не только избавляет вас от SQL-инъекций, но и от синтаксических ошибок! Также поддерживает коллекции моделей с цепочкой методов для фильтрации или применения действий к нескольким результатам сразу и нескольких подключений.

41

ajax security xss

задан Kirill Kobelev 12 October 2012 в 22:53

8 ответов

Ну, по-видимому, Вы не единственный человек, который чувствует тот путь...

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

2

ответ дан Andrew Rollings 27 November 2019 в 00:51

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

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

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

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

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

, Этот вид нападений называют Перекрестной Подделкой Запроса Сайта (XSRF). Существует больше информации об этом на Википедия .

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

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

2

ответ дан Baishampayan Ghose 27 November 2019 в 00:51

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

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

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

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

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

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

1

ответ дан Mike Griffith 27 November 2019 в 00:51

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

1

ответ дан Shawn 27 November 2019 в 00:51

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

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

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

1

ответ дан Filip Dupanović 27 November 2019 в 00:51

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

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

1

ответ дан Kornel 27 November 2019 в 00:51

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

кроме того, Вообразите перекрестный сценарий сайта, который крадет весь Ваш материал Facebook. Это открывает IFrame и перешло на Facebook.com

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

0

ответ дан user57660 27 November 2019 в 00:51

Другие вопросы по тегам:

ajax security xss

Похожие вопросы:

score 36 · Accepted Answer

, Почему Запросам HTTP Ajax не позволяют пересечь доменные границы.

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

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

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

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

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

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

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

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