Regole di base per la protezione SSL per un sito web

How would a secure implementations look like and where can one expect problems?

Queste regole hanno lo scopo di fornire protezione SSL, ovvero protezione contro un avversario che può intercettare e modificare i pacchetti .

sottocomponenti

You probably into mixed mode in some scenarios

Se, in una pagina HTTPS, carichi qualsiasi script o risorsa CSS in chiaro http, che annulla il vantaggio SSL (non solo riduce).

Di norma, in una pagina HTTPS, carica tutti i sottocomponenti (frame, script, stili, immagini) su HTTPS, da host affidabili .

Cookie

Un errore particolarmente sfortunato è quello di dimenticare rende tutti i cookie" sicuri ". Se si dimentica di contrassegnare tutti i cookie rilevanti per la sicurezza con questo attributo, annulla la sicurezza SSL . (Ovviamente un cookie di accesso / sessione è sensibile alla sicurezza.)

Come vuoi che il tuo sito web sia interamente su HTTPS, seleziona tutti i cookie "sicuro" .

Un problema è che anche i cookie "sicuri" possono essere sostituiti dai cookie Cookie HTTP non sicuri! Ciò che lo rende ancora peggio è che il browser non ti dirà nemmeno se il cookie proviene da HTTP o HTTPS!

Puoi presumere che un cookie sicuro non possa essere letto da un avversario. Ma non puoi presumere che un cookie inviato da un browser su HTTPS sia il cookie sicuro che hai precedentemente inviato.

Protezione SSL per tutto il sito

Fornendo contenuti su HTTPS non solo per alcune pagine "sensibili", ma per l'intero sito, addestrerai gli utenti a utilizzare il tuo sito solo su HTTPS, il che è abbastanza buono per la sicurezza.

Affinché gli utenti possano immettere un URL HTTP, eseguirai certamente un reindirizzamento HTTP da HTTP a HTTPS, in modo che l'unico traffico HTTP non crittografato sia un reindirizzamento HTTP (nel solito caso, nessun attacco, ).

Il problema qui è che se gli utenti si abituano a digitare l'URL HTTP e potrebbero non riuscire a controllare ogni volta che vengono reindirizzati correttamente al sito HTTPS corrispondente: un utente malintenzionato che può intercettare e modificare i pacchetti può modificare la richiesta HTTP reindirizzare a un altro sito HTTPS ingannevole, o semplicemente assumere che l'utente di solito non rilevi la differenza HTTP / HTTPS: questo è una buona ragione per usare HSTS .

Altri principi di sicurezza del sito web

La protezione crittografica SSL è una parte essenziale della sicurezza del sito Web, in particolare per proteggere la segretezza delle password. Ma non è la fine dei requisiti di sicurezza specifici per i siti web.

Come promemoria, alcuni altri principi di sicurezza essenziali:

Gestione sicura dei dati non attendibili

Quando si prende l'input dell'utente e lo si stampa nella pagina Web, è necessario applicare l'escape corretto per evitare le vulnerabilità XSS. Per questo, devi capire che diverse parti della pagina HTML hanno una sintassi diversa (normale HTML, valore di attributo, URL hanno sintassi completamente diverse) e quindi hanno bisogno di una diversa escaping.

Come in ogni altro programma che prende input non attendibili esterni, devi validare correttamente ogni input , e memorizzarlo e stamparlo in un modo che non si comporta male se è presente un carattere insolito (vedi: SQL injection ).

Verifica dell'autorizzazione sul Web

Non puoi fare affidamento solo sui cookie (o sull'autenticazione HTTP) per convalidare che un ordine specifico da un client HTTP sia autorizzato: così facendo esporresti il tuo sito Web a un attacco CSS da un altro sito web se l'utente naviga su entrambi i siti web nello stesso browser .

La mia vista su design sicuro

Il problema con la sicurezza del sito Web è spesso causato dalla mancata comprensione dei diversi requisiti specifici di questi protocolli web o dalla protezione di tutti i "punti di ingresso" tranne uno.

Prima ancora di progettare un sito web "sicuro", è necessario comprendere tutti questi requisiti; allora dovresti applicarli in modo sistematico. Il tuo progetto dovrebbe essere semplice, regolare, comprensibile e facile da controllare.

Lo stile migliore è quello in cui non puoi dimenticare di applicare il testo di escape che verrà interpretato come attributo HTML / HTML / SQL "SQL regexp" / comandi shell / shell regexp. L'approccio migliore, quando possibile, è quello di impedire che i dati variabili non siano interpretati come attributo HTML / HTML / SQL / SQL "jolly expr" / comandi di shell / regexp di shell da visualizzare in tale contesto che richiede l'escape: evitare il bisogno scappare è più sicuro perché non puoi dimenticare di sfuggire alle cose.

So che mi sto allontanando da questo argomento ... quindi mi fermerò ora. Volevo solo chiarire che la sicurezza HTTP non si ferma a "100% su SSL".

fammi provare a rispondere per te:

1. Non utilizzare la modalità mista. Disballa completamente la porta 80 (o configura la porta 80, quindi inoltra link e link per link , nient'altro; per qualsiasi altra richiesta, mostra un 404
2. Ora preferisci l'usabilità e il page rank sulla sicurezza. potresti volerlo pensare
3. semplicemente non ospitare nulla sulla porta 80, la porta 443 dovrebbe ospitare l'app, non la porta 80

MODIFICA 1: Sembra un dato di fatto che la maggior parte delle applicazioni sia progettata senza alcuna sicurezza in mente (o che voglia ridurre i costi e pianificare di aggiungere la sicurezza in seguito). Poi succede qualcosa di terribile e i responsabili delle decisioni iniziano a urlare: "Vogliamo SICUREZZA, ORA, ma non vogliamo rovinare i nostri clienti con messaggi di errore". Bene, questo non accadrà, se vuoi provare a rendere il tuo sistema il più sicuro possibile.

Guardare qui intorno su IT Security, ci sono molti argomenti relativi al passaggio da HTTP a HTTPS, perché non pensare alla sola modalità HTTPS fin dall'inizio? In realtà è divertente: già le prime versioni di IE e Netscape Navigator avvisano gli utenti del pericolo di inviare POSTS alle pagine HTTP. Tutti i browser funzionano ancora con la piccola casella spuntata che diceva "Non disturbarmi più su di esso!".