[ASP.NET] Encriptando el ViewState

Follow @julitogtu

Como ya todos sabrán, cuando hablamos del desarrollo de aplicaciones Web con ASP.NET Web Forms, un tema clave es el ViewState, el ViewState permite mantener el estado de una página, controles cuando se realiza un postback, por ejemplo, si tu seleccionas un ítem en una lista (dropdownlist en este caso) y enviar tu página al servidor por alguna razón, a menos que programáticamente se cambie el ítem seleccionado cuando se vuelva a cargar la página la selección que se hizo no se pierde, y esto es gracias al ViewState.

Ahora, el ViewState se almacena en un campo oculto en cada página, y ese valor es validado por el servidor cuando la página en enviada, si quieren ver el ViewState de x página entonces en el explorador seleccionar ver código fuente, y allí buscamos el control con id=’_ViewState’, por ejemplo:

 1: <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMTY4ODMwNDIxNWRkT+WM3DOwh5uijZZHqblfLffgUC4in6ObYJk+MWBASQ0=" />

Como se ve, el valor del ViewState no es entendible, pero no porque este encriptado, es porque por defecto es almacenado con un encoding en base64, el cual es muy sencillo de leer, una aplicación que pueden usar y la que siempre he usado es ViewStateDecoder, la cual lee el valor y permite ahora si ver de manera claro los datos.

Ahora, cuando la seguridad es nuestra aplicación es un tema fundamental, es posible encriptar el valor del ViewState, y es posible realizarlo a nivel de todo nuestro sitio o en una página específica, para hacerlo a nivel de página simplemente en la directiva de la página colocamos el atributo ViewStateEncryptionMode=”Always” y si fuera a nivel de sitio, se debe especificar en el archivo de configuración <pages viewStateEncryptionMode=”Always”></pages> dentro del nodo System.Web.

Una consideración muy importante que se debe tener presente es que cuando se encripta el ViewState, la página tardará más tiempo en cargar,  así que debe usarse con precaución… además les recomiendo le den una mirada a temas de optimización, ya que algunas veces podemos tener un ViewState increíblemente grande, lo cual va a causar una disminución en el rendimiento de la aplicación.

Espero les sea interesante el post, hasta la próxima.

[ASP.NET] Ataques por URL

En el pasado post vimos una pequeña introducción a la esencia de un ataque XSS (mira el post acá), así que siguiendo con algunos temas de seguridad quiero mostrarles un gran error que se comente cuando trabajamos aplicaciones Web, lo cual claramente se puede convertir en un problema grande de seguridad. Creo que todos conocemos que por medio de la URL de una página podemos enviar valores a otra página, y esto claramente es muy sencillo, por ejemplo, si quisiéramos ver el detalle de un producto con un determinado código podemos tener una URL parecida a la siguiente:

   1:  http://misitio.com/producto.aspx?idProducto=50

Con lo cual le estaríamos diciendo al sistema que el producto del cual deseamos ver el detalle es aquel cuyo id es el 50, lo cual no esta mal, sin embargo acá ya podemos mencionar algunos posible problemas:

• La manipulación de la URL queda 100% del lado del usuario
• El usuario visualiza datos sensibles de la aplicación

Ahora, si comentamos más en detalle los dos puntos anteriores, podemos decir que en el segundo caso debemos ser demasiado cuidadosos con los datos que enviamos por URL, NUNCA debemos enviar datos sensibles como claves, números de tarjetas o demás información privada, y en el primer punto el rollo radica en que el usuario puede colocar lo que desee en la URL.. bueno y esto que problema tiene??

Como ejemplo, digamos que en la página tenemos un método llamado CargarInformacionProducto, el cual realiza una consulta a nuestra base de datos en busca de los datos del producto teniendo como filtro el id del producto, si ese es que vemos en la URL, entonces suponga que (y debería ser) el id del producto es de tipo int, con lo cual convertimos el valor de la variable idProducto a int, una forma podría ser:

   1:  int idProducto = Convert.ToInt32(Request.QueryString["idProducto"]);

Sencillo no? claro que si, pero bueno, ahora suponga que nuestro querido usuario que no tiene nada que hacer va a la URL y la deja algo así:

   1:  http://misitio.com/producto.aspx?idProducto=FelizNavidad

Que!!! Si así como lo ves, ahora vamos a buscar el id del producto cuyo valor es FelizNavidad, entonces al ejecutar la misma instrucción de convertir a int (creo que ya sabrán que va a botar error) vamos a tener el siguiente error:

El cual se da simplemente porque no es posible convertir FelizNavidad a un dato numérico… y bueno si nuestro querido usuario sigue cambiando la URL y ahora elimina todos los parámetros que tiene?? es decir deja solo la parte de producto.aspx entonces volvemos a tener problemas, ya que cuando intentamos acceder a una variable no es posible, claro ya que no esta en la URL, y puede que no se genere error pero nuestra aplicación tampoco va a funcionar de la mejor manera.

Bueno ustedes podrán decir que hasta el momento los ataques no han tenido un problema serio, y es verdad, pero que pasaría si tenemos una URL como:

   1:  http://misitio.com/eliminarproducto.aspx?idProducto=50

En ese caso estaríamos eliminado el producto con id igual a 50, y en ese caso modificando el valor de idProducto nos podrían estar borrando TODOS nuestros productos, lo cual les aseguro si seria un problema…o no?? Y eso no es todo, también nos podrían incluir código JavaScript en la URL!!

