Come funzionano i cookie HttpOnly con le richieste AJAX?

JavaScript deve accedere ai cookie se AJAX viene utilizzato su un sito con restrizioni di accesso basate sui cookie. I cookie HttpOnly funzioneranno su un sito AJAX?

Modifica: Microsoft ha creato un modo per prevenire gli attacchi XSS impedendo l'accesso JavaScript ai cookie se viene specificato HttpOnly. FireFox ha successivamente adottato questo. Quindi la mia domanda è: se stai usando AJAX su un sito, come StackOverflow, i cookie solo HTTP sono un'opzione?

Modifica 2: Domanda 2. Se lo scopo di HttpOnly è impedire l'accesso JavaScript ai cookie e puoi ancora recuperare i cookie tramite JavaScript tramite l'oggetto XmlHttpRequest, qual è lo scopo di HttpOnly ?

Modifica 3: Ecco una citazione da Wikipedia:

Quando il browser riceve un cookie di questo tipo, dovrebbe usarlo normalmente nei seguenti scambi HTTP, ma non per renderlo visibile agli script lato client. [32] Il HttpOnlyflag non fa parte di alcuno standard e non è implementato in tutti i browser. Si noti che al momento non è possibile prevenire la lettura o la scrittura del cookie di sessione tramite XMLHTTPRequest. [33].

Capisco che document.cookieè bloccato quando si utilizza HttpOnly. Ma sembra che puoi ancora leggere i valori dei cookie nell'oggetto XMLHttpRequest, consentendo XSS. In che modo HttpOnly ti rende più sicuro di? Producendo cookie essenzialmente di sola lettura?

Nel tuo esempio, non posso scrivere sul tuo document.cookie, ma posso ancora rubare il tuo cookie e pubblicarlo sul mio dominio usando l'oggetto XMLHttpRequest.

