2010-07-15 18 views
14

Questo sarà un po 'difficile da spiegare ma farò del mio meglio.

C'è un sito web che ha il modulo di accesso su ogni pagina con campi username/password. Queste pagine non stanno usando SSL. Dopo che l'utente compila il nome utente/password e invia il modulo, il modulo viene inviato a una pagina di autenticazione che è https.Dopo l'accesso, tutte le pagine dovrebbero essere https?

Ho alcune domande su questa situazione.

  1. Quando si invia un modulo a una pagina https, i dati sono crittografati? O solo dopo essere passato da una pagina https (presumo solo di andare da)?
  2. Se la risposta al numero uno è la ladder, significa che dovrei usare https per tutte le pagine perché il modulo di login viene reindirizzato da lì?
  3. Dopo che un utente è stato autenticato tramite https, l'utente può essere reindirizzato a http e continuare a utilizzare i dati di sessione? O l'utente dovrebbe rimanere in https?
  4. È meglio/peggio lasciare l'utente in https?

Grazie mille per qualsiasi aiuto!
Metropolis

CONCLUSIONE

Ok, quindi dopo pensare a questo per un po 'ho deciso di fare solo il tutto https. @ Mathew + @Rook, le tue risposte sono state entrambe fantastiche e penso che entrambi punti importanti. Se fossi in una situazione diversa potrei averlo fatto in modo diverso, ma qui ci sono le mie ragioni per fare l'intera cosa a https.

  1. Sarà più facile controllare le richieste di pagina, poiché devo solo rimanere in https.
  2. Im non eccessivamente preoccupati con la performace (in un'altra situazione io sia stato)
  3. Non avrò bisogno di chiedersi se i dati degli utenti è in corso garantiti in tutti i luoghi
  4. sarò seguendo la linea guida OWASP come Rook ha dichiarato

risposta

10

In base a The OWASP top 10 non è possibile utilizzare un id di sessione autenticato su HTTP. Quindi crei una sessione su HTTP e poi quella sessione viene autenticata, quindi hai violato The OWASP Top 10 e stai permettendo agli utenti di essere suscettibili agli attacchi.

Si consiglia di impostare secure flag on your cookie. Questo è un nome terribile per questa funzione, ma obbliga i cookie solo a https. Questo non dovrebbe essere confuso con "Httponly cookies", che è un flag diverso che è utile per mitigare l'impatto di xss.

Per assicurarsi che gli utenti siano al sicuro, imporrei l'uso di HTTPS tutto il tempo. ssl è un protocollo molto leggero, se si incontrano problemi con le risorse, quindi considerare di concatenare le politiche https.

+0

Perché questo sito utilizzando HTTP per tutto il tempo, allora, tranne durante l'accesso a? Dovrei supporre che stiano usando le sessioni? – Metropolis

+0

Sì, come ho detto è un trade-off. È possibile intercettare e rubare un cookie di sessione StackOverflow. Decisero che erano disposti a rischiare quella possibilità. –

+0

@Metropolis perché si tratta di una violazione molto comune di owasp. Inoltre SO non è sicura al 100% (http://meta.stackexchange.com/questions/46671/captcha-bypass) – rook

6
  1. Sì. Se l'URL dell'azione è https, i dati del modulo vengono crittografati.
  2. A causa del numero 1 non è necessario impostare la pagina https, ma è possibile che vengano visualizzati avvisi di contenuto misto. E, naturalmente, un aggressore man-in-the-middle potrebbe manipolare la pagina di accesso per puntare a un altro URL di azione.
  3. Questa è una decisione da prendere. Chiaramente, tutti i dati trasmessi su HTTP, se i cookie (compresi i cookie di sessione) oi dati dell'utente, possono essere intercettati e manipolati.
  4. Ancora una volta, questo è un compromesso basato su prestazioni e sicurezza.
+0

# 3 è una violazione di owasp. Dovrei darti un -1 per quello. – rook

+3

@The Rook, non ho mai detto che sarebbe OWASP compatibile in entrambi i modi. Ho * fatto * che l'HTTP consentiva alle persone di intercettare e manipolare i dati della sessione. –

+0

Sì, non penso che tu stia conducendo le persone fuori strada. – rook

3

In aggiunta a ciò che dice la torre, la presentazione di una forma da http a https è un rischio per un paio di motivi:

  1. Non v'è alcuna icona "lucchetto" nella pagina in cui la gente scrive dentro il loro nome utente e password, quindi non hanno modo di sapere che i loro dati sono crittografati (se non per "fidarsi di te")
  2. Se qualcuno dirottato la tua pagina, gli utenti non avrebbero modo di sapere che stanno per digitare il loro nome utente e password e essere reindirizzati a una pagina malevola (questo è un po 'un corollario del # 1).

questo è un attacco molto più semplice che http cookie di intercettazione, quindi è in realtà un rischio ancora più grande ...

Ma il punto del Rook è importante: si dovrebbe mai mix traffico HTTP e HTTPS. Sui nostri siti web, non appena si è registrato in, tutto è https da quel punto in poi.

2

Oltre alle risposte precedenti, poiché le persone tendono a voler passare da HTTPS a HTTP per motivi di prestazioni, potrebbe essere di interesse il numero this article about HTTPS at Google. Il suo messaggio principale è:

SSL/TLS non è computazionalmente costoso più.

+0

Il link è per imperialviolet.org non per Google come mi aspettavo da "su Google" e il link è rotto. –

+0

@Stephen P, sì, sfortunatamente il collegamento è attualmente inattivo. Se cerchi il link, dovresti riuscire a trovare l'articolo nella cache. Anche se è difficile verificarlo, parlano di "[loro] lavoro su Google". L'articolo inizia con "(Questa è una scrittura up del discorso che ho dato al [Velocity 2010] (http://conferences.oreilly.com/velocity) Giovedi scorso. Si tratta di un lavoro congiunto di me stesso, Nagendra Modadugu e Wan -Teh Chang.) ", Vedi http://it.oreilly.com/velocity2010/public/schedule/detail/14217 – Bruno

Problemi correlati