Безопасная реализация сценария тега взломать, чтобы сделать XSS?

Question

Как и многие разработчики, я хочу, чтобы JavaScript, обслуживаемый сервером "A", общался с веб-службой на сервере "B", но я застрял в текущем воплощении в той же политике происхождения . Наиболее безопасный способ преодоления этого (что я могу найти) - это серверный скрипт, который находится на сервере «А» и действует как прокси между ним и «Б». Но если я хочу развернуть этот JavaScript в различных клиентских средах (RoR, PHP, Python, .NET и т. Д.) И не могу написать прокси-сценарии для всех из них, что мне делать?

Используйте JSONP, некоторые люди говорят . Что ж, Даг Крокфорд указал на своем веб-сайте и в интервью , что взлом скриптового тега (используемый JSONP) - это небезопасный способ обойти ту же политику происхождения. У сценария, обслуживаемого «A», нет способа проверить, что «B» - это тот, кем они себя называют, и что данные, которые он возвращает, не являются вредоносными или будут собирать конфиденциальные данные пользователя на этой странице (например, номера кредитных карт) и передайте это подлым людям. Это кажется разумной проблемой, но что, если я просто сам использую скрипт-хак и буду строго общаться в JSON? Это безопасно? Если нет, то почему? Будет ли безопаснее с HTTPS? Примеры сценариев приветствуются.

Приложение: Требуется поддержка IE6. Сторонние расширения браузера не вариант. Давайте остановимся на рассмотрении достоинств и рисков взлома скрипта, пожалуйста.

Answer 1

В настоящее время поставщики браузеров разделены на том, как должен работать междоменный JavaScript. Безопасным и простым в использовании оптоином является файл Crossdomain.xml от Flash . Для большинства языков написано междоменных прокси , и они имеют открытый исходный код.

Более гнусным решением было бы использовать xss, как Sammy Worm использовал для распространения. XSS можно использовать для «чтения» удаленного домена с помощью xmlhttprequest. XSS не требуется, если другие домены добавили <script src="https://YOUR_DOMAIN"></script>. Подобный тег сценария позволяет вам оценить свой собственный JavaScript в контексте другого домена, который идентичен XSS.

Также важно отметить, что даже при наличии ограничений на одну и ту же политику происхождения вы можете заставить браузер передавать запросы в любой домен, вы просто не можете прочитать ответ. Это основа CSRF. Вы можете динамически записывать невидимые теги изображений на страницу, чтобы браузер запускал неограниченное количество запросов GET. Такое использование тегов изображений позволяет злоумышленнику получить documnet.cookie с использованием XSS в другом домене. CSRF POST использует работу, создавая форму и вызывая .submit() для объекта формы.

Чтобы лучше понять Единую политику организации, CSRF и XSS, вы должны прочитать Справочник по безопасности браузера Google .

Answer 2

Взгляните на easyXDM , это чистая библиотека javascript, которая позволяет общаться через границу домена без какого-либо взаимодействия на стороне сервера.Он даже поддерживает RPC «из коробки».
Он поддерживает все «современные» браузеры, а также IE6 с временем передачи <15 мс. </p>

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

Answer 3

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

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

Независимо от того, как используется взлом тега сценария, однако, нет способа отфильтровать ответ для вредоносного кода, так как браузеры выполняют любой возвращаемый JavaScript. И ни IE, ни Firefox, ни браузеры Webkit не проверяют SSL-сертификаты в этом сценарии. Насколько я могу судить, Даг Крокфорд прав. Начиная с JavaScript 1.8.5 не существует безопасного способа создания междоменных сценариев.

Answer 4

Что, если я просто сам использую скрипт-хак и буду строго общаться в JSON? Это безопасно? Если нет, то почему?

Допустим, у вас есть два сервера - frontend.com и backend.com. На frontend.com есть тег <script>, подобный этому - <script src="http://backend.com/code.js"></script>.

когда браузер оценивает code.js, считается частью frontend.com, а НЕ частью backend.com. Таким образом, если код code.js содержит код XHR для связи с backend.com, не получится .

Будет ли безопаснее с HTTPS? Примеры сценариев приветствуются.

Если вы только что преобразовали <script src="https://backend.com/code.js> в https, НЕ будет безопасным. Если остальная часть вашей страницы - http, то злоумышленник может легко обработать страницу посредником и изменить https на http - или, что еще хуже, включить свой собственный файл javascript.

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

Короче говоря, https полезен, но он не поможет вам ни на секунду, если ваш сервер будет взломан.

Итак, какие у меня варианты?

1. Добавьте прокси-сервер в каждое из ваших клиентских приложений. Вам не нужно писать код, ваш веб-сервер может автоматически сделать это за вас. Если вы используете Apache, найдите mod_rewrite
2. Если ваши пользователи используют самые последние браузеры, вы можете рассмотреть возможность использования Cross Origin Resource Sharing .
3. Как указал The Rook, вы также можете использовать Flash + Crossdomain. Или вы можете использовать Silverlight и его эквивалент Crossdomain. Обе технологии позволяют вам общаться с javascript - поэтому вам просто нужно написать служебную функцию, и тогда будет работать обычный js-код. Я полагаю, что YUI уже предоставляет для этого флэш-упаковку - отметьте YUI3 IO

Что вы рекомендуете?

Я рекомендую создать прокси-сервер и использовать https на вашем веб-сайте.