it-swarm.dev

Un cookie è più sicuro di una semplice intestazione HTTP?

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 passano i token di accesso. Qual è il ragionamento alla base di 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 catturato. È corretto?

15
mergesort

Cookie are Intestazioni HTTP. L'intestazione si chiama 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'altra parte, finiranno nel Referer: intestazione di qualsiasi sito che visiti direttamente da quello con il parametro URL.

23
tylerl

Esistono tre modi standard per trasferire i dati dal browser: GET, POST e cookie (che vengono inviati per entrambe le richieste GET e POST). Ecco una richiesta di esempio in quanto 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: */*

Inserendo le informazioni sulla sessione nell'URL, è possibile che vengano copiate dall'utente del browser. Dal punto di vista della visibilità sul filo, tuttavia, non fa alcuna differenza. È per questo motivo che i dati sensibili sono spesso POSTed. Qualunque sia il modo in cui si effettua una richiesta, tenere presente che probabilmente dovrebbe essere protetta da CSRF .

Per quanto riguarda i cookie, forniscono un modo per archiviare dati che durano per tutta la durata di una sessione o attraverso le schede del browser.

8
Jeff Ferland

Se si passa il token di autorizzazione tramite le intestazioni http, è necessario disporre di una logica lato client per passarlo al server ogni volta che si effettua una richiesta. Uno skimmer può cercarlo nel codice lato client e può dirottare la sessione utente con Java di Java.

Ma se le stesse informazioni vengono passate tramite i cookie, è responsabilità del browser passare i cookie ogni volta che viene effettuata una richiesta (si è liberi di scrivere la logica lato client). Quindi rendere un po 'difficile (ma non impossibile) identificare il meccanismo in cui viene passato il token.

Se il cookie è impostato su httponly, il dirottamento della sessione diventa quasi impossibile tramite JavaScript (ho letto alcuni browser che forniscono queste informazioni a JavaScript ma il supporto sta aumentando). E i cookie hanno la stessa politica di origine. Ma usando ancora strumenti come il violinista, un determinato hacker 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, scegli certificati SSL che rimuovono quasi la minaccia di sniffare la rete di un'attività futile.

3
Mr.X

I cookie fanno parte di intestazione HTTP , quindi non possono essere più sicuri di loro stessi. I cookie hanno flag di sicurezza integrati nelle loro specifiche: HTTPOnly e Secure, quest'ultimo dei quali impedisce la trasmissione su connessioni non SSL.

I parametri come parte dell'URL sono inclini a essere registrati dai servizi Web in esecuzione come parte delle statistiche o in altro modo, lasciandoli aperti alla lettura in testo normale per chiunque possa ottenere l'accesso.

3
Ditmar Wendt
  1. I parametri URL vengono inviati nell'intestazione Referer ad altri siti, quindi sono il modo peggiore per trasmettere dati sensibili.

  2. Il (obsoleto) Cookie2 header è crittografato utilizzando un nonce fornito dal sito nel suo Set-Cookie2 header di risposta. Questo è quindi il meno male, ma non è supportato bene.

  3. Altre intestazioni di richiesta (incluso Cookie) si trovano nel mezzo.

Nessuna di queste opzioni è "sicura".

L'opzione sicura only è HTTPS (ovvero SSL) che utilizza un'autorità di certificazione reciprocamente attendibile.

2
Nicholas Shanks

Immagino sia i cookie che le intestazioni abbiano punti forti e deboli. Poiché alcune risposte indicano già i punti di forza dei cookie, citerò il punto di forza delle intestazioni. Le intestazioni devono essere trasmesse programmaticamente dall'applicazione js; non vengono mai trasmessi automaticamente dal browser quando accedono a un URL sul rispettivo dominio. Ciò rende tale che altre applicazioni js o frammenti non possano inviare l'intestazione automaticamente, eliminando così una vasta gamma di attacchi nel CSRF o nelle aree di scripting cross site. Naturalmente in entrambi i casi è necessario utilizzare solo HTTPS su TLS e disabilitare il downgrade a HTTP.

1
NicuMarasoiu