2009-04-03 9 views
11

Ho un sito Web (www.mydomain.com) protetto da un certificato SSL. È un sito Web ASP.NET e ho obbligato alcune pagine tramite codice a richiedere il prefisso https: //. Se non lo fanno, li reindirizzerà a https: // equivalenti. È una buona pratica? C'è un modo più semplice per farlo? Non ogni singola pagina richiede SSL.Migliori pratiche del sito Web SSL-protected

Inoltre, quando gli utenti utilizzano il mio URL sotto forma di mydomain.com anziché www.mydomain.com ricevono un errore di certificato perché il certificato è stato registrato per www.mydomain.com. Devo utilizzare lo stesso approccio con il problema http: // e https: // che ho menzionato sopra? O c'è un modo migliore di gestirlo?

risposta

2

Il tuo approccio suona bene. Nel mio progetto attuale, impongo HTTPS quando un utente accede alla mia pagina di accesso, (Basato su un flag di configurazione che consente di eseguire test localmente senza occuparmi di richiedere un certificato). Questo mi permette di accedere ad altre pagine non protette che è a portata di mano.

Ho un paio di posizioni in cui il nostro server cattura l'output di altre pagine (il rendering in html in PDF e il recupero di immagini dinamiche, ad esempio). A causa del nostro ambiente, il nostro server non può risolvere il suo nome pubblico, quindi se dovessimo forzare ssl nel sito dovremmo aggiungere, il nostro indirizzo IP interno (o il nome del dominio falso).

Per quanto riguarda la seconda domanda, sono disponibili due opzioni per gestire www.example.com vs example.com. È possibile acquistare un certificato che consente di avere più nomi di dominio. Questi sono noti come certificati UCC.

La seconda opzione è quella di reindirizzare example.com a www.example.com o viceversa. Il reindirizzamento è un'ottima opzione se desideri che i tuoi contenuti vengano indicizzati da Google o da altri motori di ricerca. Dal momento che vedranno www.example.com e example.com come due siti separati. Ciò significa che i collegamenti ai tuoi siti verranno suddivisi riducendo il ranking generale della pagina.

+0

Sì, prendo lo stesso approccio. Ho una chiave EnableSsl nel mio file web.config che posso spegnere e accendere a seconda dell'ambiente in cui mi trovo. Ho anche una chiave SecurePages delimitata da pipe che posso facilmente aggiungere/rimuovere. –

+0

Un altro modo invece di delimitare Pipe (supponendo che non è necessario modificare questo dopo la distribuzione) sarebbe quello di definire una pagina di base che esegue il controllo, quindi qualsiasi pagina che si desidera garantire sicuro erediterà sempre da quella pagina. Potresti anche usare gli attributi. – JoshBerke

+0

Sì, ma preferirei mantenere un'unica pagina base e mi piacerebbe poter impostare dinamicamente le pagine su ssl o no senza ricompilare. –

1

È possibile configurare siti in IIS per richiedere un certificato, ma A) genera un errore se qualcuno non visita con https e B) richiede a tutte le pagine di utilizzare https. Quindi, che non funzionerà. È possibile inserire un filtro su IIS che verifica tutte le richieste e le reindirizza come chiamate https se si trovano nell'elenco di crittografia. Lo svantaggio ovvio qui è la necessità di aggiornare l'elenco di pagine ogni volta che viene aggiunta una nuova pagina (ad esempio da un file o database XML) e riavviare il filtro.

Penso che tu sia probabilmente corretto nella creazione di codice nelle pagine che richiedono https che reindirizzano a una versione https se arrivano via http. Per quanto riguarda l'errore cert, è possibile reindirizzare con un percorso completo (che include www) anziché un percorso relativo per risolvere questo problema. Se avete domande su come rilevare se la chiamata utilizza https OPPURE come ottenere il percorso completo della richiesta corrente, fatemelo sapere. Entrambi sono abbastanza semplici ma ho codice di esempio se ne hai bisogno.

UPDATE - Josh, i certificati che gestiscono più sottodomini sono chiamati caratteri jolly. Il problema è che sono un po 'più costosi di quelli standard.

UPDATE 2: Un'altra cosa da considerare è l'utilizzo di una pagina master o di una classe derivata per le pagine che richiedono SSL. In questo modo, invece di duplicare il codice in ogni pagina, puoi semplicemente dichiararlo come tipo SSLPage (o usare la pagina Master corrispondente) e far gestire al reindirizzatore la classe Master/Parent. Ancora una volta, dovrai eseguire qualche elaborazione URL se segui questo approccio, ma è piuttosto banale.

+0

Grazie per l'input. Sto già rilevando http: // e https: //, quindi non sarà un problema. Dovrò giocare con il controllo di www. perché l'URL non lo avrà sul mio computer di sviluppo. Qualche consiglio? –

+0

Mark ora sono chiamati certificati UCC. I caratteri jolly sono diversi. Un UCC di Godaddy in grado di supportare 5 domini è $ 89 all'anno. – JoshBerke

+0

Mike: Aggiungi la voce www.localhost al tuo file hosts. Questo ti permetterà di testare il tuo www. logica :-) – JoshBerke

-1

seguito è qualcosa che può aiutare a:

  • Se va bene per visualizzare tutte le pagine del sito web con https: // allora si può semplicemente aggiornare il codice per utilizzare https: // e impostare due attacchi in IIS. Uno è per http e un altro è per https. In questo modo, il tuo sito web può essere accessibile attraverso qualsiasi protocollo.
  • I visitatori ricevono un errore di mancata corrispondenza del nome perché il nome comune utilizzato nel certificato SSL è www.mydomain.com. Namecheap fornisce i certificati RapidSSL tramite i quali è possibile proteggere entrambi i nomi con SSL singolo. Puoi acquistare questo SSL per www.mydomain.com e proteggerà automaticamente mydomain.com (cioè senza www).

Un'altra opzione è che è possibile scrivere un codice per reindirizzare i visitatori sul sito Web www.mydomain.com anche se navigano su mydomain.com.