Я понимаю основные идеи XSS и политики того же происхождения, поэтому, если ваша реакция колена состоит в том, чтобы научить меня основам, вы можете продвинуться хотя бы на полшага вперед...
Если javascript является клиентским, в какой момент HTTP-запрос, отправленный через XMLHttpRequest, отличается от пользователя, отправляющего запрос с помощью кнопки отправки формы?
Вот моя реальная ситуация:
Я работаю над сценарием, который (если это возможно) будет собирать безопасные данные из защищенного поддомена, где хранятся такие личные данные. Ради этого вопроса я назову свой сайт staff.work.org, а другой сайт personal.work.org.
Предыстория, пропустите, если хотите
Таким образом, преимущества такого сценария заключаются в том, что он упростит избыточный процесс и принесет пользу как персоналу, так и руководству. Прямо сейчас каждый сотрудник должен отправить менеджеру по расписанию свою доступность на этот срок. Поскольку большинство сотрудников — студенты, им просто нужно отправить расписание занятий по электронной почте. Каждый из них отправляет свое расписание по электронной почте, и менеджер делает с ним все, что они делают, возможно, просто создает большой текстовый файл или файл Excel.
Но я хочу, чтобы они просто перешли на страницу типа «Импорт расписаний», которая будет извлекать данные из personal.work.org в мой сценарий в staff.work.org (компания имеет прямое спонсорство и брендинг колледжа, поэтому мы размещены на их домене) . Таким образом, они могут подтвердить классы, внести любые изменения, а затем сообщить о своей доступности. Затем данные отправлялись в базу данных SQL, которую менеджер мог открыть на странице администрирования и получить гораздо лучшее представление об общей картине. Кроме того, мой сценарий предлагает сотрудникам возможность преобразовывать свои расписания в ical, чтобы они могли вставлять свой календарь Google и лучше успевать за учебными заведениями, бла-бла-бла.
Я рассказал эту предысторию, чтобы а) вы увидели, что это не просто ajax ради ajax или междоменного парсинга, просто чтобы срезать несколько углов, и б) потому что любая альтернатива приветствуется.
Таким образом, оба сайта (служебный и личный) используют один и тот же метод аутентификации и, следовательно, один и тот же файл 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, я не смогу перейти к нему по тем же причинам.
хромые обходные пути
Но единственные другие альтернативы, которые я могу придумать, это: а) попросить пользователя загрузить страницу расписания и загрузить ее на мою страницу, б) попросить их просмотреть исходный код, скопировать и вставить его на мою страницу или в) попросить их скопировать и вставить прямо из обычного просмотра браузера.
Первые два не принесут мне никаких наград за гениев и не станут популярными. И любое копирование и вставка настолько полны потенциальных ошибок как с моей, так и с их стороны, что не стоит рисковать.
Короткая версия вопроса
Но если я добавлю форму, которая указывает на страницу расписания с методом get, нажатие кнопки отправки (без каких-либо других входных данных или значений) просто приведет их прямо на страницу, как если бы это была ссылка. Является ли это просто частью политики XSS браузера, когда запросы, отправленные js, искажаются, прежде чем они попадут в трубы? Или что-то происходит в другом месте? Есть ли способ «загрузить» страницу с помощью формы (без доступа к серверу personal.work.org для изменения заголовков на этом конце?
По сути, я предполагаю, что мне не повезло, и это во благо, но, похоже, мне чего-то не хватает, что должно позволять торговать данными, когда пользователь уже аутентифицирован с использованием того же файла cookie...
О, я проверил эта статья на тему, которая показала, что предлагаемая установка document.domain = work.org в обоих документах решит проблему. Мало того, что это не вариант, но все попытки установить это даже в моем сценарии не увенчались успехом, согласно Firebug (document > domain : "")..
Есть идеи?
