Recentemente mi è stato detto che un cookie è "più sicuro" di una normale vecchia intestazione HTTP, che è più sicura di un parametro URL, in particolare quando si passa ai token di accesso. Qual è il motivo dietro il quale un cookie è più sicuro di un'intestazione HTTP?
Inoltre, sono abbastanza sicuro di capire perché un parametro URL non è sicuro: perché è sempre visibile e può essere facilmente afferrato. È corretto?
I cookie sono Intestazioni HTTP. L'intestazione è chiamata Cookie: e contiene il tuo cookie.
Ma i cookie sono in effetti più sicuri dei parametri URL perché i cookie non vengono mai inviati ad altri domini. I parametri URL, d'altro canto, finiranno nell'intestazione Referer: di qualsiasi sito che visiti direttamente da quello con il parametro URL.
Esistono tre modi standard per passare i dati dal browser: GET , POST e cookie (che vengono inviati per entrambe le richieste GET e POST ). Ecco una richiesta di esempio che viene inviata a un server se hai richiesto www.example.org/spec.html?secret=foo:
GET /spec.html?secret=foo HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Accept: */*
Mettere le informazioni sulla sessione nell'URL lo rende soggetto a essere copiato dall'utente del browser. Dal punto di vista della visibilità sul cavo, tuttavia, non fa differenza. È per questo motivo che i dati sensibili sono spesso POST ed. Indipendentemente dal modo in cui esegui una richiesta, tieni presente che probabilmente dovrebbe essere protetto da CSRF .
Come per i cookie, forniscono un modo per archiviare dati che durano per tutta la durata di una sessione o in tutte le schede del browser.
I cookie fanno parte della intestazione HTTP , quindi non possono essere più sicuri di loro stessi. I cookie hanno bandiere di sicurezza incorporate nelle loro specifiche: HTTPOnly e Secure, il l'ultimo dei quali impedisce la trasmissione su connessioni non SSL.
I parametri come parte dell'URL sono soggetti a essere registrati dai servizi Web che vengono eseguiti come parte delle statistiche o in altro modo, lasciandoli aperti per la lettura in chiaro per chiunque possa accedere.
Se si passa un token di autorizzazione tramite intestazioni http, è necessario disporre di una logica lato client per passare questo al server ogni volta che si effettua una richiesta. Uno skimmer può cercarlo nel codice lato client e può dirottare la sessione utente con lo script Java.
Ma se le stesse informazioni vengono passate tramite i cookie, è responsabilità del browser passare il cookie ogni volta che viene effettuata una richiesta (sei libero di scrivere la logica lato client). Quindi rendere un po 'difficile (ma non impossibile) identificare il meccanismo con cui viene passato il token.
Se il cookie è impostato su httponly, il dirottamento di sessione diventa quasi impossibile tramite JavaScript (alcuni lettori hanno letto queste informazioni su JavaScript ma il supporto è in aumento). E i cookie hanno una stessa politica di origine. Ma usando ancora strumenti come il violinista, un hacker determinato sarà in grado di accedere a queste informazioni.
Ma l'hacker dovrebbe essere in grado di annusare la rete per ottenere queste informazioni.
Quindi, in conclusione, un cookie è sicuramente più sicuro.
Se sei così preoccupato per la sicurezza, allora vai per i certificati SSL che quasi rimuove la minaccia della rete che annusa un'attività inutile.
I parametri dell'URL vengono inviati nell'intestazione Referer ad altri siti, quindi sono il modo peggiore per passare i dati riservati.
L'(obsoleto) Cookie2 header è crittografato utilizzando una nonce fornita dal sito nella sua Set-Cookie2 intestazione di risposta. Questo è quindi il meno negativo, ma non è supportato bene.
Altre intestazioni di richiesta (incluso Cookie ) sono da qualche parte nel mezzo.
Nessuna di queste opzioni è "sicura".
L'opzione sicura solo è HTTPS (cioè SSL) che utilizza un'autorità di certificazione reciprocamente attendibile.
Credo che sia i cookie che le intestazioni abbiano punti forti e deboli. Poiché alcune risposte indicano già i punti forti dei cookie, menzionerò il punto di forza delle intestazioni. Le intestazioni devono essere trasmesse a livello di codice dall'applicazione js; non vengono mai automaticamente trasmessi dal browser all'accesso a un URL sul rispettivo dominio. Ciò rende tale che altre applicazioni js o snippet non possano inviare automaticamente l'intestazione, eliminando così un'intera gamma di attacchi nelle aree CSRF o cross-site scripting. Ovviamente, l'uso esclusivo di HTTPS su TLS e la disattivazione del downgrade su HTTP sono necessari in entrambi i casi.