Compartir a través de

Este artículo proviene de un motor de traducción automática.

Pinceladas sobre seguridad

Seguridad de estado de vista

Bryan Sullivan

Administrar de forma eficaz el estado de usuario en aplicaciones Web, puede ser un acto de equilibrio difícil de rendimiento, escalabilidad, facilidad de mantenimiento y seguridad. La consideración de seguridad es especialmente evidente cuando se administra el estado de usuario almacenado en el cliente. Tengo un compañero que solía decir que el estado manejo datos a un cliente están similar a la entrega de un cono de helados a un 5 años: puede recuperarlo, pero definitivamente no se puede esperar para que en la misma forma que tenía cuando se le concedió!

En la columna de este mes, examinaremos algunas implicaciones de seguridad relacionados con la administración de estado del cliente en las aplicaciones ASP.NET; en concreto, vamos a mirar la seguridad del estado de vista. (Tenga en cuenta: en este artículo se supone que está familiarizado con el concepto de estado de vista ASP.NET. Si no, consulte “ de Understanding ASP.NET View State ” por Scott Mitchell).

Si no hay datos almacenados en el estado de vista ’ las aplicaciones que vale la pena proteger, cree de nuevo. Información confidencial puede encontrar el camino en el estado de vista sin que aún se percate de ello. Y aunque le preocupa de evitar la pérdida de información confidencial a través de estado de vista, un atacante puede aún alterar los que el estado de vista y ocasionar problemas mayores para usted y sus usuarios. Afortunadamente, ASP.NET tiene algunas defensas integradas frente a estos ataques. Let’s, eche un vistazo a cómo se pueden utilizar estas defensas correctamente.

Amenaza Nº 1: Revelación de información

En Microsoft, los equipos de desarrollo, utilice el modelo STRIDE para clasificar las amenazas. STRIDE es una tecla de acceso que es el acrónimo:

  • Suplantación
  • Manipulación
  • Repudio
  • Revelación de información
  • Denegación de servicio
  • Concesión de privilegio

Los dos principales categorías STRIDE importantes desde la perspectiva de seguridad del estado de vista son la divulgación de información y la manipulación (aunque una manipulación con éxito el ataque puede dar lugar a una posible elevación de privilegios, analizaremos que con más detalle más adelante). Revelación de información es la más simple de estas amenazas, explicar, por lo que se tratará primero.

Uno de los conceptos erróneos Desgraciadamente más persistentes alrededor de estado de vista es que está cifrada o no se puede leer alguna manera por el usuario. Después de todo, una cadena de estado de vista sin duda, no tiene decomposable:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTE2MTY2ODcyMjkPFgIeCHBhc3N3b3JkBQlzd29yZGZpc2hkZA==" />

Sin embargo, esta cadena es simplemente codificado en base64, no se cifran con cualquier tipo de algoritmo criptográfico seguro. Se puede descodificar y deserializar esta cadena mediante la clase de formateador de (LOS) serialización limitada de objetos System.Web.UI.LosFormatter fácilmente:

LosFormatter formatter = new LosFormatter();
object viewstateObj = formatter.Deserialize("/wEPDwULLTE2MTY2ODcyMjkPFgIeCHBhc3N3b3JkBQlzd29yZGZpc2hkZA==");

Un vistazo rápido en el depurador (vea la figura 1 de ) indica que el objeto de estado de vista deserializado es realmente una serie de objetos de System.Web.UI.Pair termina con un objeto System.Web.UI.IndexedString con un valor de la contraseña de “ ” y un valor de cadena correspondiente del “ pez espada. ”

Figure 1 Secret View State Data Revealed by the Debugger

Figura 1 de Descripción de los datos de estado de vista de la clave por el depurador

Si se Don ir a la molestia de escribir su propio código para deserializar los objetos de estado de vista, existen varios estado de vista de una buena 
decoders disponible descargar gratuitamente en Internet, incluyendo la herramienta del Fritz Onion descodificador de ViewState en alt.pluralsight.com/tools.aspx de .

Cifrar el estado de vista

En “ el ciclo de vida de desarrollo de seguridad: SDL: Un proceso para desarrollar claramente más seguro software ” (Microsoft Press, 2006), Michael Howard y Steve Lipner, comente las tecnologías que pueden utilizarse para mitigar las amenazas STRIDE.La figura 2 muestra los tipos de amenazas y las técnicas de mitigación asociadas.

La figura 2 de técnicas para mitigar las amenazas STRIDE

