Comments 73
Вроде jQuery давненько умеет такое, достаточно добавить в конец запроса "?" и все сработает.
Только не понимаю такой реакции на это.
Только не понимаю такой реакции на это.
ну может и неглубоко :)… существуею плагин для jQuery plugins.jquery.com/files/jQuery.windowName.plugin.js.txt, тоже недавно сделали…
В статье речь идет о кроссдоменных POST запросах. Кроссдоменный GET может в jQuery и есть (и скорее всего реализуется через элемент script).
Скорее всего вы думаете про JSONP.
вы глубоко заблуждаетесь
у iframe
а так — молодцы, что еще сказать :)
style="display:none" дважды идет…а так — молодцы, что еще сказать :)
в избранное! Спасибо, будет полезно :)
СРАКС — клево звучит!
> Суть реализации XSS POST основана на особенностях хранения данных в свойстве window.name.
и что? непонятно как указанная вами статья коррелируется с текущей. вы бы хоть чтото словами добавили, а то непонятно зачем тут эта ссылка
Собственно, да — об этом писали ещё в мае.
а у меня почемуто не получилось считать window.name из одного окна, установив его в другом
А не лучше ли кросс-доменные AJAX запросы делать через «прокси»-скрипт на сервере? Это к тому же позволяет контролировать в одном месте все проходящие запросы (например, в целях предотвращения уязвимостей).
не стоит сильно полагаться на то, что .name сохраняется при переходе между доменами — вряд ли это поведение описано в каком-нибудь стандарте, и уже сейчас вряд ли оно будет работать в хроме (его разработчики вроде обещали полностью очищать все данные при смене домена)
а насколько я понял по описанию принцип работы плагина dojo, там используется старый *проверенный* способ кроссдоменной передачи данных. Кстати, имхо именно по причине древности «это событие прошло незамеченным»
а насколько я понял по описанию принцип работы плагина dojo, там используется старый *проверенный* способ кроссдоменной передачи данных. Кстати, имхо именно по причине древности «это событие прошло незамеченным»
1) >принцип работы плагина dojo, там используется старый *проверенный* способ кроссдоменной передачи данных
принцип работы dojo такой же как и у нас. мы используя тот же подход сделали другим образом (другая реализация).
2) >не стоит сильно полагаться на то, что .name сохраняется при переходе между доменами
сохраняется 100%
3) >вряд ли оно будет работать в хроме
почему не проверили? работает 100%
4) > Кстати, имхо именно по причине древности «это событие прошло незамеченным»
кстати как раз этого и достаточно чтобы «дожить» до нормальной реализации XDomain, которая заложена в новых стандартах W3ORG
принцип работы dojo такой же как и у нас. мы используя тот же подход сделали другим образом (другая реализация).
2) >не стоит сильно полагаться на то, что .name сохраняется при переходе между доменами
сохраняется 100%
3) >вряд ли оно будет работать в хроме
почему не проверили? работает 100%
4) > Кстати, имхо именно по причине древности «это событие прошло незамеченным»
кстати как раз этого и достаточно чтобы «дожить» до нормальной реализации XDomain, которая заложена в новых стандартах W3ORG
Нарушения безопасности нет. Потомучто довереный домен должен возвращать данные в определенном формате, поэтому это закрывать не будут, а если и будут то уже в спецификации HTML5 предусмотрены функции для кроссдоменного доступа и это работает уже в FF3. Остальные браузеры поднятнутся. Зачем это нужно? Покажут новые проекты.
гыгыгы, «определённый формат» % )
security through obscurity, да? Если да, то не позорьтесь: )
security through obscurity, да? Если да, то не позорьтесь: )
Вы бы термины не применяли в которых не разбираетесь ;)
Формат ответа window.name=’данные’ не для того чтобы запутать злоумышленника, а для того чтобы наоборот открыть данные для кроссдоменных запросов. Так что сами не позорьтесь.
Формат ответа window.name=’данные’ не для того чтобы запутать злоумышленника, а для того чтобы наоборот открыть данные для кроссдоменных запросов. Так что сами не позорьтесь.
окей, давайте разберёмся, кто чего не понимает
сначала вы говорите про безопасность. Потом вы говорите, что это не для безопасности, а наоборот. Меня это удивляет, мягко говоря
кроме того, вы говорите «Нарушения безопасности нет. Потомучто довереный домен должен возвращать данные в определенном формате». В мире компьютерной безопасности это означает, что безопасность обеспечивается исключительно тем, что злоумышленник не знает формата, в котором передаются данные. Именно такой подход называется security through obscurity, и именно его ругают все подряд.
сначала вы говорите про безопасность. Потом вы говорите, что это не для безопасности, а наоборот. Меня это удивляет, мягко говоря
кроме того, вы говорите «Нарушения безопасности нет. Потомучто довереный домен должен возвращать данные в определенном формате». В мире компьютерной безопасности это означает, что безопасность обеспечивается исключительно тем, что злоумышленник не знает формата, в котором передаются данные. Именно такой подход называется security through obscurity, и именно его ругают все подряд.
Нету задачи запутать злоумышленника. Стоит задача дать возможность кроссдоменных запросов для чистых JavaScript решений. Решается эта задача через хак — window.name транспорт. Есть еще одно решение через script транспорт. Оба хака не нарушают философию Same Origin Policy (изоляция сайта в пределах протокола, домена и порта) иначе бы их прикрыли. Потомучто для обоих хаков скрипты на которые производится кроссдоменный запрос изначально разрабатываются с поддержкой этих транспортов.
хм, если нет задачи запутать злоумышленника, почему вы вообще начали говорить про безопасность?
Потомучто кроссдоменные запросы запрещены из-за соображений безопасности, и чтобы делать такие запросы приходится пользоваться хаками, но они не нарушают принцип Same Origin Policy. Поэтому вероятность что закроют хаки низка.
потому что данный подход хоть и позволяет осуществлять кросс-доменные запросы в это же время не позволяет производить XSS скрабинг или как он называется по модному «Фишинг»
про принцип работы я ошибся, да. Удивлён, что они стали так заморачиваться.
фраза «100% сохраняется/работает» верна *на текущий момент* в тех браузерах, *которые вы тестировали*. Это может сломаться в ближайшем будущем, или не работать в редком браузере.
а поддержки нового клёвого стандарта ждать долго: (
фраза «100% сохраняется/работает» верна *на текущий момент* в тех браузерах, *которые вы тестировали*. Это может сломаться в ближайшем будущем, или не работать в редком браузере.
а поддержки нового клёвого стандарта ждать долго: (
пока вы ждете и фантазируете на тему «как все плохо» — мы делаем нужные вещи и делимся с другими. Тех браузеров в которых мы тестировали достаточно с головой, потому что они перекрывают 95-99% pageview.
> пока вы ждете и фантазируете на тему «как все плохо»
классический, но от этого не менее смелый ход в дискуссии — обвинить собеседника в только что придуманном грехе: )
> достаточно с головой, потому что они перекрывают 95-99% pageview
у меня большой опыт попадания в оставшиеся 1-5%, поэтому я и рекомендую использовать стандартные подходы
классический, но от этого не менее смелый ход в дискуссии — обвинить собеседника в только что придуманном грехе: )
> достаточно с головой, потому что они перекрывают 95-99% pageview
у меня большой опыт попадания в оставшиеся 1-5%, поэтому я и рекомендую использовать стандартные подходы
> у меня большой опыт попадания в оставшиеся 1-5%
это как понимать? что у вас не работает наша тестовая страница?
это как понимать? что у вас не работает наша тестовая страница?
сейчас ваша тестовая страница у меня работает. Но я не уверен, что так оно будет и дальше
а я не уверен что интрнет вообще будет дальше работать и что? я ж написал в начале
фантазируете на тему «как МОЖЕТ БЫТЬ все плохо» когда в настоящий момент хорошо :)
фантазируете на тему «как МОЖЕТ БЫТЬ все плохо» когда в настоящий момент хорошо :)
а я уверен, что дальше интернет будет работать. Потому что он основан на открытых стандартах, которые может поддерживать любой человек. А полуслучайные совпадения, которые не описаны ни в каком публичном документе, могут внезапно исчезнуть, как уже не раз бывало. Недавно, например, закончилась поддержка Flash Paper, и никто ничего с этим не может поделать
Начет закрытия хаков врятли они так поступят. Например, альтернатива window name хаку есть script. Известно что через тег script можно загружать скрипты с любого домена. Причем эта поддержка на уровне стандарта. Хак заключается в том что нужно вернуть валидный js код, а там уже будет содержаться ответ от сервера, например ответ от сервера такой, а клиентский код уже содержит функцию my_callback которая получит в аргументе ответ.
Чтобы прикрыть этот хак нужно запретить загрузку скриптов с другого домена. А это уже изменение на уровне стандарта. А если просто взять и запретить загрузку скриптов с другого домена может перестать работать множество сайтов (кто его знает сколько таких сайтов в сети, например у гугли есть целый сервис, который предоставляет скрипты популярных фреймворков, чтобы разработчики не хранили их у себя, а могли загрузить их с серверов гугли).
Чтобы прикрыть этот хак нужно запретить загрузку скриптов с другого домена. А это уже изменение на уровне стандарта. А если просто взять и запретить загрузку скриптов с другого домена может перестать работать множество сайтов (кто его знает сколько таких сайтов в сети, например у гугли есть целый сервис, который предоставляет скрипты популярных фреймворков, чтобы разработчики не хранили их у себя, а могли загрузить их с серверов гугли).
P.S. > например ответ от сервера такой <скрипт>my_callback('тут ответ в формате XML и т. п.')</скрипт>
оно понятно, что скрипты с другого домена будут работать как раньше. Вопрос только — при чем здесь window.name? Все эти аргументы к нему неприменимы.
Потомучто если будут закрывать window.name тогда надо и закрыть возможность получить кроссдоменные данные через script. Иначе одно закрыли, а другое нет, поэтому не будут трогать ни то ни другое.
нет уж, извините
вы сами сказали, что поведение script в спеке прописано (не хак), а поведение window.name — нет (хак). Именно поэтому первое не закроют, а второе могут закрыть.
вы сами сказали, что поведение script в спеке прописано (не хак), а поведение window.name — нет (хак). Именно поэтому первое не закроют, а второе могут закрыть.
а смысл? я не думаю что браузеры разрабатывают неумные люди, делают такие же програмеры как и мы, опасности в window.name нету значит и смысла закрывать нету, иначе уже б давно закрыли.
Вам наверно сюда: tema.livejournal.com
Что-то мне подсказывает что туда идти не следует))) Да и нет привычки кликать по всем ссылкам)
Может вам аналогичную ссылку на lleo подкинуть?
Может вам аналогичную ссылку на lleo подкинуть?
Ну раз просите)) Сходите lleo.aha.ru/na/
Очень сильно извиняюсь, но я реализовывал динамический script по долгу службы еще прошлой осенью… в сентябре. Да и раньше это было и работало… и механизм с iFrame тогда существовал и работал…
м? чего в этом нового? обертка в класс? хаафо, только были уже jQuery плагины для этого.
м? чего в этом нового? обертка в класс? хаафо, только были уже jQuery плагины для этого.
Автору огромный респект, за обзор решения подобной проблемы, второй день парюсь с подобной проблемой
автору спасибо, помогла схема.
Заметил одну такую особенность…
если в срипте убрать вот эту строчку
finish[id] = callback;
то сервер на который отправляется запрос начинает изрядно подвисать.
з.ы. возможно погрешности измерения
Заметил одну такую особенность…
если в срипте убрать вот эту строчку
finish[id] = callback;
то сервер на который отправляется запрос начинает изрядно подвисать.
з.ы. возможно погрешности измерения
Sign up to leave a comment.
JavaScript Cross Site (XSS) POST