Почему файлы cookie и заголовки set-cookie не могут быть установлены при создании xmlhttprequest с помощью setRequestHeader?

мне было интересно, почему нельзя ставить cookie заголовки с помощью setRequestHeader. Есть ли какая-то конкретная причина или просто они добавляются самим браузером, поэтому эти заголовки отключены? Есть ли какие-либо проблемы с безопасностью?

--Edit

Я работаю над узлом.js и использовал xmlhttprequest модуль. Ниже приведен тестовый код:

var xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
xhr.withCredentials = true;
xhr.setRequestHeader('Cookie', "key=value");
xhr.send(null);

здесь мне нужно установить cookie-header как node.js' xmlhttprequest явно не добавляет cookie-заголовок(как браузеры делать.) При попытке сделать это,xmlhttprequest выдает ошибку "Refused to set unsafe header".

хотя я нашел патч и успешно смог отправить cookie-заголовок. Но было интересно, почему он был отключен, чтобы установить cookie-файл-заголовок? Где-либо я читал, обнаружил, что это необходимо для целостности и безопасности данных, но какая безопасность может быть нарушена в этом случае, нигде не упоминается. Я хочу оценить, действительно ли эта проблема целостности данных для узла.приложение js также, если я пойду с моим патчем.

29
cookies html javascript node.js xmlhttprequest

6 ответов

Я уверен, что вы прошли бы через рабочий проект и нашли

вышеуказанные заголовки управляются агентом пользователя, чтобы позволить ему управлять эти аспекты транспорта.

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

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

наконец, намерение запретить перезапись заголовков или настройку заголовков для определенных полей, таких как Content-Length , Cookie дух secure design approach. Это обескураживает или, по крайней мере, пытается обескуражить HTTP запрос контрабанды.

23

вы можете отключить это поведение: 

var xhr = new XMLHttpRequest();
xhr.setDisableHeaderCheck(true);
xhr.open(...);
...
14

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

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

Если вы посмотрите на исходный код driverdan's XMLHttpRequest.js вы найдете:

 // These headers are not user setable.   
 // The following are allowed but banned in the spec:   
 // * user-agent   
 var forbiddenRequestHeaders = [
    "accept-charset",
    "accept-encoding",
    "access-control-request-headers",
    "access-control-request-method",
    "connection",
    "content-length",
    "content-transfer-encoding",
    "cookie",
    "cookie2",
    "date",
    "expect",
    "host",
    "keep-alive",
    "origin",
    "referer",
    "te",
    "trailer",
    "transfer-encoding",
    "upgrade",
    "via"   ];

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

как отметил робертклеп, вы можете отключите эту предосторожность по умолчанию с помощью setDisableHeaderCheck метод. И да это не ответ или способствовать ответ на ваш вопрос, потому что в вашем вопросе вы указали:

I have found a patch and successfully able to send the cookie-header

Теперь мы обнаружили, что вам не нужен этот патч.

Удачи!

8

Да, это необходимо для целостности и безопасности данных. Чтобы понять это, вы должны понять роль файлов cookie в методах HTTP-запросов.

Cookies важны для идентификации пользователя, браузера, соединения и т. д. И хранятся в веб-браузере. JavaScript позволяет манипулировать файлами cookie, но не всеми файлами cookie в браузере. См.HTTP и cookie-файлы, они устанавливаются только Браузером, так что пользователь не может злоупотреблять им (через JavaScript).

на a поддерживаемый браузер, файл cookie сеанса HttpOnly будет использоваться только при передаче HTTP (или HTTPS) запросов, тем самым ограничивая доступ из других, не HTTP API (например, JavaScript).

когда вы отправляете xmlhttprequest он читает HttpOnly cookies и отправляет на сервер через . Теперь, если вы это сделаете xhr.setRequestHeader('Cookie', "key=value");, вы пытаетесь изменить файлы cookie, отправленные на сервер. setRequestHeader добавить дополнительное key=value это может поставить под угрозу целостность файлов cookie отправленный.

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

4

в документации упоминается, что это делается для защиты целостности данных. http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader%28%29-method

вышеуказанные заголовки управляются агентом пользователя, чтобы позволить ему управлять эти аспекты транспорта. Это гарантирует целостность данных некоторым степень. Имена заголовков, начинающиеся с Sec - не могут быть установлены в разрешить чеканку новых заголовков, которые гарантированно не будут получены объект XMLHttpRequest.

2

Я смог решить эту проблему, используя следующий Gist:
https://gist.github.com/killmenot/9976859

оригинальная идея взята отсюда:
https://gist.github.com/jfromaniello/4087861

я столкнулся с рядом проблем:

  1. исходный Gist устарел и не работает для меня. Например, был изменен API lib" request".
  2. я мог бы работать с розетка.библиотека "xmlhttprequest" io-клиента и не устанавливайте на одном уровне с socket.io-клиент.
  3. Оригинал "гнездо.io-client "(0.9.16) использует "xmlhttprequest" (1.4.2), который не поддержка метода "setDisableHeaderCheck" (но 1.6.0 делает). Итак, я делаю вилка и используй ееhttps://github.com/intspirit/socket.io-client/tree/0.9.16+20140408120400

гнездо.io-client (1.0.0-pre) использует движок.io-клиент, использующий правильную версию объект XMLHttpRequest. Я предполагаю, что в будущем я буду использовать версию 1.0.0 вместо моей вилки, укажите транспорт" xhr-polling " и макет XMLHttpRequest, как это делает исходный gist.

1