Tipo de amenaza Técnica de mitigación
Suplantación Autenticación
Manipulación Integridad
Repudio Servicios de no rechazo
Revelación de información Confidencialidad
Denegación de servicio Disponibilidad
Concesión de privilegio Authorization

 

Dado que estamos trabajando en una amenaza de divulgación de información a los datos almacenados en el estado de vista, es necesario aplicar una técnica de mitigación de confidencialidad; en este caso, la tecnología de mitigación más eficaz de confidencialidad está cifrado.

Versión ASP.NET 2.0 tiene una función integrada para habilitar el cifrado del estado de vista, la propiedad ViewStateEncryptionMode, que se puede habilitar a través de una directiva de página o en el archivo web.config de la aplicación:

<%@ Page ViewStateEncryptionMode="Always" %>

O bien

<configuration>
   <system.web>
      <pages viewStateEncryptionMode="Always">

Hay tres valores posibles para ViewStateEncryptionMode: Siempre (siempre se cifra el estado de vista); nunca (nunca se cifra el estado de vista); y automático (el estado de vista sólo se cifra si uno de los controles de la página solicitudes de forma explícita). Los valores de siempre y nunca son bastante fácil de entender, pero automática requiere un poco de explicación más.

Si un control de servidor continúa información confidencial en estado de vista la página de su, el control puede solicitar que la página cifre el estado de vista mediante una llamada al método Page.RegisterRequiresViewStateEncryption (tenga en cuenta que en este caso el estado de vista entera está cifrado, no sólo el estado de vista correspondiente al control que lo ha solicitado):

public class MyServerControl : WebControl
{
   protected override void OnInit(EventArgs e)
   {
      Page.RegisterRequiresViewStateEncryption();
      base.OnInit(e);
   }
   ...
}

Sin embargo, hay una salvedad. La razón por la que el método se denomina RegisterRequiresViewStateEncryption y no algo parecido a EnableViewStateEncryption, es porque la página, puede pasar por alto la solicitud. Si ViewStateEncryptionMode la página está establecido en automático (o siempre), solicitud del control de la que se va a conceder, y se cifrará el estado de vista. Si se establece ViewStateEncryptionMode en nunca, se omitirá la solicitud del control y el estado de vista estará desprotegido.

Sin duda es algo a tener en cuenta si es un desarrollador de controles. Considere la posibilidad de mantener información potencialmente confidencial del estado de vista (que es siempre una buena idea). En casos extremos donde esto no es posible, es posible que considere la posibilidad de reemplazar los métodos del control SaveViewState y LoadViewState para cifrar y descifrar el estado de vista no existe de forma manual.

Consideraciones acerca del conjunto de servidores de servidor

En un entorno de servidor único, es suficiente habilitar ViewStateEncryptionMode, pero hay algún trabajo adicional que hacer en un entorno de conjunto de servidores. Algoritmos de cifrado simétrico, como las que ASP.NET utiliza para cifrar el estado de vista, requieren una clave. Puede especificar una clave de forma explícita en el archivo web.config o ASP.NET pueden generar automáticamente una clave. Una vez más, en un entorno de servidor único sirve permitir que el marco de trabajo de controlar la generación de claves, pero esto no funciona para un conjunto de servidores. Cada servidor generará su propia secuencia numérica, y las solicitudes que obtienen 
balanced de carga entre diferentes servidores se producirá un error porque no coincide con las claves de descifrado.

Puede establecer explícitamente el algoritmo de cifrado y de la clave que se utiliza en el elemento machineKey del archivo web.config de la aplicación:

<configuration>
   <system.web>
      <machineKey decryption="AES" decryptionKey="143a...">

Para el algoritmo de cifrado, puede elegir AES (el valor predeterminado), DES o 3DES. De éstos, DES está prohibido explícitamente por las normas de cifrado de SDL de Microsoft y 3DES está totalmente desaconsejado. Se recomienda seguir con AES para conseguir la máxima seguridad.

Una vez que haya seleccionado un algoritmo, deberá crear una clave. Sin embargo, recuerde que la intensidad de la seguridad de este sistema depende de la eficacia del esa clave. No utilice el nombre de su mascota, cumpleaños de otras de su significativos o cualquier otro valor fácilmente guessable! Debe utilizar un número aleatorio criptográficamente seguro. Éste es un fragmento de código para crear uno en el formato que el elemento machineKey espera (sólo de caracteres hexadecimales) mediante la clase RNGCryptoServiceProvider. NET:

