Я понимаю основные идеи XSS и политики одного и того же происхождения, поэтому, если ваша реакция коленного толчка состоит в том, чтобы научить меня основам, вы можете прыгнуть вперед хотя бы на полшага ...
Если javascript на стороне клиента, в какой момент HTTP-запрос, отправленный через XMLHttpRequest, отличается от пользователя, отправляющего запрос с помощью кнопки отправки формы?
Вот моя реальная ситуация:
Я работаю над сценарием, который будет (если это возможно) собирать защищенные данные из безопасного субдомена, в котором находятся такие частные данные. Ради этого вопроса я позвоню на мой сайт staff.work.org
, а на другой сайт personal.work.org
.
Back Story, пропустите, если хотите
Таким образом, преимущества такого сценария состоят в том, что он оптимизирует избыточный процесс и добавит преимущества как персоналу, так и руководству. Прямо сейчас любой сотрудник должен отправить менеджеру по планированию свою готовность на этот срок. Поскольку большинство сотрудников являются студентами, им просто нужно отправить расписание занятий по электронной почте. Каждый из них отправляет свое расписание по электронной почте, а менеджер делает с ним все, что угодно, возможно, просто создает большой текстовый файл или файл Excel.
Но я хочу, чтобы они просто перешли на страницу типа «Schedule Importer», которая перетаскивала бы данные из personal.work.org
в мой сценарий по адресу staff.work.org
(у компании есть прямое спонсорство и брендинг колледжа, поэтому мы размещены на их домене). Таким образом, они могут подтвердить классы, внести любые изменения, а затем представить их доступность. Затем данные отправляются в базу данных SQL, которую менеджер может найти на странице администратора и получить более полное представление о картине. И не только это, но мой сценарий предоставит сотрудникам возможность конвертировать свои графики в обычные, чтобы они могли добавлять в свой Календарь Google и лучше учиться, yadda yadda.
Я привел эту обратную историю, чтобы: а) вы увидели, что это не просто ajax ради ajax или междоменной очистки, просто чтобы срезать несколько углов, и b) потому что любая альтернатива приветствуется. *
Итак, оба сайта (персонал и личный) используют один и тот же метод аутентификации и, следовательно, один и тот же файл cookie. Вход в один означает вход в оба. Таким образом, пользователь может очень легко открыть обе страницы одновременно и т. Д. Если бы я установил личные данные в iFrame, они увидели бы их без необходимости повторного входа.
Вещи, которые не работают
Таким образом, данные не могут быть извлечены с помощью cURL, потому что cookie содержит IP-адрес входа в систему, и, следовательно, cURL отображается с IP-адресом сервера, а не пользователя. Новый cookie не может быть создан на стороне сервера, в частности, из-за того, что сайт входа в систему отклоняет любые попытки входа в систему с IP-адресов, привязанных к основным серверам. Насколько я могу судить, серверная часть отсутствует.
Но попытки получить клиентскую часть через ajax и jquery приводят к тому, что запрос обрабатывается как межсайтовый, поскольку мне приходится указывать полный URL-адрес из-за субдомена. Вместо того, чтобы передавать cookie и метод GET
, он передает:
Access-Control-Request-Method GET
Access-Control-Request-Headers cookie,x-requested-with
То, что быстрый поиск в Google говорит мне, является попыткой w3c иметь законный XSS. Справедливо, но это не работает, так что, думаю, это не сработает.
Я знаю, что если я положу его в iframe, я не смогу пройти по нему по тем же причинам.
хромые обходные пути
Но единственные другие альтернативы, о которых я могу подумать, это: а) заставить пользователя загрузить страницу расписания и загрузить ее на мою страницу, б) заставить его просматривать исходный код, скопировать и вставить его на мою страницу, или в) иметь его копию и вставьте прямо из обычного браузера.
Первые двое не собираются приносить мне гениальные награды или действительно завоевывать популярность. И любое копирование и вставка настолько полны потенциальных ошибок, как с моей, так и с их стороны, что не стоит рисковать.
Краткая версия вопроса
Но если я вставлю форму, которая указывает на страницу расписания с методом as get, нажатие кнопки отправки (без других входных данных или значений) просто перенесет их прямо на страницу, как если бы это была ссылка. Является ли это просто частью политики XSS браузера, когда запрос, отправляемый js, деформируется до того, как он попадает в трубки? Или что-то происходит в другой момент? Есть ли способ «загрузить» страницу с помощью формы (без доступа сервера к personal.work.org
для изменения заголовков на этом конце?
В принципе, я предполагаю, что мне не повезло, и это для большей пользы, но мне кажется, что мне чего-то не хватает, что должно позволить торговать данными, когда пользователь уже аутентифицирован с использованием того же куки ...
О, я проверил эту статью на тему , которая была проницательной, и предложила установить document.domain = work.org
в обоих документах, чтобы решить эту проблему. Согласно Firebug (document > domain : ""
) ..
не только это не вариант, но и все попытки установить, что даже в моем скрипте не удалось.
Есть идеи?