Perché i cookie e le intestazioni set-cookie non possono essere impostati mentre si effettua xmlhttprequest utilizzando setRequestHeader?

Question

Mi chiedevo perché non è possibile impostare le intestazioni del cookie utilizzando setRequestHeader. C'è qualche motivo specifico o solo che sono aggiunti dal browser stesso, quindi queste intestazioni sono disabilitate? C'è qualche problema di sicurezza?

--edit

Sto lavorando su node.js e utilizzato il modulo xmlhttprequest. Di seguito è riportato il codice di prova:

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

Qui ho bisogno di impostare cookie di intestazione come node.js' xmlhttprequest no esplicitamente aggiunge cookie di intestazione (come i browser). Quando si tenta di farlo, xmlhttprequest restituisce l'errore "Refused to set unsafe header".

Sebbene abbia trovato una patch e sia riuscito a inviare l'intestazione del cookie. Ma ci si chiedeva perché fosse disabilitato per impostare cookie-header? Ovunque io legga, ho scoperto che è necessario per l'integrità e la sicurezza dei dati, ma in questo caso la sicurezza può essere violata, non viene menzionato dove. Voglio valutare se, questo problema di integrità dei dati è valido anche per l'applicazione node.js se vado con la mia patch.

Answer 1

sono sicuro che sarebbe passato attraverso il working draft e trovato

Le intestazioni di cui sopra sono controllati dal programma utente per farla controllare quegli aspetti di trasporto.

In primo luogo, dobbiamo capire, si tratta di standard che funzionano come linee guida per l'interoperabilità delle funzioni tra diversi browser. Non è obbligatorio per il browser e quindi i browser hanno un diverso livello di adesione a questo standard per diversi motivi.

In secondo luogo, dal punto di vista tecnico è possibile emulare un agente utente, considerare il programma come browser e impostare in modo ottimale tali valori secondo gli standard citati.

Infine, l'intento di non consentire la sovrascrittura dei intestazioni o la creazione di intestazioni per alcuni settori come Content-Length, Cookie Ethos il secure design approach. È scoraggiare o almeno cercare di scoraggiare HTTP Request smuggling.

Answer 2

la documentazione indica che ciò viene fatto per proteggere l'integrità dei dati. http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader%28%29-method

Le intestazioni sopra sono controllati dal programma utente per farla controllare quegli aspetti dei trasporti. Ciò garantisce l'integrità dei dati fino all'estensione di . I nomi delle intestazioni che iniziano con Sec- non possono essere impostati su consentire la creazione di nuove intestazioni con la garanzia che non vengano fornite da XMLHttpRequest.

Answer 3

è possibile disattivare questo comportamento:

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

Answer 4

Sì, è necessario per l'integrità dei dati e la sicurezza. Per capire questo, devi capire il ruolo dei cookie nei metodi di richiesta HTTP.

I cookie sono importanti per identificare l'utente, il browser, la connessione ecc. E sono memorizzati sul browser web. JavaScript ti consente di manipolare i cookie, ma non tutti i cookie nel browser. Vedere HTTP cookies, questi sono impostati solo dal browser, in modo che l'utente non possa abusarne (tramite JavaScript).

Su un browser supportato, un HttpOnly cookie di sessione sarà usato solo durante la trasmissione HTTP (o HTTPS) richieste, limitando così l'accesso da altri non-HTTP API, (come JavaScript).

Quando si invia xmlhttprequest legge HttpOnly cookie e invia al server tramite l'intestazione Cookie. Ora se si fa xhr.setRequestHeader('Cookie', "key=value");, si sta tentando di manomettere i cookie inviati al server. setRequestHeader aggiungerà ulteriore key=value che potrebbe compromettere l'integrità dei cookie inviati.

Questi sono utilizzati dal server per autenticare l'utente (sessione, account di posta elettronica o qualsiasi account). Ciò consente essenzialmente al server di impedire l'uso improprio dei cookie per ottenere l'accesso al server.

Answer 5

Come è noto, per i browser, i cookie (tra le altre proprietà) devono essere gestiti con attenzione per impedire a terzi di rubare sessioni utente (o altri dati). Questo è un problema con i browser e la natura incontrollata di visitare un sito Web che esegue Javascript arbitrario.

Ovviamente questo rischio di esecuzione di codice arbitrario è basso o non rischioso per node.js, poiché si esegue solo uno script che è stato scritto e che può eseguire altro codice pianificato.

Se si dispone di uno sguardo al codice sorgente per driverdan di XMLHttpRequest.js troverete:

// 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" ]; 

Questa rispondere alla tua domanda specifica del motivo per cui la restrizione si applica particolarmente a questo script utilizzato per node.js - il codificatore era seguendo le specifiche (il più vicino possibile), nonostante ciò, probabilmente non era una precauzione di sicurezza richiesta in node.js. Tuttavia, questo livello di sicurezza predefinito viene prontamente modificato.

Come indicato da robertklep, è possibile disabilitare questa precauzione predefinita utilizzando il metodo setDisableHeaderCheck. E sì, questo ultimo punto non risponde o contribuisce in modo significativo verso una risposta per la tua domanda perché nella sua domanda lei ha dichiarato:

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

Abbiamo ora trovato non hai bisogno di quella patch.

Buona fortuna!

Answer 6

sono stato in grado di risolvere questo problema utilizzando il seguente Gist:
https://gist.github.com/killmenot/9976859

L'idea originale è tratto da qui:
https://gist.github.com/jfromaniello/4087861

ho affrontato con diversi problemi:

1. Source Gist è obsoleto e non funziona per me. Ad esempio, "request" lib API è stata modificata.
2. Potrei lavorare con la libreria "xmlhttprequest" di socket.io-client e non installare sullo stesso livello con socket.io-client.
3. L'originale "socket.io-client" (0.9.16) utilizza "xmlhttprequest" (1.4.2) che non supporta il metodo "setDisableHeaderCheck" (ma la versione 1.6.0 non supporta) . Quindi, faccio una forchetta e lo uso https://github.com/intspirit/socket.io-client/tree/0.9.16+20140408120400

socket.io-client (1.0.0-pre) utilizza engine.io-client che utilizza corretta versione di XMLHttpRequest. Immagino che in futuro userò la versione 1.0.0 invece della mia fork, specificare il trasporto "xhr-polling" e simulare XMLHttpRequest come fa l'originale gist.