<script type="text/javascript">
    var req = null;
    try { req = new XMLHttpRequest(); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {}
    req.open('GET', 'http://stackoverflow.com/', false);
    req.send(null);
    alert(req.getAllResponseHeaders());
</script>

Modifica 4: Scusa, intendevo inviare XMLHttpRequest al dominio StackOverflow, quindi salvare il risultato di getAllResponseHeaders () in una stringa, regex il cookie e quindi pubblicarlo su un dominio esterno. Sembra che Wikipedia e ha.ckers concordino con me su questo, ma mi piacerebbe essere rieducato ...

Modifica finale: Ahh, a quanto pare entrambi i siti sono sbagliati, questo è in realtà un bug in FireFox . IE6 e 7 sono in realtà gli unici browser che attualmente supportano completamente HttpOnly.

Per ribadire tutto ciò che ho imparato:

• HttpOnly limita tutti gli accessi a document.cookie in IE7 e FireFox (non sono sicuro di altri browser)
• HttpOnly rimuove le informazioni sui cookie dalle intestazioni di risposta in XMLHttpObject.getAllResponseHeaders () in IE7.
• XMLHttpObjects può essere inviato solo al dominio da cui ha origine, quindi non esiste alcuna pubblicazione interdominio dei cookie.

modifica: è probabile che queste informazioni non siano più aggiornate.

Sì, i cookie solo HTTP andrebbero bene per questa funzionalità. Verranno comunque fornite la richiesta di XmlHttpRequest al server.

Nel caso di Stack Overflow, i cookie vengono automaticamente forniti come parte della richiesta XmlHttpRequest. Non conosco i dettagli di implementazione del provider di autenticazione StackTranslate.it, ma i dati sui cookie vengono probabilmente utilizzati automaticamente per verificare la tua identità a un livello inferiore rispetto al metodo del controller "voto".

Più in generale, i cookie non sono richiesti per AJAX. Il supporto XmlHttpRequest (o anche remoting iframe, su browser meno recenti) è tutto ciò che è tecnicamente richiesto.

Tuttavia, se si desidera fornire sicurezza per la funzionalità abilitata per AJAX, si applicano le stesse regole dei siti tradizionali. Hai bisogno di un metodo per identificare l'utente dietro ogni richiesta, e i cookie sono quasi sempre i mezzi a tale scopo.

Nel tuo esempio, non posso scrivere sul tuo document.cookie, ma posso ancora rubare il tuo cookie e pubblicarlo sul mio dominio usando l'oggetto XMLHttpRequest.

XmlHttpRequest non farà richieste tra domini (esattamente per il tipo di motivi che stai toccando).

Normalmente potresti inserire script per inviare il cookie al tuo dominio utilizzando iframe remoting o JSONP, ma poi HTTP-Only protegge nuovamente il cookie poiché è inaccessibile.

Se non avessi compromesso StackOverflow.com sul lato server, non saresti in grado di rubare i miei cookie.

Modifica 2: Domanda 2. Se lo scopo di Solo HTTP è impedire l'accesso JavaScript ai cookie e puoi ancora recuperare i cookie tramite JavaScript tramite l'oggetto XmlHttpRequest, qual è lo scopo di Solo HTTP?

Considera questo scenario:

• Trovo una strada per iniettare il codice JavaScript nella pagina.
• Jeff carica la pagina e il mio JavaScript dannoso modifica il suo cookie in modo che corrisponda al mio.
• Jeff invia una risposta stellare alla tua domanda.
• Poiché lo invia con i miei dati sui cookie anziché i suoi, la risposta diventerà mia.
• Vota la "mia" risposta stellare.
• Il mio vero account ottiene il punto.

Con i cookie solo HTTP, il secondo passaggio sarebbe impossibile, sconfiggendo così il mio tentativo XSS.

Modifica 4: Scusa, intendevo inviare XMLHttpRequest al dominio StackOverflow, quindi salvare il risultato di getAllResponseHeaders () in una stringa, regex il cookie e quindi pubblicarlo su un dominio esterno. Sembra che Wikipedia e ha.ckers concordino con me su questo, ma mi piacerebbe essere rieducato ...

È corretto. Puoi comunque dirottare la sessione in quel modo. Sottolinea in modo significativo il branco di persone che possono eseguire con successo anche quell'hacking XSS contro di te.

Tuttavia, se si va di nuovo al mio scenario di esempio, è possibile vedere dove HTTP-Solo non tagliare con successo gli attacchi XSS che si basano sulla modifica cookie del cliente (non raro).

Si riduce al fatto che a) nessun singolo miglioramento risolverà tutte le vulnerabilità eb) nessun sistema sarà mai completamente sicuro. HTTP-Only è uno strumento utile per puntellare su XSS.

Allo stesso modo, anche se la restrizione interdominio su XmlHttpRequest non ha successo al 100% nel prevenire tutti gli exploit XSS, non ti saresti mai sognato di rimuovere la restrizione.

Non necessariamente, dipende da cosa vuoi fare. Potresti elaborare un po '? AJAX non ha bisogno dell'accesso ai cookie per funzionare, può fare richieste da solo per estrarre informazioni, la richiesta della pagina che la chiamata AJAX effettua potrebbe accedere ai dati dei cookie e restituirli allo script chiamante senza che Javascript debba accedere direttamente al biscotti

Sì, sono un'opzione praticabile per un sito basato su Ajax. I cookie di autenticazione non sono manipolabili da script, ma sono semplicemente inclusi dal browser su tutte le richieste HTTP inviate al server.

Gli script non devono preoccuparsi di ciò che dice il cookie di sessione: fintanto che sei autenticato, tutte le richieste al server avviate da un utente o dallo script includeranno i cookie appropriati. Il fatto che gli script non possano conoscere da soli il contenuto dei cookie non ha importanza.

Per tutti i cookie utilizzati per scopi diversi dall'autenticazione, questi possono essere impostati senza il solo flag HTTP, se si desidera che lo script sia in grado di modificarli o leggerli. Puoi scegliere quali cookie devono essere solo HTTP, quindi ad esempio qualsiasi cosa non sensibile come le preferenze dell'interfaccia utente (ordinamento, comprimere il riquadro a sinistra o meno) può essere condivisa nei cookie con gli script.

Mi piacciono molto solo i cookie HTTP - è una di quelle estensioni del browser proprietarie che è stata un'idea davvero accurata.

C'è un po 'di più in questo.

