Collegamento da una pagina Http a una pagina Https - si tratta di un problema di sicurezza?

5

Ho un sito che per lo più non è un qualcosa che deve essere protetto. Tuttavia c'è una piccola parte del sito che è solo per gli utenti registrati.

Quindi il mio sito normale è Http & il sito degli utenti registrati è tramite Https.

Sul mio normale sito Http - ho un link alla pagina di accesso https per quegli utenti che hanno bisogno di accedere a quel contenuto.

Mi chiedevo se si tratta di un problema di sicurezza, ad esempio un collegamento da una pagina HTTP a una pagina HTTPS?

L'unico attacco a cui riesco a pensare è se c'è un tipo di Uomo nell'attacco intermedio in cui qualcuno modifica il mio link in modo che punti a un sito falso con un URL simile al mio.

Questa è una preoccupazione? Come posso mitigarlo? È l'unico modo per trasformare il mio sito normale anche in https?

EDIT: la mia domanda non è un duplicato dell'altra domanda - l'altra domanda chiede di passare al login del post http. La mia domanda è completamente diversa: si tratta di 2 diverse parti dello stesso sito, una delle quali richiede accesso e una che è pubblicamente accessibile. Ti sto chiedendo se è ok mantenere la prima parte https (sia per login che per postare l'accesso) e mantenere l'altra parte http.

    
posta user93353 18.08.2016 - 11:12
fonte

3 risposte

6

Sì, non è sicuro.

Il modo più semplice per attaccare è sslstrip, uno strumento che esegue un MitM e sostituisce automaticamente i link https con quelli http.

L'unico modo sicuro per farlo correttamente è avere https su tutto il sito web e attivare HSTS.

Nota che anche per gli utenti non loggati https è utile, ad esempio per impedire a terze parti (come ISP) di inserire annunci nei tuoi siti web senza il tuo consenso.

    
risposta data 18.08.2016 - 11:29
fonte
2

La minaccia principale è un attacco Man-In-The-Middle qui.

Qualsiasi utente che naviga da http://example.com a https://example.com/secure/login potrebbe essere sslstrip 'o potrebbe essere reindirizzato a un phishing dominio - https://example.org .

Questo significa anche che l'HSTS non può essere usato per mitigare sslstrip. L'HSTS garantirà che una volta che un browser si è connesso tramite HTTPS, non potrà mai stabilire una semplice connessione HTTP a quel dominio fino alla scadenza della politica. Nota che per "quel dominio" intendo sia il tuo dominio attuale, sia un dominio controllato da MITM che finge di essere la versione HTTP del tuo sito.

Se i tuoi contenuti protetti si trovano nello stesso dominio dei tuoi contenuti non sicuri, significa che anche se stai impostando il flag di sicurezza su tutti i cookie sensibili, i cookie potrebbero comunque essere avvelenati da un MITM. Ad esempio, in un attacco di fissazione di sessione, un attacco a CSRF esegue il doppio controllo dei cookie di invio o nel caso in cui si stia utilizzando un cookie per visualizzare il contenuto non elaborato sulla pagina, potrebbe essere possibile un attacco XSS. Ciò è dovuto al fatto che un cookie impostato su http://example.com e https://example.com avrà lo stesso aspetto sul server, poiché il flag di sicurezza non viene inviato in ciascuna richiesta HTTP affinché il server li differenzi.

Suggerirei di utilizzare HTTPS in tutto il sito e implementare una politica HSTS con il precaricamento.

    
risposta data 19.08.2016 - 11:41
fonte
0

Poiché il tuo sito può essere consultato in modalità http, presumo che non contenga contenuti altamente sensibili. La scelta tra HTTP e HTTPS è una questione di scambio di sicurezza per le prestazioni:

  • tutto ciò che può essere fatto in HTTP può essere fatto in HTTPS e ottieni una maggiore sicurezza
  • HTTPS consuma più risorse

Come regola generale, utilizza HTTPS se offri abbastanza risorse e HTTP se il valore dei dati è basso.

Può essere ammesso combinare HTTP per pagine normali e HTTPS per pagine sensibili come lo scambio di credenziali fornito:

  • il server rifiuterà qualsiasi richiesta HTTP a una pagina sicura = > se una pagina contenente collegamenti HTTPS viene riscritta con collegamenti HTTP, otterrai un reindirizzamento alla pagina HTTPS o un errore
  • la sicurezza generale del sito è a livello HTTP
  • sei sicuro che i tuoi utenti controllino che le pagine sensibili provengano dal tuo sito

Ciò che devi sapere è che non appena la sessione utilizza un cookie non protetto (modalità HTTP) non devi essere sicuro di quella sessione per accedere alle informazioni riservate.

Quindi questo è corretto: consultazione HTTP = > link a HTTPS per login = > nuova sessione dopo l'accesso = > Consultazione HTTP: la sicurezza complessiva è di basso livello perché il cookie di sessione non è sicuro e si proteggono solo le credenziali

Ma questo non va bene: login HTTPS = > Consultazione HTTP di pagine non sensibili = > Consultazione HTTPS / modifica di dati sensibili

perché qui il livello di sicurezza della sessione è caduto su HTTP e viene ancora utilizzato per operazioni sensibili.

Il minimo dovrebbe essere:

... = > Operazioni HTTP = > Controllo HTTPS delle credenziali o di un cookie sicuro = > nuova sessione = > Operazioni HTTPS ...

Il più grande rischio qui è che dovresti istruire i tuoi utenti che la pagina di accesso è speciale e che dovrebbero controllare che il piccolo lucchetto sia presente e l'url sia nel dominio corretto. Il rischio è qui:

  • un utente malintenzionato è riuscito a ottenere una copia della pagina di accesso
  • riesce a inviare uno dei tuoi utenti a una pagina che controlla
  • l'utente scrive le sue credenziali

= > l'utente malintenzionato ha ottenuto tutti gli accessi consentiti all'utente

TL / DR: avere solo una parte del sito (inclusa la pagina di accesso) in HTTPS è accettabile solo se:

  • la pagina di accesso è accessibile solo in HTTPS e crea una nuova sessione
  • qualsiasi transizione da HTTP a HTTPS richiede un controllo delle credenziali (o di uno speciale cookie sicuro)
  • tutti i tuoi utenti controllano che l'URL della pagina di accesso sia corretto prima di inserire le loro credenziali
risposta data 19.08.2016 - 14:17
fonte

Leggi altre domande sui tag