En resumen, debemos tener mucho cuidado al manejar variables por QueryString (si no sabes que es QueryString mira este post), y algunas puntos que podemos tener presente son:

• No mostrar información sensible.
• Validar que la variable existe.
• Validar el tipo de dato de la variable.
• No realizar operaciones directamente, aplica para el ejemplo de la página eliminarProducto.
• Encriptar los valores que pasamos (me gusta hacerlo siempre).

Y hasta acá llegamos, ha sido un post corto, de un tema que ya todos conocemos, pero que algunas veces pasamos de largo.

Hasta la próxima!

[ASP.NET] Conociendo los ataques XSS

Cuando comenzamos el desarrollo de una nueva aplicación Web, generalmente pasamos por encima el tema de seguridad, pensando que con implementar un sistema de autenticación nuestro sistema es los suficientemente seguro para responder a cualquier ataque por pequeño que sea… y en realidad no es así. Es por eso que iré mostrando (tan seguido como el tiempo me lo permita) algunos de esos ataques que puede recibir un sitio Web, no intento decir que soy un hacker ni mucho menos, y tampoco que soy un experto en seguridad, pero quiero dar algunos aportes al tema, una cosa importante que deseo aclarar es que los puntos que voy a ir mostrando si los vas a probar no deben hacerlos sobre sitios en la Web, como bien sabrán estos temas de seguridad son bastantes delicados con los temas legales.

Entonces iniciemos, y que es eso de XSS?, según la Wikipedia:

XSS, del inglés Cross-site scripting es un tipo de inseguridad informática o agujero de seguridad típico de las aplicaciones Web, que permite a una tercera parte inyectar código JavaScript en páginas web vistas por el usuario, evitando medidas de control como la Política del mismo origen.

Y en resumen, es simplemente atacar utilizando código JavaScript, pero para entenderlo mejor vamos a realizar un sencillo ejemplo. En el ejemplo el usuario podrá ingresar un nombre de usuario en un campo de texto y al dar click en el botón de enviar el texto ingresado será mostrado en un label, simple no? y ustedes dirán que es algo muy sencillo, pero realmente nos podemos complicar la vida, en resumen el HTML de nuestro ejemplo sería:

   1:  <form id="form1" runat="server">

   2:      <h1>XSS</h1>

   3:      <div>

   4:          <b>Nombre:</b>

   5:          <asp:TextBox ID="txtNombre" runat="server"></asp:TextBox><asp:Button ID="btnEnviar" runat="server" Text="Enviar" />

   6:          <hr />

   7:          <b>Nombre ingresado: </b><asp:Label ID="lblNombre" runat="server"></asp:Label>

   8:      </div>

   9:  </form>

Listo, luego de tener nuestro “complejo” formulario listo, vamos a agregar una pequeña lógica al evento click del botón, el cual simplemente tomará el texto ingresado en el campo de texto y lo mostrará en el label inferior:

   1:  protected void btnEnviar_Click(object sender, EventArgs e)

   2:  {

   3:      lblNombre.Text = txtNombre.Text;

   4:  }

Ahora si ingresamos el texto “julitogtu” y damos click en el botón que sucede? pues nada raro, ese texto se muestra en el label sin problema (lo cual era lógico verdad??), pero ahora vamos a cambiar un el texto ingresado por: <script>alert(‘Mensaje JavaScript’);</script> y nuevamente damos click en el botón de enviar y vemos que ahora obtenemos una pantalla digamos que de error, la cual es:

Y que ha pasado?? simple, el usuario está intentando enviar un pequeño código JavaScript, y por default toda aplicación Web realizado con ASP.NET lo considera peligroso, lo cuál es completamente cierto, pero bueno si nos detallamos un poco más en la imagen vemos que nos sugiere dos pasos:

1. Modificar el Web.configla etiqueta httpruntime y establecer el valor de la propiedad requestValidationMode="2.0".
2. En las directivas de la página establecer el valor de la propiedad validateRequest en false.

Así que hagámoslo, entonces el Web.config quedaría (y no olvides el punto 2):

   1:  <?xml version="1.0"?>

   2:  <configuration>

   3:      <system.web>

   4:          <compilation debug="true" targetFramework="4.0"  />

   5:          <httpRuntime requestValidationMode="2.0"/>

   6:      </system.web>

   7:  </configuration>

Luego de realizar los dos cambios anteriores, vamos a probar de nuevo, y que pasa en este caso? pasa que al ingresar el valor: <script>alert(‘Mensaje JavaScript’);</script> en el campo de texto y dar enviar se esta mostrando un alert de JavaScript, si el que se ingreso en el campo de texto!! y en nuestro label no se está mostrando nada :

Y ahora si podemos ver el problema verdad?? y eso que en el ejemplo solo se ha ingresado un simple alert… pero como todo tiene solución simplemente vamos a utilizar una función que nuestro querido framework nos provee, y es el HtmlEncode, entonces reescribiendo el código del click del botón tenemos:

   1:  protected void btnEnviar_Click(object sender, EventArgs e)

   2:  {

   3:      lblNombre.Text = HttpUtility.HtmlEncode(txtNombre.Text);

   4:  }

Y al volver a intentar ahora si el comportamiento es el esperado, sin embargo quiero aclarar que establecer el valor de la propiedad validateRequest en false no es la mejor práctica, peor ya veremos en otro post más de este tema, espero esta introducción les sea de interés.

Saludos!