RNGCryptoServiceProvider csp = new RNGCryptoServiceProvider();
byte[] data = new byte[24];
csp.GetBytes(data);
string value = String.Join("", BitConverter.ToString(data).Split('-'));

Como mínimo, debe generar valores de 16 bytes aleatorios para las claves; es el valor mínimo permitido por las normas de cifrado de SDL. La longitud máxima admitida para las claves AES es 24 bytes (48 caracteres como hexadecimal) en Microsoft .NET Framework 3.5 y versiones anterior y 32 bytes (caracteres de 64 hexadecimales) en el 4 de .NET Framework. DES admite un máximo de 24 bytes, independientemente de la versión del marco de trabajo de una longitud de clave máxima de sólo 8 bytes y 3DES. Una vez más, le recomiendo que evite estos algoritmos y AES en su lugar.

Amenaza Nº 2: Manipulación

Alteración es la otra amenaza importante. Quizás piense que la defensa mismo cifrado que impide que los atacantes fisgones en el estado de vista también impidan cambiarlo, pero es incorrecto. Cifrado no ofrece protección contra la manipulación: Incluso con los datos cifrados, es posible para que un atacante invertir bits en los datos cifrados.

Echemos otro vistazo a de figura 2. Para mitigar la amenaza de alteración, es necesario utilizar una tecnología de la integridad de datos. La mejor opción sigue siendo una forma de criptografía y todavía está integrada en ASP.NET, pero en lugar de utilizar un algoritmo simétrico para cifrar los datos, vamos a utilizar un algoritmo de hash para crear un código de autenticación de mensajes (MAC) para los datos.

La característica ASP.NET para aplicar un MAC se denomina EnableViewStateMac y, al igual que ViewStateEncryptionMode, se puede aplicar a través de una directiva de página o a través del archivo web.config de la aplicación:

<%@ Page EnableViewStateMac="true" %>

O bien

<configuration>
   <system.web>
      <pages enableViewStateMac="true">

Para entender lo que EnableViewStateMac realmente hace en realidad, let’s primero veamos alto nivel cómo habilita la vista de estado se escribe en la página cuando el estado de vista MAC es no :

  1. Estado de vista de la página y todos los controles de participantes se recopila en un objeto de gráfico de estado.
  2. El gráfico de estado se serializa en un formato binario.
  3. La matriz de bytes serializados se codifica en una cadena base-64.
  4. La cadena base-64 se escribe en el valor de la forma __VIEWSTATE en la página.

Cuando se habilita el estado de vista MAC, hay tres pasos adicionales que tienen lugar entre los anteriores pasos 2 y 3:

  1. Estado de vista de la página y todos los controles de participantes se recopila en un objeto de gráfico de estado.
  2. El gráfico de estado se serializa en un formato binario.
    a. un valor de clave secreto se anexa a la matriz de bytes del número de serie.
    b. un hash de cifrado se calcula para la nueva matriz de bytes del número de serie.
    c. el algoritmo hash se anexa al final de la matriz de bytes del número de serie.
  3. La matriz de bytes serializados se codifica en una cadena base-64.
  4. La cadena base-64 se escribe en el valor de la forma __VIEWSTATE en la página.

Cada vez que esta página se envía al servidor, el código de la página valida la entrada __VIEWSTATE tomando la entrada de estado de gráfico de datos (que se deserializan desde el valor __VIEWSTATE), agregar el mismo valor de clave secreto y vuelve a calcular el valor de hash. Si el nuevo valor de hash recomputed coincide con el valor de hash proporcionado al final de la entrada __VIEWSTATE, el estado de vista se considera válido y se realiza la transformación (consulte de figura 3). De lo contrario, el estado de vista se considera que han sido manipulados y se produce una excepción.

La figura 3 de la aplicación de un código de autenticación de mensajes (MAC)

La seguridad de este sistema se encuentra en la confidencialidad del valor de clave secreta. Este valor se almacena siempre en el servidor, ya sea en la memoria o en una configuración de archivos (más adelante), nunca se escribe en la página. Sin conocer la clave, no habría ninguna manera de que un atacante calcular un hash del estado de vista válido.

