SSL con GET e POST

Ora, la domanda è, sai che cosa una richiesta HTTP ?

Bene, supponendo che no, ecco un esempio di uno:

GET /test?param1=hello&param2=world HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

Tutte di queste informazioni sono incluse nel trasporto SSL, come dice gentilmente il commento sulla tua risposta. Questo significa:

• Ottieni parametri crittografati.
• Corpo HTTP (parametri post) sono crittografati.

Cosa non è necessariamente sicuro:

• L'host che stai chiedendo. La maggior parte dei server Web in questi giorni supporta i parametri Host: something in modo che più domini possano essere gestiti da un server Web su un'interfaccia e un indirizzo IP. Chiaramente, questa intestazione è crittografata, tuttavia, se si esegue traffico non-https al sito, dovrebbe essere chiaro su quali host è possibile connettersi. Anche se questo non è il caso, DNS inverso ti dirà sicuramente cosa è ospitato su quell'IP e probabilmente puoi fare un'ipotesi ragionevole da lì.
• Informazioni sul browser / client. Sfortunatamente ogni client https è diverso e il suo processo di negoziazione potrebbe potenzialmente dare via quale piattaforma su cui gira, o quale browser è. Questa non è la fine del mondo con qualsiasi mezzo, è solo un fatto da capire.

Le richieste POST sembrano simili alle richieste, tranne che contengono un corpo. Questo può assomigliare a questo:

POST /testpost HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

param1=hello&param2=hello

Ci sono alcune varianti più complicate, ovviamente, ma in sostanza è tutto criptato comunque.

Non ho visto questo menzionato nelle altre risposte, ma generalmente non dovresti inserire informazioni segrete (password) nelle richieste GET anche con SSL, ma usa il POST. Perché? L'URL con le informazioni sensibili verrà generalmente registrato alle due estremità; ad esempio, nell'elenco cronologico dei browser (https://www.example.com?user=me&password=MyPassword) nonché i registri sul server. Le informazioni POST (specialmente con le password) in genere non vengono scritte nei log del server Web, anche se ovviamente possono essere configurate per essere registrate, quindi è meglio non riutilizzare (o usare password simili) su siti diversi.

SSL crittografa e garantisce l'autenticità dell'intera connessione, inclusi il metodo e l'URL richiesti. Un GET è altrettanto ben protetto come un POST.

Quando SSL funziona come previsto, un intercettatore può solo vedere quale indirizzo IP si sta collegando a quale indirizzo IP (e su quale porta, ma di solito è 443), a che ora e quanto. Se ci sono più host virtuali sullo stesso computer, l'utente malintenzionato non può sapere quale contatto si sta contattando (tuttavia, l'intercettatore potrebbe visualizzare le richieste DNS appena prima della richiesta HTTPS e fare un'ipotesi plausibile). Anche tutte queste informazioni sono autenticate: un utente malintenzionato attivo non può giocare man-in-the-middle e modificare i dati in transito.

Cose che possono rendere SSL non funziona come previsto:

• Uso improprio dell'applicazione, in cui alcuni dati vengono accidentalmente inviati su un semplice HTTP.
• Una delle rare vulnerabilità del protocollo SSL, come la recente vulnerabilità BEAST .
• Mancata manipolazione dei certificati, che consente all'autore dell'attacco di passare come server, perché il certificato del server è stato trapelato, un'autorità di certificazione ha consegnato impropriamente un certificato all'autore dell'attacco o perché il client non controlla correttamente il certificato del server .
  • In questa nota, ricorda che SSL, poiché viene utilizzato la maggior parte delle volte, autentica il server ma non il client. Il server non può assumere nulla sul client.
• Un attacco canale laterale potrebbe rivelare alcune informazioni agli intercettatori. Ad esempio, il momento esatto in cui i partecipanti inviano i dati può rivelare qualcosa su come vengono calcolati i dati e quindi sulla natura dei dati. La dimensione di ogni pacchetto è anche nota all'attaccante. Quanto questo possa rivelare se i partecipanti prendono precauzioni e sulla natura delle informazioni. Una conversazione in tempo reale è molto più incline a tale analisi del traffico rispetto al download di un file.

Vedi anche Come è possibile che le persone che osservano una connessione HTTPS stabilita non sappiano come decrittografarla? per qualche background.

Solo per aggiungere un altro piccolo dettaglio, su come questo viene realizzato su HTTP.
Probabilmente ti starai chiedendo (o dovresti esserlo, se sai che hai familiarità con handshake SSL ), come Il canale SSL viene creato, senza che la richiesta GET venga inviata in chiaro? Che dire se la mia richiesta deve passare attraverso un proxy: come è possibile?

HTTP v1.1 ha introdotto un CONNECT metodo HTTP, che sostanzialmente invia una richiesta semplificata a il server attraverso un proxy, contenente solo l'URL host più semplice (senza parametri aggiuntivi, intestazioni o corpo). In base a questa richiesta, viene creato un tunnel SSL, quindi viene inviata la richiesta GET (o POST) originale su di esso.

Source: Answer on Stack Overflow

Il metodo GET è pensato solo per il recupero dei dati e non dovrebbe avere effetti collaterali . Ma POST è pensato per quello scopo specifico: modificare i dati sul lato server.

Le richieste GET possono essere facilmente trincerate (vedi Falsi per richieste cross-site ) solo posizionare un'immagine su una pagina mentre falsificare le richieste POST non è così facile (questo è anche un motivo per cui si dovrebbero consentire solo le richieste POST autorizzate).

Un altro punto non menzionato è che se si utilizza GET e si dispone di contenuti di terze parti incorporati o collegati (ad esempio annunci del sito), tale sito di terze parti otterrà l'URL completo (con dati dei parametri sensibili) nell'intestazione Referer.

Che espone i dati a terzi che non dovrebbero averli.