asp.net problema de cifrado de viewstate

Question

Estoy intentando activar el cifrado de viewstate Siempre como medida de seguridad para mi sitio web ASP.NET 3.5 alojado en IIS6. Tenemos Viewstate desactivado, pero aún vemos algunos "controlstate" en esta cadena. En un entorno de prueba Soy capaz de establecer simplemente el siguiente en web.config y puedo base 64 ya no decodificar el estado de vista a semi-texto llano:

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

Incluso me han añadido los siguientes (por genereated machine key generater) en Machine.config y todavía encripta la multa estado de vista en mi servidor de prueba:

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

mi entorno no prueba no parece recoger los cambios anteriores como pueda decodificar siempre base 64 del estado de vista a texto sin formato con la configuración anterior. Siempre lo hago después de hacer cualquier cambio.

Algo de información sobre mi servidor web no prueba:

• de servidores Web/carga equilibrada (pero sólo un servidor para la prueba en este momento)
• SQL estado de sesión (machinekey en machine.config se necesita inicialmente configurar esto)
• machine.config: despliegue menor = "true"

puede alguien sugerir dónde buscar ajustes adicionales que pudieran interferir con el cifrado asp.net estado de vista?

EDITAR: Ahora en mi servidor de prueba iis no puedo deshacer la configuración de viewStateEncryptionMode ya que está encriptando ViewState aun cuando lo configuré en "Nunca" y ninguno de mis otros sitios web parece contener esta configuración. ¿Dónde puedo ver dónde está anulada esta propiedad? ¿Hay alguna memoria caché donde se almacena esta configuración que debe borrarse además de lo que se haría cuando reinicie/detenga el servicio www/touch machine.config?

EDITAR FINAL: Después de días estudiando los archivos de configuración, abandoné e implementé esto a través de un código. Ya tenía un módulo de seguridad que se adjuntaba a los eventos de página, así que en Page_Load agregué: Page.RegisterRequiresViewStateEncryption();

Me encantaría saber qué impedía que esta configuración fuera detectada en IIS6 de forma inmediata. Cuando ejecuto cassini localmente si configuro el modo viewStateEncryptionMode en "Siempre" a través del nodo de páginas, inmediatamente veré que codifica el viewstate y representa el campo oculto adicional con id = "__ VIEWSTATEENCRYPTED". Cuando lo configuro como "Nunca", inmediatamente vería que el cifrado se apaga. Si realizo el mismo cambio exacto al sitio web en mi sitio web alojado en IIS6, no tendría efecto de inmediato, pero si permitiera que la configuración permanezca allí, eventualmente se afianzaría. Yo detendría/iniciaría el servicio de www, restablecería iis, borraría la caché temporal de ASPNET pero no sé qué más probar. Afortunadamente, esta publicación puede ROTAR por un tiempo y alguien en el futuro verá el mismo comportamiento que yo experimenté y ¡podemos resolver esto aún más!

Answer 1

Web.config page settings do not apply to pre-compiled ASP.Net application with updatable option disabled. Ha pasado un tiempo pero mi servidor de prueba probablemente me había desplegado con la opción actualizable desactivada ... lección aprendida.

VER MSDN

similares Question -pregunté mismo problema.

Answer 2

Sé que ha pasado un tiempo desde que publicó esto, pero ¿ha considerado realizar su propia implementación de PageStatePersister? PageStatePersister es el componente responsable de formatear los datos de ViewState y ControlState integrados en su página. Si la seguridad es su principal preocupación, puede usar los algoritmos de cifrado que desee para garantizar que sus datos permanezcan privados. En función de su configuración, parece que se encuentra en un entorno bastante capaz, por lo que obviamente primero debe realizar una prueba de carga.También vale la pena mencionar que no tengo idea o experiencia con la participación en capas de MVC en ViewState cuando se incorpora en un sitio "clásico" ASP.NET WebForms.

Buena suerte.

B

Answer 3

Mi conjetura es la granja de servidores web que equilibra la carga es la fuente de la confusión. Usted indicó que solo "solo un servidor [está] listo para la prueba en este momento", pero todos los síntomas que está experimentando suenan exactamente igual a lo que sucedería si se ejecutaran varios servidores en la granja de servidores web, pero solo creó el archivo web.config y machine.config cambia en un servidor. Cuando accedes al sitio web con tu navegador, a veces golpeas un servidor que está configurado de una manera, a veces presionas otro servidor configurado de otra manera.