En teoría, con la suficiente potencia de un atacante podría a realizar ingeniería inversa a la clave: Cuenta con conocimientos de un valor de hash calculado y conocimientos sobre el texto sin formato correspondiente, y no hay demasiadas opciones disponibles para el algoritmo de hash. Sólo tendría que recorrer todos los valores de claves posibles, volver a calcular el valor de hash para el texto sin cifrar conocido, además de la clave actual y compárelo con el valor de hash conocida. Una vez que los valores coinciden, sabe que ha encontrado el ataque de ahora correcto de clave y puede el sistema como desee. El único problema con este es el abundante número de valores posibles: El tamaño de clave predeterminado es 512 bits, lo que significa que hay 2 a la potencia de 512 distintas posibilidades, que es por lo tanto, un número grande que un ataque de fuerza bruta es completamente informáticamente.

Aproveche el estado de vista MAC-menor

El valor predeterminado de EnableViewStateMac es true, por lo que la protección de las aplicaciones es tan simple como que no se establece en false. Desafortunadamente, hay algunos engañosa documentación sobre el impacto de rendimiento de EnableViewStateMac y algunos sitios Web a los desarrolladores al deshabilitar el estado de vista MAC a fin de mejorar el rendimiento de sus aplicaciones. Incluso la documentación en pantalla de MSDN para PagesSection.EnableViewStateMacProperty es el culpable de este elemento, que se indica: “ No establezca EnableViewStateMac en true si el rendimiento es una consideración clave. ” No siga este Consejo. (Con suerte, en el momento en que estás leyendo esto, la documentación se han cambiado para reflejar mejor las consideraciones de seguridad.)

Cualquier página que tiene el estado de vista MAC deshabilitado es potencialmente vulnerable a ataques de secuencias de comandos entre sitios con respecto al parámetro __VIEWSTATE. La primera prueba de concepto de este ataque se ha desarrollado por Byrne de David de Trustwave y demuestran Byrne y su compañero Rohini Sulatycki en la conferencia de controlador de dominio de Black Hat en febrero de 2010. Para ejecutar este ataque, los atacante de manualidades de un gráfico de estado de vista que se establece el código de secuencia de comandos malintencionada que se desea ejecutar como el valor almacenado de la propiedad innerHtml del elemento de formulario de la página. En formato XML, este gráfico de estado de vista será parecido al siguiente de figura 4.

La figura 4 del código XML en el estado de vista MAC ataque

<viewstate>
  <Pair>
    <Pair>
      <String>...</String>
      <Pair>
        <ArrayList>
          <Int32>0</Int32>
          <Pair>
            <ArrayList>
              <Int32>1</Int32>
              <Pair>
                <ArrayList>
                  <IndexedString>innerhtml</IndexedString>
                  <String>...malicious script goes here...</String>
                </ArrayList>
              </Pair>
            </ArrayList>
          </Pair>
        </ArrayList>
      </Pair>
    </Pair>
  </Pair>
</viewstate>

A continuación, el atacante base 64 codifica el estado de vista malintencionado y agrega esta cadena como valor de un parámetro de cadena de consulta __VIEWSTATE para la página vulnerable. Por ejemplo, si se sabe que tiene el estado de vista MAC deshabilitado home.aspx de la página en el sitio de www.contoso.com, el identificador URI de ataque sería https://www.contoso.com/home.aspx?\_\_VIEWSTATE=/w143a...

Sólo queda engañar a una víctima potencial en este vínculo. A continuación, el código de la página se deserializar el estado de vista desde el parámetro de cadena de consulta __VIEWSTATE entrantes y escribir la secuencia de comandos malintencionada como el innerHtml del formulario. Cuando la víctima, obtiene la página, secuencia de comandos del atacante se ejecutará inmediatamente en el Explorador de la víctima, con las credenciales de la víctima.

Este ataque es especialmente peligroso, ya que elude por completo todas las defensas habituales (XSS) secuencias de comandos entre sitios. No se bloqueará el filtro de XSS en Internet Explorer 8. La característica ValidateRequest de ASP.NET bloqueará varios tipos comunes de ataque XSS, pero no deserializar y analizar el estado de vista de entrada, por lo que también no es ayuda en esta situación. La biblioteca Microsoft Anti-Cross Site Scripting (Anti-XSS) (que ahora se incluye como parte de la biblioteca de protección de Web de Microsoft) es más eficaz contra XSS que ValidateRequest; sin embargo, las funciones de limpieza ni el resultado de las características de codificación protegerá contra este ataque ya sea de entrada ni la biblioteca de Anti-XSS. La defensa sólo real es garantizar ese estado de vista que Mac siempre se aplica a todas las páginas.

Consideraciones acerca del conjunto de servidores de servidor más

