I siti di reindirizzamento devono utilizzare HTTPS

Se il sito principale utilizza HTTPS, anche il sito di reindirizzamento dovrebbe.

Quali attacchi sono possibili se non

Passive Attacker

• Può vedere ogni oggetto guardato dall'utente
• Può ottenere informazioni aggiuntive (quale sito / chat è collegato alla pagina)

Attaccante attivo

Tutto ciò che può fare un attaccante passivo e ...

• Può MITM la connessione e utilizzare qualcosa come SSLStrip per impedire l'aggiornamento della connessione a HTTPS, permettendo quindi di guardare password, numeri di carte di credito, ecc.
• Può aggiungere un cookie alla risposta, consentendo loro di tracciare un utente
• Può reindirizzare il traffico verso un sito di phishing o un sito che installa malware.

Come impedire completamente l'utilizzo di HTTP, per arrestare strumenti come SSLStrip

• Puoi pubblicare un'intestazione HSTS, quindi solo la prima visita (e la prima visita dopo la scadenza dell'intestazione) utilizzerà HTTP, quindi un utente malintenzionato non può intercettare il traffico
• Se vuoi evitare questi punti deboli, puoi aggiungere il tuo sito alla lista di precarico HSTS , che impedirà le connessioni HTTP.
• Ciò dovrebbe essere applicato per entrambi i siti, come se il sito principale fosse HSTS, ma il reindirizzamento potrebbe quindi essere reindirizzato a un sito che controllano, ignorando HSTS.

Devo usare HTTPS

Generalmente, SÌ

Ci sono pochissime occasioni in cui puoi fare a meno di non usare HTTPS, tutti questi devono essere applicati:

• Firmi manualmente i tuoi dati - e verifica sempre la firma

• Non ti importa delle persone che scoprono che il tuo software è in esecuzione sul computer di qualcuno

• Non gestisci informazioni sensibili o informazioni che gli utenti potrebbero voler mantenere segreti
• Non accidentalmente riceverai le informazioni sensibili inviate sul tuo sistema
  • Un esempio potrebbe essere ACARS, non è stato pensato per informazioni sensibili, ma i numeri delle carte di credito sono stati inviati su di esso senza rendersi conto dei problemi causati. [ forum , carta ]
• Non ti interessa o puoi rilevare se qualcuno scambia i file con altri firmati validi
• Il servizio non implica dati sensibili (una pagina relativa a una malattia potrebbe non essere sensibile, ma il fatto che qualcuno stia cercando la malattia può essere sensibile).

Ci sono pochissimi casi in cui l'utilizzo di un semplice HTTP e non HTTPS è una buona idea. Questo probabilmente non è uno di questi.

Considera questo scenario: un utente fa clic su un link su http://exmpl.com/foo , sperando di acquistare qualche nuovo foo. Un uomo nel mezzo intercetta la richiesta e risponde con una copia di phishing di https://example.com/items/42 anziché un reindirizzamento a quello legittimo. L'utente, essendo pigro come gli utenti, non controlla l'URL in cui è stato reindirizzato - dopo tutto, sapeva di aver fatto clic sul link giusto. Invece procede per inserire i dati della sua carta di credito nel sito di phishing. Pensa che stia facendo la spesa per un sito legittimo, mentre in realtà viene truffato.

Certo, l'utente ha commesso un errore qui. Ma è un errore che non avrebbe avuto importanza se tu avessi usato solo HTTPS.

Quando l'utente è consapevole della privacy, potrebbe voler minimizzare la quantità di dati che un intercettore può raccogliere su di loro. Quando si utilizza HTTPS, l'intera richiesta viene crittografata. L'intercettatore conosce solo il server a cui l'utente ha avuto accesso e (approssimativamente) la quantità di dati scambiati.

Quando exmpl.com non usa HTTPS, l'intercettore sa:

• Oggetto con accesso http://exmpl.com/foo
• Oggetto ricevuto un http-reindirizzato a https://example.com/items/42
• Oggetto a cui è stato effettuato l'accesso a un URL sconosciuto (ma ora facile da inferire) sul dominio example.com
• Oggetto ricevuto una risposta crittografata lunga

Quando usi HTTPS, tutto l'hacker sa:

• Oggetto a cui è stato effettuato l'accesso a un URL sconosciuto nel dominio exmpl.com
• Oggetto ricevuto una risposta criptata breve
• Oggetto a cui è stato effettuato l'accesso a un URL sconosciuto nel dominio example.com
• Oggetto ricevuto una risposta crittografata lunga

L'utente malintenzionato non apprende quale reindirizzamento viene utilizzato dall'utente e quindi non apprende che l'utente ha visitato items/42 . Anche l'attaccante non può essere sicuro che questi due accessi siano correlati.