Domanda

La mia ultima coppia di progetti ha coinvolto siti Web che vendono un prodotto / servizio e richiedono un processo di "checkout" in cui gli utenti inseriscono i dati della propria carta di credito e simili. Ovviamente abbiamo ottenuto i certificati SSL per la sicurezza, oltre a garantire tranquillità ai clienti. Tuttavia, sono un po 'all'oscuro delle sottigliezze di esso e, soprattutto, su quali parti del sito Web dovrebbero "utilizzare" il certificato.

Ad esempio, sono stato su siti Web in cui nel momento in cui colpisci la home page sei inserito in https - principalmente siti bancari - e poi ci sono siti web in cui sei inserito in https solo quando finalmente esegui il checkout. È eccessivo far funzionare https sull'intero sito Web se non si tratta di qualcosa a livello bancario? Devo solo creare la pagina di pagamento https? Qual è il successo prestazionale che sta andando fuori di testa?

È stato utile?

Soluzione

Vado personalmente con " SSL da vai a guai " ;.

Se il tuo utente non inserisce mai un numero di carta di credito, certo, nessun SSL.

Ma c'è una possibile perdita di sicurezza intrinseca dal replay dei cookie.

  1. L'utente visita il sito e riceve un cookie.
  2. L'utente naviga sul sito e aggiunge i dati al carrello (utilizzando i cookie)
  3. L'utente procede alla pagina di pagamento utilizzando i cookie.

Proprio qui c'è un problema, soprattutto se devi gestire tu stesso la negoziazione dei pagamenti.

Devi trasmettere informazioni dal dominio non sicuro al dominio sicuro e viceversa, senza garanzie di protezione.

Se fai qualcosa di stupido come condividere lo stesso cookie con non sicuro come fai con sicuro, potresti trovare alcuni browser (giustamente) semplicemente rilasciare il cookie completamente (Safari) per motivi di sicurezza , perché se qualcuno annusa quel cookie all'aperto, può forgiarlo e usarlo in modalità protetta a, degradando la tua meravigliosa sicurezza SSL a 0, e se i dettagli della Carta vengono persino memorizzati temporaneamente nella sessione, hai un pericolo perdita in attesa di accadere.

Se non puoi essere certo che il tuo software non sia soggetto a questi punti deboli, suggerirei SSL dall'inizio, quindi il loro cookie iniziale viene trasmesso in modo sicuro.

Altri suggerimenti

Se il sito è per uso pubblico, probabilmente dovresti mettere le parti pubbliche su HTTP. Questo rende le cose più facili ed efficienti per ragni e utenti occasionali. Le richieste HTTP sono molto più veloci da avviare rispetto all'HTTPS e questo è molto ovvio soprattutto sui siti con molte immagini.

I browser a volte hanno anche un criterio di cache diverso per HTTPS rispetto a HTTP.

Ma va bene inserirli in HTTPS non appena accedono o appena prima. Nel momento in cui il sito diventa personalizzato e non anonimo, può essere HTTPS da lì in poi.

È una migliore idea usare HTTPS per la pagina di accesso stessa e per qualsiasi altro modulo, in quanto fornisce l'uso del lucchetto prima che inseriscano le loro informazioni, il che li fa sentire meglio.

L'ho sempre fatto su tutto il sito Web.

Anche io userei HTTPS fino in fondo. Ciò non ha un grande impatto sulle prestazioni (poiché il browser memorizza nella cache la chiave simmetrica negoziata dopo la prima connessione) e protegge dallo sniffing.

Una volta che lo sniffing stava uscendo a causa di reti cablate completamente commutate, dove avresti dovuto lavorare molto di più per catturare il traffico di chiunque altro (al contrario delle reti che utilizzano hub), ma è sulla via del ritorno a causa delle reti wireless, che creano ancora una volta un mezzo di trasmissione che semplifica il dirottamento della sessione, a meno che il traffico non sia crittografato.

Penso che una buona regola empirica stia forzando SSL ovunque sia possibile che vengano trasmesse informazioni sensibili. Ad esempio: sono membro della Wescom Credit Union. C'è una sezione in prima pagina che mi consente di accedere al mio conto bancario online. Pertanto, la pagina principale forza SSL.

Pensala in questo modo: verranno trasmesse informazioni riservate e private? Se sì, abilitare SSL. Altrimenti dovresti stare bene.

Nella nostra organizzazione abbiamo tre classificazioni di applicazioni -

  • Basso impatto aziendale: nessuna PII, archiviazione in chiaro, trasmissione in chiaro, nessuna limitazione di accesso.
  • Impatto aziendale medio - PII non transazionali, ad es. indirizzo email. archiviazione in chiaro, SSL dal datacenter al client, testo in chiaro nel data center, accesso limitato all'archiviazione.
  • Impatto aziendale elevato: dati transazionali, ad es. SSN, carta di credito ecc. SSL all'interno e all'esterno del datacenter. Crittografato & amp; Archiviazione controllata. Applicazioni controllate.

Utilizziamo questi criteri per determinare il partizionamento dei dati e quali aspetti del sito richiedono SSL. Il calcolo di SSL viene eseguito sul server o tramite acceleratori come Netscaler. Con l'aumentare del livello delle PII, aumenta anche la complessità dell'audit e della modellizzazione delle minacce.

Come puoi immaginare, preferiamo fare applicazioni LBI.

Kent l'ha inchiodato. Voglio solo fare un breve commento - Amazon lo fa bene, penso. http per la maggior parte del sito, ma quando arriva il momento del checkout, devi effettuare nuovamente l'accesso (oneclick è un po 'diverso), probabilmente c'è un cookie diverso a quel punto. Penso che altri commenti stiano dicendo la stessa cosa, ma volevo solo fare un esempio concreto.

Generalmente ogni volta che si trasmettono dati sensibili o personali si dovrebbe utilizzare SSL - ad es. l'aggiunta di un articolo a un carrello probabilmente non richiede SSL, l'accesso con nome utente / password o l'inserimento dei dettagli CC deve essere crittografato.

C'è un aspetto negativo principale in un sito https completo e non è la velocità (va bene).

Sarà molto difficile eseguire Youtube, "Mi piace", ecc. senza l'avviso non sicuro.

Stiamo gestendo un sito Web protetto da forze complete e facciamo acquisti da due anni e questo è il più grande svantaggio. Siamo riusciti a far funzionare Youtube ora ma " Aggiungi questo " è ancora una grande sfida. E se cambiano qualcosa nel protocollo, è possibile che tutti i nostri film su Youtube siano vuoti ...

Reindirizzo sempre i miei siti su SSL solo quando è necessario che l'utente inserisca informazioni riservate. Con un carrello non appena devono compilare una pagina con i loro dati personali o i dettagli della carta di credito, li reindirizzo a una pagina SSL. Per il resto del sito probabilmente non è necessario, se stanno solo visualizzando informazioni / prodotti sul tuo sito commerciale.

SSL è piuttosto intenso dal punto di vista computazionale e non dovrebbe essere usato per trasmettere grandi quantità di dati, se possibile. Pertanto, sarebbe meglio abilitarlo nella fase di pagamento in cui l'utente avrebbe trasmesso informazioni sensibili.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top