Каковы риски межсетевого обмена JSONP?

Question

В нашем веб-приложении мы столкнулись с ситуацией, когда нам нужно выполнять междоменные вызовы AJAX из одного домена, который мы полностью контролируем в другом домене, который мы полностью контролируем. Я занимаюсь серфингом для лучшего решения, а два, которые приходят на ум, - это локальный прокси-файл (локальный файл с использованием php :: fopen) или jquery/JSONP.

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

Каковы конкретные векторы атаки, которые будут открываться перекрестным доменом JSONP?

Из моего понимания единственного вектора JSONP точно такой же вектор, который открыл счет включения <script> тега на сайте которого ЦСИ является любого сайта, который не контролируется вами: То, что они могли бы превратить злонамеренные и начать фермерские сессии пользователей/файлы cookie/данные. Если это так, то, похоже, это не протокол (JSONP), а источник , из которого собираются данные.

Поскольку это был прокси-сервер на стороне сервера, тег <script> или ajax/JSONP, риск состоит в том, что я помещаю чужой контент на свою страницу, и они могут начать фермерские сессии пользователей, если они чувствуют себя обязанными (в это именно то, что Google Analytics делает с помощью тега сценария).

Многие векторы, которые я слышу в Интернете, зависят от неправильной проверки представленных пользователем форм и данных. В примере JSONP используется для вытягивания некоторого файла, который помещает данные в форму, а затем форму отправляется для вставки базы данных. Если данные из этой формы доверяют, потому что это источник из надежного источника (данные JSONP) и вводятся без проверки, то опять же это не ошибка JSONP, а неправильная проверка ввода пользователя. Пользователь может вносить одни и те же изменения в эту форму с помощью Firebug, но последний раз, когда я проверял, никто не вызывает Firebug для вектора безопасности.

Последний элемент - это понятие о том, что с прокси-сервером на стороне сервера существует большая способность фильтровать результаты до передачи его клиенту. Тем не менее, будь то PHP или Javascript, я мог бы фильтровать результаты, чтобы удалить такие вещи, как onclick или iframe. Конечно, кто-то клиентская сторона может изменить мою функцию javascript, чтобы удалить фильтрацию, но фильтрация повлияет только на их конкретный клиентский опыт и не будет изменена для других пользователей, что предотвратит постоянную многопользовательскую атаку XSS.

Очевидно, что есть некоторые преимущества для прокси-сервера на стороне сервера, поскольку это упростит такие действия, как ведение журнала возможных атак XSS, но с точки зрения предотвращения самой атаки как PHP, так и Javascript, похоже, имеют достаточные утилиты. В некотором смысле, казалось бы, JSONP на самом деле более безопасен, чем простой тег <script>, потому что, по крайней мере, с помощью JSONP результат проходит через функцию, которая означает, что она несколько отфильтрована, а не просто доверие к одежде, как это происходит с <script>.

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

РЕШЕНИЕ

1. Если оба конца доверяют, нет никакой опасности в JSONP (это в основном только <script> тег).

2. Оба сценария/JSONP имеют одинаковые уязвимости безопасности, поскольку они автоматически выполняются, а не просто передаются как данные. Использование прокси-сервера на стороне сервера означает, что междоменное возвращение передается как данные и может быть отфильтровано для вредоносного содержимого. Если кросс-домен полностью доверен, JSONP/SCRIPT безопасен, если есть подозрение на риск, а затем передать его через прокси-сервер фильтра.

Answer 1

Когда вы контролируете оба конца запроса, большинство традиционных безопасности заботы о JSONP не является проблемой.

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

Answer 2

Существует БОЛЬШАЯ разница между server-side-proxy и <script>/JSONP. В первом случае, вы загружаете данные, в последней загрузки и автоматически выполнятькод

При создании на стороне сервера прокси, то Javascript код может использовать XmlHttpRequest для загрузки данных. Эти данные не будут выполняться автоматически; вы должны явно сделать что-то глупое, например eval(), чтобы заставить его выполнить. Даже если формат данных JSON и другой сервер были скомпрометированы, а ваш собственный серверный прокси не поймает компромисс, у вас все еще есть линия защиты, доступная вашему клиентскому коду. Вы можете, например, разобрать JSON с помощью safeJSON parser и отклонить вредоносный скрипт.

Но когда вы используете JSONP или тег <script>, вы непосредственно включаете чужой код . Поскольку его код (а не данные), браузер автоматически выполняет его, не давая вам возможности проверить или изменить его.

Итак, на стороне сервера прокси дает две дополнительные линии обороны -

1. Возможность проверять данные на сервере для вредоносного содержимого
2. Возможность проверять данные в JavaScript до начала если это вообще необходимо выполнить.