Проблема безопасности с динамическими тегами скрипта

Question

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

Одна проблема, которую им пришлось преодолеть, заключалась в том, как анализировать и обрабатывать так много данных (то есть всех ваших контактов) на стороне клиента. Они пытались получить XML и JSON через AJAX, но обнаружили, что это слишком медленно. Затем они сказали это о загрузке данных через динамически генерируемый тег сценария (с функцией обратного вызова):

JSON и динамические теги сценариев: быстро, но небезопасно

Работа с теорией, которая велика манипулирование строками было проблемой с последним подходом мы перешли от использования Ajax вместо извлечения данные с использованием динамически генерируемых тег сценария. Это означает, что контактные данные никогда не рассматривались как строка, и вместо этого был выполнен как как только он был загружен, так же, как любой другой файл JavaScript. разница в производительности была шокирует: 89мс для разбора 10000 контакты (сокращение на 3 порядка величина), в то время как наименьший случай 172 контакта заняли всего 6 мс. Разбор время на контакт фактически уменьшилось чем больше список стал. это подход выглядел идеально, за исключением одно: для того, чтобы этот JSON исполнить, мы должны были обернуть его в метод обратного вызова. Поскольку он исполняемый код, любой веб-сайт в мире может использовать тот же подход, чтобы загрузить Список контактов участника Flickr. Это было нарушитель сделки. (выделение мое)

Может, кто-нибудь расскажет о точной угрозе безопасности здесь (возможно, с примером эксплойта)? Чем загрузка данного файла с помощью атрибута "src" в теге скрипта отличается от загрузки этого файла с помощью вызова AJAX?

Answer 1

Это хороший вопрос, и именно этот вид эксплойта когда-то использовался для кражи списков контактов из gmail.

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

Например, когда вы загружаете новую страницу stackoverflow.com, ваш браузер отправляет ваши данные cookie на stackoverflow.com. Stackoverflow использует эти данные, чтобы определить, кто вы, и показывает соответствующие данные для вас.

То же самое относится ко всему, что вы загружаете из домена, включая файлы CSS и Javascript.

Уязвимость безопасности, с которой столкнулся Flickr, заключалась в том, что любой веб-сайт мог встроить этот файл javascript, размещенный на серверах Flickr. Ваши данные cookie Flickr будут затем отправлены как часть запроса (поскольку javascript был размещен на flickr.com), и Flickr создаст документ javascript, содержащий конфиденциальные данные. Вредоносный сайт сможет получить доступ к загруженным данным.

Вот эксплойт, который использовался для кражи контактов Google, что может сделать его более понятным, чем мое объяснение выше: http://blogs.zdnet.com/Google/?p=434

Answer 2

Если бы я разместил HTML-страницу на моем сайте, например:

<script src="http://www.flickr.com/contacts.js"></script>
<script> // send the contact data to my server with AJAX </script>

Предполагая, что contacts.js использует сеанс, чтобы узнать, какие контакты отправлять, у меня теперь будет копия ваших контактов.

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

Answer 3

На простом английском:

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

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