2011-07-06 12 views
19

Sto tentando di attivare la crittografia viewstate Sempre come misura di sicurezza per il mio sito Web ASP.NET 3.5 ospitato in IIS6. Abbiamo disattivato lo stato di visualizzazione, ma vediamo ancora alcuni "stati di controllo" in questa stringa. In un ambiente di test sono in grado di impostare semplicemente il seguente nel file web.config e posso base64 non più decodificare il ViewState di semi-testo in chiaro:asp.net viewstate encryption issue

<pages enableViewState="false" enableViewStateMac="true" viewStateEncryptionMode="Always">

Ho anche aggiunto il seguente (genereated da machine key generater) a machine.config e cifra ancora la multa viewState sul mio server di prova:

<machineKey validationKey="002..." decryptionKey="D90E..." validation="SHA1" decryption="AES" />

mio ambiente non-test non sembra raccogliere i cambiamenti di cui sopra come posso decodificare sempre Base64 il viewState in testo normale con le impostazioni di cui sopra. Io sempre iisreset dopo aver apportato eventuali modifiche.

Alcune informazioni circa il mio non-test server web:

  • Web Farm/carico equilibrato (ma un solo server per il test in questo momento)
  • Sql stato sessione (machineKey in machine.config è stato inizialmente necessario impostare questa funzione)
  • machine.config: distribuzione al dettaglio = "true"

qualcuno può suggerire dove cercare ulteriori impostazioni che potrebbero interferire con la crittografia asp.net viewstate?

EDIT: Ora sul mio server di prova iis non è possibile annullare l'impostazione viewStateEncryptionMode in quanto sta crittografando il viewstate anche quando l'ho impostato su "Mai" e nessuno dei miei altri siti Web sembra prendere in considerazione questa impostazione. Dove posso cercare di vedere dove questa proprietà viene sovrascritta? C'è qualche cache in cui è memorizzata questa impostazione che deve essere cancellata oltre a ciò che verrebbe fatto quando iiisreset/stop www service/touch machine.config?

FINALE DI EDIT: Dopo giorni di studio dei file di configurazione ho rinunciato e l'ho implementato tramite codice. Ho già un modulo di sicurezza che si collegava agli eventi della pagina, quindi in Page_Load ho aggiunto: Page.RegisterRequiresViewStateEncryption();

Mi piacerebbe davvero sapere cosa impediva l'impostazione di questa impostazione su IIS6 immediatamente. Quando eseguo cassini localmente se imposto viewStateEncryptionMode su "Always" tramite il nodo delle pagine, vedrei immediatamente che codifica il viewstate e renderizza il campo nascosto aggiuntivo con id = "__ VIEWSTATEENCRYPTED". Quando poi l'ho impostato su "Never", vedrei immediatamente la disattivazione della crittografia. Se faccio la stessa identica modifica al sito web sul mio sito web ospitato da IIS6, non avrebbe alcun effetto immediato, ma se permetto che l'impostazione rimanga lì, alla fine prenderà piede. Vorrei interrompere/avviare il servizio www, ripristinare iis, cancellare la cache temporanea ASPNET ma non so cos'altro provare? Speriamo che questo post possa ROT per un po 'e qualcuno in futuro vedrà lo stesso comportamento che ho vissuto e possiamo ulteriormente capire questo!

+5

Si scopre che RegisterRequiresViewStateEncryption attiva anche la convalida ViewstateMAC anche se ho impostato esplicitamente su false nel mio web.config. Poiché il mio sito è un "MVC" personalizzato che si trova in cima a WebForms in cui reindirizzo a pagine diverse a volte su POSTI non posso avere la convalida MAC. Sto pensando che le mie impostazioni web.config di ViewStateMAC = false e ViewStateEncryption = true non erano una buona combinazione. – felickz

risposta

2

So che è passato un po 'di tempo da quando l'hai postato, ma hai pensato di realizzare la tua implementazione di PageStatePersister? PageStatePersister è il componente responsabile della formattazione dei dati ViewState e ControlState incorporati nella pagina. Se la sicurezza è la tua preoccupazione principale, puoi utilizzare qualsiasi algoritmo di crittografia che desideri per garantire che i tuoi dati rimangano privati. In base alla configurazione, sembra che tu sia in un ambiente piuttosto capace, quindi ovviamente prima esegui il test di carico.Vale anche la pena ricordare che non ho idea riguardo o esperienza con il coinvolgimento stratificato di MVC in ViewState quando incorporato in un sito Web "Classico" ASP.NET.

Buona fortuna.

B

+0

Grazie per il suggerimento. Non ho mai esplorato questo percorso, esaminando tutti i problemi che possono essere causati mettendo il viewstate in sessione che mi sono allontanato dal mio PageStatePersister. Se lo spacco, aprirò sicuramente la tua idea di crittografare la sessione da solo. – felickz

0

La mia ipotesi è che il bilanciamento del carico Web Farm è la fonte della confusione. Hai dichiarato che solo "un solo server [è] pronto per i test in questo momento", ma tutti i sintomi che stai riscontrando sembrano esattamente come accadrebbe se fossero in esecuzione più server nella web farm, ma hai creato solo web.config e machine.config cambia su un server. Quando si colpisce il sito Web con il browser, a volte si colpisce un server che è stato configurato in un modo, a volte si colpisce un altro server che è stato configurato in un altro modo.

+0

Questo pensiero mi è passato per la mente molte volte durante la settimana in cui ho trascorso a giocare con questo. L'ho controllato continuamente e, quando sono stato frustrato, sono passato al mio server di sviluppo che non è bilanciato. MA tu hai un punto valido ed è importante per tutti capire in un ambiente con bilanciamento del carico – felickz