Guida per implementatori di siti solo HTTPS (lato server)

I principali sono:

• Utilizza SSL in tutto il sito. Non offrire nulla su http. Invece, qualsiasi connessione tramite http dovrebbe immediatamente reindirizzare alla pagina di destinazione del sito principale tramite https.

• Utilizza la sicurezza del trasporto rigorosa HTTPS. Questo dirà ai browser degli utenti: ti preghiamo di connetterti a me solo tramite https. Questo difende da sslstrip e simili attacchi man-in-the-middle.

• Imposta il flag di sicurezza su tutti i cookie. Ciò garantirà che i cookie vengano inviati solo tramite un canale https, mai su un collegamento http non sicuro.

• Evita contenuti attivi di terze parti pubblicati su http. Non caricare contenuti attivi esterni su http. Assicurati che qualsiasi CSS, Javascript, widget, analisi o annunci caricati da fonti di terze parti vengano caricati su https.

  • Potenzialmente ancora meglio, puoi prendere in considerazione l'idea di creare la tua copia e servire queste risorse dal tuo server, se possibile, quindi non devi caricarle da una fonte di terze parti. In molti casi puoi evitare di caricare CSS, librerie Javascript o widget da fonti di terze parti semplicemente memorizzandone una copia sul tuo server.

  • Per l'analisi, tieni presente che Google Analytics supporta https.

  • Gli annunci sono la parte più difficile. Se si utilizzano gli annunci, è possibile che non si abbia altra scelta che accettare annunci di terze parti su http, il che rappresenta un rischio per la sicurezza. Se lo fai, pubblica gli annunci in un iframe (non utilizzare SCRIPT SRC per integrare gli annunci nella tua pagina).

  Va bene caricare immagini ospitate su un host di terze parti purché siano caricate su HTTPS (per evitare avvisi di contenuto misto).

Penso che se fai queste quattro cose, coprirai la maggior parte dei problemi. Il resto sono dettagli che possono essere valutati in base al sito, ma probabilmente hanno un'importanza secondaria (secondo me).

Se vuoi essere attraente, puoi guardare il pinning dei certificati e una tecnologia emergente simile, ma partire da questi quattro è già un progetto abbastanza significativo.

Sicurezza dell'utente

• Ti manca una cosa estremamente importante : mitigazione CSRF.

  Assicurati di comprendere appieno i problemi correlati. Tldr: in addition al token di autorizzazione (es. Cookie di sessione), è necessario un challenge per per identificare se l'azione è destinata all'utente o non intenzionale.

• Correzione perdite JSONP .

• X-Content-Type-Options: nosniff , su tutte le pagine per impedire lo sniffing di MIME, specialmente per le pagine generate dagli utenti.

• Norme sulla sicurezza dei contenuti .

• Assicurati che il meccanismo di "reimpostazione della password" protetto impedisca alle persone di reimpostare la password di altre persone e ottenere fraudolenti l'accesso.

• Mostra un avviso enorme enorme quando gli utenti utilizzano password deboli o non lo accettano del tutto.

• Fai allenare gli utenti (magari tramite un'immagine della freccia su ogni pagina che punta alla barra verde) per verificare se le tue pagine sono caricate con HTTPS. Se usano mai un browser che non supporta HSTS, almeno noterebbero che manca HTTPS.

Sicurezza del server / utente

• Assicurati che i segreti non siano trapelati a causa di tempistiche attacks .

Privacy dell'utente

• L'applicazione del riempimento a solo ajax è insufficiente. Per proteggere i tuoi utenti dal monitoraggio della rete , tutte le richieste e le risposte devono essere dati imbottito. Le richieste non devono essere riempite nel tempo, ma le risposte devono.

• Correzione della cronologia delle perdite a causa di variazione dei tempi per le risposte :

  Suppose that Alice is surfing the Web, and she visits Bob’s Web site at http://www.bob.com. Bob wants to find out whether Alice has visited Charlie’s Web site (http://www.charlie. com).

  First, Bob looks at Charlie’s site, and picks a file that any visitor to the site will have seen. Let’s say Bob picks the file containing Charlie’s corporate logo, at http://www.charlie.com/ logo.jpg. Bob is going to determine whether the logo file is in Alice’s Web cache. If the file is in her cache, then she must have visited Charlie’s Web site recently.

  Bob writes a Java applet that implements his attack, and embeds it in his home page. When Alice views the attack page, the Java applet is automatically downloaded and run in Alice’s browser. The applet measures the time required to access http://www. charlie.com/logo.jpg on Alice’s machine, and reports this time back to Bob. If the time is less than some threshold (say, 80 milliseconds), Bob concludes that Alice has been to Charlie’s site recently; if it is greater than the threshold, he concludes that she has not been to the site recently.

Privacy del server

• Garantisci l'invulnerabilità agli attacchi invii di clock .

Disponibilità

• Limitazione basata su utente / IP in caso di DoS e DDoS .

Altre cose miscche che non puoi correggere (problemi con il browser):

• Cronologia che perde tramite HSTS