Ajax non richiede strettamente i cookie, ma possono essere utili come altri poster hanno menzionato. Contrassegnare un cookie HTTPSolo per nasconderlo dagli script funziona solo in parte, perché non tutti i browser lo supportano, ma anche perché esistono soluzioni alternative comuni.

È strano che le intestazioni XMLHTTPresponse forniscano il cookie, tecnicamente il server non deve restituire il cookie con la risposta. Una volta impostato sul client, rimane impostato fino alla scadenza. Sebbene esistano schemi in cui il cookie viene modificato con ogni richiesta per impedire il riutilizzo. Quindi potresti essere in grado di evitare questa soluzione alternativa modificando il server per non fornire il cookie sulle risposte XMLHTTP.

In generale, tuttavia, penso che HTTPOnly dovrebbe essere usato con una certa cautela. Esistono attacchi di scripting tra siti in cui un utente malintenzionato organizza un utente per inviare una richiesta simile a ajax proveniente da un altro sito, utilizzando semplici moduli di post, senza l'uso di XMLHTTP, e il cookie ancora attivo del browser autenticherebbe la richiesta.

Se vuoi essere sicuro che una richiesta AJAX sia autenticata, la richiesta stessa E le intestazioni HTTP devono contenere il cookie. Ad esempio attraverso l'uso di script o input nascosti unici. HTTPOnly lo ostacolerebbe.

Di solito il motivo interessante per volere HTTPOnly è impedire che i contenuti di terze parti inclusi nella tua pagina web rubino i cookie. Ma ci sono molte ragioni interessanti per essere molto cauti nell'includere contenuti di terze parti e filtrarli in modo aggressivo.

I cookie vengono gestiti automaticamente dal browser quando si effettua una chiamata AJAX, quindi non è necessario che Javascript si scherzi con i cookie.

Pertanto presumo che JavaScript debba accedere ai tuoi cookie.

Tutte le richieste HTTP dal tuo browser trasmettono le informazioni sui cookie per il sito in questione. JavaScript può sia impostare che leggere i cookie. I cookie non sono per definizione richiesti per le applicazioni Ajax, ma sono necessari per la maggior parte delle applicazioni Web per mantenere lo stato dell'utente.

La risposta formale alla tua domanda come formulata - "JavaScript deve accedere ai cookie se si utilizza AJAX?" - è quindi "no". Pensa ai campi di ricerca avanzata che utilizzano le richieste Ajax per fornire opzioni di suggerimento automatico, ad esempio. In questo caso non sono necessarie informazioni sui cookie.

Come chiarimento: dal punto di vista del server, la pagina richiesta da una richiesta AJAX non è sostanzialmente diversa da una richiesta di ricezione HTTP standard eseguita dall'utente facendo clic su un collegamento. Tutte le normali proprietà della richiesta: user-agent, ip, sessione, cookie, ecc. Vengono passate al server.

No, la pagina richiesta dalla chiamata AJAX ha accesso anche ai cookie ed è ciò che controlla se hai effettuato l'accesso.

Puoi eseguire altre autenticazioni con Javascript, ma non mi fiderei, preferisco sempre mettere qualsiasi tipo di controllo di autenticazione nel back-end.

Sì, i cookie sono molto utili per Ajax.

Inserire l'autenticazione nell'URL della richiesta è una cattiva pratica. La settimana scorsa è stato pubblicato un articolo su come ottenere i token di autenticazione negli URL dalla cache di Google.

No, non c'è modo di prevenire gli attacchi. I browser meno recenti consentono ancora un banale accesso ai cookie tramite javascript. Puoi bypassare solo http, ecc. Qualunque cosa ti venga in mente può essere aggirata con uno sforzo sufficiente. Il trucco è fare uno sforzo eccessivo per essere utile.

Se vuoi rendere il tuo sito più sicuro (non esiste una sicurezza perfetta) puoi utilizzare un cookie di autenticazione che scade. Quindi, se il cookie viene rubato, l'attaccante deve usarlo prima che scada. In caso contrario, hai una buona indicazione che c'è attività sospetta su quell'account. Più è breve la finestra temporale, migliore è la sicurezza ma maggiore è il carico che genera sul server generando e mantenendo le chiavi.