Что такое межсайтовое включение сценариев (XSSI)? - PullRequest
31 голосов
/ 06 ноября 2011

Я недавно видел XSSI, упомянутый на нескольких страницах, например Эксплуатация и защита веб-приложений :

Браузеры не позволяют страницам одного домена читать страницы в других доменах. Но они не мешают страницам домена ссылаться на ресурсы в других доменах. В частности, они позволяют отображать изображения из других доменов и выполнять сценарии из других доменов. Включенный скрипт не имеет собственного контекста безопасности. Он работает в контексте безопасности страницы, которая его включала. Например, если www.evil.example.com содержит скрипт, размещенный на сайте www.google.com, тогда этот скрипт выполняется в злом контексте, а не в контексте Google. Таким образом, любые пользовательские данные в этом скрипте будут «утекать».

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

Кто-нибудь может зарисовать эксплойт, основанный на XSSI?

Спасибо

Ответы [ 3 ]

44 голосов
/ 07 ноября 2011

Обычно это проблема, если вы используете JSONP для передачи данных. Рассмотрим веб-сайт, состоящий из домена A, который загружает данные из домена B. Пользователь должен пройти проверку подлинности на сайтах A и B, а также потому, что единая политика происхождения не позволяет старым браузерам напрямую взаимодействовать с доменом (B), отличным от текущей страницы. (A), разработчики решили использовать JSONP. Таким образом, сайт A включает скрипт, указывающий на http://B/userdata.js, который выглядит примерно так:

displayMySecretData({"secret":"this is very secret", ...})

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

Теперь злой сервер E приходит. Он видит, что A включает данные из B с использованием JSONP. Таким образом, сервер E включает в себя тот же скрипт, но определяет свой собственный displayMySecretData, который вместо этого крадет данные. Затем злоумышленник обманывает пользователя, чтобы он посетил его сайт. Когда пользователь переходит туда и входит в систему B, браузер автоматически отправляет куки-файлы аутентификации для B вместе с запросом, чтобы найти скрипт из B. B видит аутентифицированного пользователя и, таким образом, возвращает скрипт, как и ожидалось. E получает данные, и Presto ...

Использование JSONP для загрузки конфиденциальных данных из другого домена таким образом действительно небезопасно, но люди все еще используют его. Плохая идея.

19 голосов
/ 02 августа 2013

XSSI не ограничивается ответами jsonp.В некоторых браузерах вы можете переопределить конструктор Array.Если ответ Json содержит [...] и вы включили его в качестве сценария, он выполнит новый конструктор вместо встроенного.Исправление заключается в том, чтобы вставить в ответ что-то, что не может быть проанализировано, например ])}while(1);</x>, а затем использовать код для его удаления перед синтаксическим анализом.Злоумышленник не может этого сделать, поскольку включение сценария всегда является полным сценарием.

Подробнее о проблеме и ее решении см. http://google -gruyere.appspot.com / part3 # 3__cross_site_script_inclusion

7 голосов
/ 01 декабря 2011

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

Например, допустим, я включил в свой HTMLpage

<script type="text/javascript" src="http://mymatedave.com/js/coolwidget.js"></script>

Этот скрипт будет работать в моем веб-приложении с тем же уровнем доверия, что и любой мой собственный код JavaScript.Он будет иметь доступ к полному содержанию страницы и DOM, сможет читать все файлы cookie моего приложения, читать нажатия клавиш и движения мыши, а также все остальное, что может делать javascript.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...