È possibile che un attacco XSS ottenga i cookie HttpOnly?

Question

Leggere questo post sul blog sui cookie di HttpOnly mi ha fatto iniziare a pensare, vero? è possibile ottenere un cookie HttpOnly attraverso qualsiasi forma di XSS? Jeff afferma che "alza considerevolmente il livello". ma sembra che non protegga completamente da XSS.

A parte il fatto che non tutti i browser supportano correttamente questa funzione, come può un hacker ottenere i cookie di un utente se sono HttpOnly?

Non riesco a pensare ad alcun modo per fare in modo che un cookie HttpOnly si invii a un altro sito o venga letto dallo script, quindi sembra che questa sia una funzionalità di sicurezza sicura, ma sono sempre stupito di quanto facilmente alcune persone possano aggirare molti livelli di sicurezza.

Nell'ambiente in cui lavoro, utilizziamo IE esclusivamente, quindi gli altri browser non sono un problema. Sto cercando specificamente altri modi in cui questo potrebbe diventare un problema che non si basa su difetti specifici del browser.

Answer 1

In primo luogo, come alcuni altri hanno menzionato, XSS può consentire altri payload, non solo il furto di cookie.

Ma c'è comunque per rubare solo i cookie http, con XSS? (ignorando la domanda del supporto httpOnly?) .... La risposta è: Sì.
Un sottoinsieme di XSS è noto come Cross-Site Tracing (XST) (o vai al originale documento di ricerca ). In questo attacco il payload XSS invia una richiesta HTTP TRACE al server Web (o proxy , avanti o indietro), che restituirà al cliente la richiesta completa - COMPRESI I VOSTRI COOKIE, solo o meno. Il payload XSS può quindi analizzare le informazioni restituite e recuperare quei deliziosi cookie ...

---

A proposito, ancora un altro "sottoinsieme". (kinda) di XSS, comporta l'iniezione di payload nelle intestazioni di risposta. Sebbene simile, questo non è esattamente XSS e Header Injection può persino portare a HTTP Response Splitting (HRS) - che è molto più potente, consente il controllo quasi completo di altri client, avvelenamento da cache e ovviamente accesso ai cookie, se lo si desidera.

Answer 2

Se il browser non capisce HttpOnly, l'attacco ha successo. Modifica: okay, non ti preoccupare. Va bene, ma lascerò questo avviso solo come riferimento. È utile dichiararlo esplicitamente.

Un altro modo di rubare oltre ad annusare la rete sarebbe il controllo diretto del computer dell'utente. Quindi i cookie possono essere letti da un file. Se si tratta di un cookie di sessione, verrà ovviamente rimosso dopo la chiusura del browser.

A proposito, rubare i cookie di sessione non è l'unico possibile "payload" di attacco XSS. Ad esempio, potrebbe rendere inutile la protezione CSRF. Potrebbe alterare i contenuti del tuo sito per ingannare l'utente. E molte altre cose dannose.

Quindi proteggiti meglio (uscita di escape), e pensa a HttpOnly come livello aggiuntivo di protezione.

Answer 3

L'uso dei cookie di HttpOnly impedirà agli attacchi XSS di ottenere quei cookie.

A meno che:

• il tuo browser non supporta HttpOnly
• esiste una vulnerabilità finora sconosciuta nel browser che interrompe HttpOnly
• il server è stato compromesso (ma probabilmente sei comunque eliminato).

Come ha notato un altro poster: XSS non è l'unica minaccia là fuori, e catturare i cookie non è l'unica minaccia di XSS. Sono sicuro che lo sapevi, sono solo completo!

Buona fortuna!

Answer 4

JavaScript può modificare l'HTML nella pagina, pertanto httpOnly not significa che sei al sicuro da XSS.

Answer 5

Lo sniffing dei pacchetti può leggere i cookie trasmessi su http. Ma potrebbe non rientrare nell'XSS.