Un certificato SSL (https) garantisce sicurezza senza che ogni pagina sia protetta da SSL?

2

Sto scrivendo un documento per la lezione e una delle cose di cui sto scrivendo è la sicurezza di Internet. So che i certificati SSL possono essere facilmente ottenuti e si suppone che crittografino i dati su pagine certificate SSL.

So che le persone hanno problemi a rendere il loro sito completamente sicuro anche con l'acquisto della certificazione SSL, quindi solo perché una pagina mostra il badge SSL o ha il protocollo https, non significa che ogni pagina su quel sito sia sicura.

Presenterò una situazione ipotetica e ripeterò la mia domanda per spero di chiarire che cosa sto chiedendo:

Supponiamo che vada su un sito Web che mostra che è protetto SSL. Faccio clic per creare un account e la nuova pagina di registrazione dell'utente mostra anche che il suo SSL è protetto. Anche la pagina di accesso è protetta da SSL e accedo al mio nuovo account. (finora tutto ha dimostrato di essere protetto SSL). Mentre esploro questo sito web (loggato) alcune delle pagine che visito NON mostrano l'emblema SSL.

La mia domanda è: se ho inserito solo informazioni che dovrebbero essere protette, su pagine con SSL .. Questo garantisce che sia effettivamente sicuro?

Inoltre. Queste informazioni rimangono al sicuro dall'amministratore? Come può un sito apparire "sicuro" ma essere esposto vulnerabilità o essere una presa in giro dei certificati SSL?

Grazie!

    
posta 20.12.2013 - 01:22
fonte

3 risposte

1

La risposta breve è che dipende dal sito.

SSL crittografa solo il traffico in transito tra un punto di partenza / endpoint e non fa presupposizioni sul fatto che i dati siano protetti all'origine o alla destinazione. Il sito che stai navigando può fare quello che vuoi con le tue informazioni, inclusa la visualizzazione di tali informazioni sensibili mentre stai navigando nel sito tramite semplice HTTP. Se i tuoi dati sensibili vengono inviati come HTTP vaniglia, naturalmente i tuoi dati sono suscettibili di grondaie e attacchi man-in-the-middle.

Inoltre, come misura di sicurezza i browser considereranno HTTP vs HTTPS come siti separati nonostante il nome del dominio. Tuttavia, i siti possono scegliere di consentire la comunicazione incrociata (condivisione delle risorse) utilizzando CORS (e JSONP). Cioè, con CORS potrebbe essere possibile per la versione HTTP del sito accedere / modificare informazioni sul sito HTTPS. Questa è una preoccupazione poiché il traffico HTTP potrebbe essere stato modificato in transito da un utente malintenzionato perché non viene inviato in modo sicuro e quindi non può essere considerato attendibile. Un utente malintenzionato potrebbe aver modificato il contenuto HTTP per fare ciò che preferisce, tra cui l'invio di dati sensibili a un altro computer.

    
risposta data 20.12.2013 - 01:28
fonte
2

"Protetto" è un termine non specifico sovraccarico.

SSL crittografa la connessione tra il server e il client nel momento in cui una connessione è aperta. Ciò significa che i dati vengono crittografati mentre sono in transito tra il client e il server. Fornisce inoltre garanzie crittografiche che il certificato utilizzato per crittografare la connessione è stato rilasciato da un'autorità di certificazione attendibile a un'entità che ha il controllo amministrativo sul nome di dominio nella barra degli indirizzi.

Cosa succede dopo che è al di fuori dell'ambito di SSL. Quindi no, una volta che hai finito di inviare le tue informazioni sicure tramite un modulo, non c'è motivo di credere che sarebbe protetto dall'amministratore.

Qualcos'altro da considerare:

Solo perché un modulo si trova su una pagina che utilizza SSL, non significa che l'invio del modulo stesso sia protetto con SSL. Il tag form html ha un attributo action che punta a un url sul server. Il valore sull'attributo action può essere impostato in 1 o 3 modi.

  1. Usa SSL se la pagina contenente sta usando ssl. Non utilizzare ssl se la pagina contenente non sta utilizzando ssl. Un attributo di azione di questo tipo assumerà la forma di action="/formprocessor"

  2. Usa sempre ssl a prescindere dalla pagina che contiene sembrerebbe action="https://example.com/formprocessor"

  3. Non utilizzare mai ssl, indipendentemente dalla pagina contanente. Questo sembrerebbe action=http://example.com/formprocessor"

risposta data 20.12.2013 - 01:40
fonte
1

Intendi garantire la sicurezza o garantire crittografia ?

Se intendi il primo, la risposta è no.

Il sito potrebbe essere ancora vulnerabile a molti attacchi come XSS , < a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29"> CSRF , SQL Injection , ecc., indipendentemente dal suo stato HTTPS.

Se intendi il secondo, allora anche la risposta è no. Anche se il modulo di accesso, la pagina che invia a ( action="https://www.example.com/dologin" ) e ogni pagina che visualizza i tuoi dettagli personali sono accessibili tramite HTTPS, se il cookie di autenticazione non ha avuto il flag sicuro impostato quindi il valore potrebbe essere trapelato su una connessione HTTP non crittografata (ad esempio se la pagina" chi siamo "ha un URL HTTP). Il token contenuto in questo cookie potrebbe essere intercettato da un Man In The Middle che potrebbe portare a Session Hijacking di terzi.

Questo sarebbe anche possibile se non ci fossero pagine solo HTTP accessibili una volta effettuato l'accesso. Se visiti un sito del forum, un utente del forum potrebbe aver pubblicato un'immagine esterna con l'URL http://www.example.com/fake_image.jpg che imporrà il tuo cookie valore da filtrare sulla connessione non criptata.

    
risposta data 23.12.2013 - 12:55
fonte

Leggi altre domande sui tag