Al igual que ViewStateEncryptionMode, existen consideraciones especiales con EnableViewStateMac al implementar aplicaciones en un entorno de conjunto de servidores. El valor secreto utilizado para el valor de hash del estado de vista debe ser constante en todos los equipos de la batería, o se producirá un error en la validación del estado de vista.

Puede especificar la clave de validación y el algoritmo HMAC que se utiliza en la misma ubicación donde puede especificar la clave de cifrado del estado de vista y el algoritmo, el elemento machineKey del archivo web.config:

<configuration>
   <system.web>
      <machineKey validation="AES" validationKey="143a...">

Si la aplicación se genera en .NET Framework 3.5 o anterior, puede elegir SHA1 (el valor predeterminado), AES, MD5 o 3DES como algoritmo de MAC. Si se está ejecutando el 4 de .NET Framework, también puede elegir el MAC de la familia SHA-2: HMACSHA256, HMACSHA384 o HMACSHA512. De estas opciones, MD5 está prohibido explícitamente por las normas de SDL Crypto y 3DES está totalmente desaconsejado. También se desaconseja SHA1, pero para .NET Framework 3.5 y versiones anteriores aplicaciones es la mejor opción. Las aplicaciones de .NET framework 4 definitivamente deben configurarse con HMACSHA512 o HMACSHA256 como el algoritmo de validación.

Después de elegir un algoritmo MAC, también tendrá que especificar manualmente la clave de validación. No olvide utilizar números aleatorios criptográficamente fuertes: Si es necesario, puede hacer referencia al código de generación de claves especificado anteriormente. Se debe utilizar la validación de al menos 128 bytes claves HMACSHA384 o HMACSHA512 y claves de al menos de 64 bits para cualquier otro tipo de algoritmo.

No se puede ocultar el estado de vista vulnerable

A diferencia de un comando de base de datos que puede estar ocultos en el código del servidor o permiso de archivo vulnerable, el estado de vista vulnerable es fácil de encontrar sólo para el mismo. Si un atacante deseaba probar una página si se ha protegido el estado de vista, simplemente no se puede realizar una solicitud para la página a sí mismo y extraer el valor de estado de vista codificado de base64 del valor de la forma __VIEWSTATE. Si la clase LosFormatter puede deserializar correctamente ese valor, a continuación, se ha no cifrado. Es un poco más complicado, pero no mucho, para determinar si se ha aplicado el estado de vista MAC.

El código MAC se aplica siempre al final del valor de estado de vista y, dado que los tamaños de hash son constantes para cualquier algoritmo hash especificado, es bastante fácil de determinar si existe un MAC. Si se ha utilizado HMACSHA512 el MAC es 64 bytes; si se ha utilizado HMACSHA384, le resultará 48 bytes y si cualquier otro algoritmo se utilizó será 32 bytes. Si se eliminan 32, 48 o de 64 bytes de final de la base-64 descodificar el valor de estado de vista, y cualquiera de estos deserializar con LosFormatter en el mismo objeto que antes, a continuación, se ha aplicado el MAC de estado de vista. Si ninguna de estas recortado vista matrices de bytes de estado se correctamente deserializar, a continuación, no se ha aplicado el MAC de estado de vista y la página es vulnerable.

Casaba Security, realiza una herramienta gratuita para los desarrolladores que se llama monitor que ayudan a automatizar este proceso de pruebas. Monitor es una herramienta de proxy de depuración de Web de Fiddler de Eric Lawrence complemento y que funciona mediante el análisis del tráfico HTTP que fluye a través del proxy de forma pasiva. Marcará todos los recursos potencialmente vulnerables que pasan a través de, por ejemplo, una página .aspx con un __VIEWSTATE falta un Mac. Si ya no está utilizando Fiddler y el monitor como parte del proceso de prueba, le recomiendo dar un bloque try.

Conclusión

Seguridad del estado de vista no hay nada que toma a la ligera, es sobre todo teniendo en cuenta el estado de vista de nuevo la alteración de los ataques que recientemente se han demostrado. Le animo a aprovechar los mecanismos de seguridad ViewStateEncryptionMode y EnableViewStateMac integrado en ASP.NET.

Bryan Sullivan es un administrador de programas de seguridad para el equipo del ciclo de vida de desarrollo de seguridad de Microsoft, donde está especializado en cuestiones de seguridad de aplicaciones Web. Es el autor de la seguridad de Ajax “ ” (Addison-Wesley, 2007).

Gracias al siguiente experto técnico para este artículo:  Michael Howard