it-swarm.dev

Come garantire che i cookie vengano sempre inviati tramite SSL quando si utilizza ASP.NET su IIS 7.5?

Firesheep ha portato in primo piano il problema degli scambi di cookie non sicuri.

Come è possibile garantire che tutti gli scambi di cookie siano forzati a verificarsi solo tramite una connessione protetta SSL al server quando si comunica a un utente Web?

Il nostro scenario è che l'app Web sia scritta in ASP.NET 4.0 e ospitata su Windows Server 2008 R2 con IIS 7.5 se questo restringe l'ambito in qualche modo.

23
cpuguru

Puoi usare app.config per forzarlo; il formato è (nel <system.web> sezione)

<httpCookies domain="String"
             httpOnlyCookies="true|false" 
             requireSSL="true|false" />

quindi vuoi davvero, come minimo

<httpCookies requireSSL='true'/>

Ma preferibilmente attiverai anche httpOnlyCookies, a meno che tu non stia facendo un po 'di javascript davvero appassionato.

21
blowdart

Il modo più sicuro per proteggere il tuo sito da Firesheep (e dagli attacchi correlati):

  • Passa alla protezione SSL dell'intero sito : sposta l'intero sito su HTTPS e disabilita tutto l'accesso HTTP. In altre parole, proteggi l'intero sito con SSL. Ecco alcune risorse in più per farlo: come proteggere contro Firesheep , pro e contro del SSL a livello di sito , perché SSL protegge contro Firesheep .

  • Imposta il flag SICURO su tutti i cookie : Ogni volta che il server imposta un cookie, provvedi a impostare il flag SICURO sul cookie. Il flag SECURE indica al browser dell'utente di rispedire questo cookie solo tramite connessioni SSL-secure (HTTPS); il browser non invierà mai un cookie SICURO su una connessione non crittografata (HTTP). Il passaggio più semplice è impostare questo flag su ogni cookie utilizzato dal tuo sito.

Inoltre, raccomando alcuni passaggi aggiuntivi:

  • Fai attenzione ai contenuti di terze parti : i widget, le librerie e i contenuti di terze parti possono rappresentare un rischio per la sicurezza. Se includi Javascript di terze parti (ad es. Tramite <SCRIPT SRC=...>), Ti consiglio di assicurarti che facciano riferimento agli URL HTTPS; in caso contrario, stai esponendo la sicurezza del tuo sito ad attacchi attivi. (Vedi anche Jeremiah Grossman's FAQ sui widget di terze parti .) Per evitare di inondare i tuoi utenti con avvisi a contenuto misto , desidera garantire che tutto il contenuto, comprese le immagini e le librerie di terze parti, venga fornito anche tramite HTTPS.

Alcuni potrebbero sostenere che quanto sopra è eccessivo. In alcuni casi, potrebbe essere possibile proteggere contro Firesheep utilizzando SSL solo su una parte del sito. Tuttavia, ciò richiede cura e conoscenza dettagliata ed è più difficile ottenere il risultato giusto. Dato che devi porre la domanda qui, ti consiglio personalmente di iniziare con SSL a livello di sito; hai maggiori possibilità di farlo bene.

Come implementarlo in IIS : Non sono un esperto IIS, quindi non posso darti una ricetta definitiva su come implementare questi passaggi in IIS. Tuttavia, questo riferimento su abilitazione SSL su IIS può esserti utile. Sembra che puoi fare clic con il tasto destro del mouse sulla radice del sito, scegliere Properties , fai clic sulla scheda Directory Security, quindi in Secure Communications, fai clic su Edit e abilita Require Secure Channel (SSL). Non so come configurare IIS per impostare automaticamente il flag SICURO su tutti i cookie. Per la migrazione di un sito esistente, ti consiglio di impostare un reindirizzamento in modo che chiunque visiti una pagina HTTP venga reindirizzato a HTTPS. I seguenti riferimenti potrebbero essere di aiuto ( non testato): reindirizzamento a HTTPS , tre metodi per il reindirizzamento a HTTPS . Se si esegue la migrazione di un sito esistente, sarà necessario modificare tutti i collegamenti e i riferimenti al proprio sito da http: URL su https: URL. Non sono sicuro su come configurare ASP.NET per impostare il flag SICURO su tutti i cookie, ma penso che tu possa aggiungere cookieRequireSSL="true" O <httpCookies requireSSL="true"> Al tuo Web.config; questo è importante da fare, e particolarmente importante se hai abilitato HTTP o se hai qualche tipo di reindirizzamento dalle pagine HTTP alle pagine HTTPS. Infine, c'è molto materiale pubblicato su tuning delle prestazioni per HTTPS .

18
D.W.

Mi sono imbattuto in questo thread durante la risoluzione del problema. La risoluzione che ho avuto è che i percorsi dei cookie fanno distinzione tra maiuscole e minuscole. Ecco la domanda correlata.

https://stackoverflow.com/questions/399982/why-are-cookie-paths-case-sensitive

La mia risoluzione era quella di reindirizzare dalla pagina di destinazione al percorso corretto. Assicurati di cercare possibili loop di reindirizzamento.

url.com/VirtualDirectory/default.aspx ->

// che ora fornirà il percorso corretto url.com/virtualdirectory/default.aspx response.redirect ("~/default.aspx");

1
MichaelChan