Una stringa di query HTTPS è sicura?

Sto creando un'API sicura basata sul Web che utilizza HTTPS; tuttavia, se consento agli utenti di configurarlo (includendo l'invio della password) utilizzando una stringa di query, anche questo sarà sicuro o dovrei forzarlo per mezzo di un POST?

Sì. Ma usare GET per dati sensibili è una cattiva idea per diversi motivi:

• Per lo più perdita di referrer HTTP (un'immagine esterna nella pagina di destinazione potrebbe perdere la password [1])
• La password verrà archiviata nei registri del server (il che è ovviamente negativo)
• Cache della cronologia nei browser

Pertanto, anche se Querystring è protetto, non è consigliabile trasferire dati sensibili su querystring.

[1] Anche se devo notare che RFC afferma che il browser non dovrebbe inviare referrer da HTTPS a HTTP. Ma ciò non significa che una cattiva barra degli strumenti del browser di terze parti o un'immagine / flash esterni da un sito HTTPS non lo perderanno.

Da un punto di vista "sniff il pacchetto di rete" una richiesta GET è sicura, poiché il browser stabilirà prima la connessione protetta e quindi invierà la richiesta contenente i parametri GET. Ma gli URL GET verranno archiviati nella cronologia / completamento automatico del browser degli utenti, il che non è un buon posto in cui archiviare, ad esempio, i dati della password. Naturalmente questo vale solo se si prende la definizione più ampia di "Webservice" che potrebbe accedere al servizio da un browser, se accedete solo dall'applicazione personalizzata, questo non dovrebbe essere un problema.

Quindi dovrebbe essere preferito usare post almeno per le finestre di dialogo della password. Inoltre, come sottolineato nel link littlegeek pubblicato, è più probabile che un URL GET venga scritto nei log del server.

Sì , le stringhe di query verranno crittografate.

Il motivo alla base è che le stringhe di query fanno parte del protocollo HTTP che è un protocollo a livello di applicazione, mentre la parte di sicurezza (SSL / TLS) proviene dal livello di trasporto. Prima viene stabilita la connessione SSL e quindi i parametri della query (che appartengono al protocollo HTTP) vengono inviati al server.

Quando si stabilisce una connessione SSL, il client eseguirà i seguenti passaggi in ordine. Supponiamo che tu stia tentando di accedere a un sito chiamato example.com e desideri inviare le tue credenziali utilizzando i parametri della query. L'URL completo potrebbe essere simile al seguente:

https://example.com/login?username=alice&password=12345)

1. Il tuo client (ad es. Browser / app mobile) risolverà innanzitutto il tuo nome di dominio example.comin un indirizzo IP (124.21.12.31)utilizzando una richiesta DNS. Quando si interrogano tali informazioni, vengono utilizzate solo le informazioni specifiche del dominio, ovvero solo example.com.
2. Ora, il client tenterà di connettersi al server con l'indirizzo IP 124.21.12.31e tenterà di connettersi alla porta 443 (porta del servizio SSL non la porta HTTP 80 predefinita).
3. Ora, il server at example.cominvierà i suoi certificati al tuo client.
4. Il client verificherà i certificati e inizierà a scambiare una chiave segreta condivisa per la sessione.
5. Dopo aver stabilito correttamente una connessione protetta, solo allora i parametri della query verranno inviati tramite la connessione protetta.

Pertanto, non esporrai dati sensibili. Tuttavia, l'invio delle credenziali su una sessione HTTPS utilizzando questo metodo non è il modo migliore. Dovresti optare per un approccio diverso.

Sì. L'intero testo di una sessione HTTPS è protetto da SSL. Ciò include la query e le intestazioni. A tale proposito, un POST e un GET sarebbero esattamente gli stessi.

Per quanto riguarda la sicurezza del tuo metodo, non c'è modo reale di dirlo senza un'ispezione adeguata.

SSL si collega prima all'host, quindi il nome host e il numero di porta vengono trasferiti come testo in chiaro. Quando l'host risponde e la sfida ha esito positivo, il client crittograferà la richiesta HTTP con l'URL effettivo (ovvero qualsiasi cosa dopo la terza barra) e la invierà al server.

Esistono diversi modi per violare questa sicurezza.

È possibile configurare un proxy per agire come un "uomo in mezzo". Fondamentalmente, il browser invia la richiesta per connettersi al server reale al proxy. Se il proxy è configurato in questo modo, si connetterà tramite SSL al server reale ma il browser continuerà a parlare con il proxy. Pertanto, se un utente malintenzionato può accedere al proxy, può vedere tutti i dati che lo attraversano in chiaro.

Le tue richieste saranno anche visibili nella cronologia del browser. Gli utenti potrebbero essere tentati di aggiungere il sito ai preferiti. Alcuni utenti hanno installato gli strumenti di sincronizzazione dei segnalibri, quindi la password potrebbe finire su deli.ci.us o in qualche altro posto.

Infine, qualcuno potrebbe aver violato il tuo computer e aver installato un registratore di tastiere o uno screen raschiatore (e molti virus di tipo Trojan Horse lo fanno). Poiché la password è visibile direttamente sullo schermo (anziché "*" nella finestra di dialogo della password), questa è un'altra falla di sicurezza.

Conclusione: quando si tratta di sicurezza, fare sempre affidamento sul sentiero battuto. C'è troppo che non sai, che non ti verrà in mente e che ti spezzerà il collo.

Sì, purché nessuno guardi da sopra le spalle al monitor.

Non sono d'accordo con l'affermazione sulla perdita [...] di referrer HTTP (un'immagine esterna nella pagina di destinazione potrebbe perdere la password) nella risposta di Slough .

HTTP 1.1 RFC afferma esplicitamente :

I client NON DOVREBBERO includere un campo di intestazione Referer in una richiesta HTTP (non sicura) se la pagina di riferimento è stata trasferita con un protocollo sicuro.

Comunque, i log del server e la cronologia del browser sono motivi più che sufficienti per non inserire dati sensibili nella stringa di query.

Sì, dal momento in cui stabilisci una connessione HTTPS tutto è sicuro. La stringa di query (GET) come POST viene inviata su SSL.

È possibile inviare la password come parametro hash MD5 con aggiunta di sale. Confrontalo sul lato server per auth.