Los que ya tenemos una cierta edad y hemos trabajado (y mucho) con ASP Clásico estamos acostumbrados a ver la sintaxis <%= %> en las páginas Web. Este tipo de expresiones se limitan a mostrar lo que vaya dentro de ellas en el lugar indicado en la página.
Por ejemplo, si escribimos:
<%= Request.Url.ToString() %>
Obtendremos la URL de la página actual. Se puede usar cualquier tipo de expresión dentro de estas etiquetas (llamadas a funciones, condicionales, bucles…) y veremos en la página el resultado.
Este tipo de sintaxis siempre fue denostada por generar mucho código espagueti, el cual es típico de otros lenguajes como PHP. Está soportado por ASP.NET Web Forms, aunque prácticamente apenas se utiliza pues hay muchas opciones mejores.
Sin embargo vuelve a estar más de moda que nunca debido a ASP.NET MVC. En MVC se utilizan mucho en las vistas ya que permiten mostrar de manera directa y sencilla los valores de las propiedades del modelo. Y la verdad es que convierten en algo muy sencillo la generación de interfaces enlazados a datos.
Problemas de seguridad
El principal problema de este tipo de sintaxis es que muestra el resultado de la expresión que contienen las etiquetas directamente en el HTML de la página y sin codificar.
Por ello, si las usamos para mostrar contenidos generados por los usuarios (introducidos previamente, por ejemplo, en un formulario), podemos obtener código HTML + JavaScript malicioso que nos puede generar vulnerabilidades de Cross-Site-Scripting (XSS).
La solución más sencilla tradicionalmente ha pasado por codificar como HTML el contenido a mostrar antes de insertarlo dentro del HTML de la página, así:
<%= HttpUtility.HtmlEncode(«<script>alert(‘hola’);</script>») %>
Al aplicar el método HtmlEncode a la cadena anterior obtenemos en la página la misma cadena pero codificada como caracteres HTML (es decir, por ejemplo, el «<» se transforma en un «<», el «>» en un «>», etc…). De esta manera lo que obtenemos es una cadena de texto inocua insertada dentro de la página y visible dentro de ésta, que no tendrá efecto alguno sobre el comportamiento de la misma. Si no hubiésemos tenido la precaución de haber codificado la cadena dentro de la expresión lo que hubiésemos obtenido es una bonita ventana de advertencia saludándonos, ya que el texto del script formaría parte natural del a página y sería interpretado por el navegador.
La nueva sintaxis en ASP.NET 4.0
En ASP.NET 4.0 se introduce una nueva forma de conseguir lo anterior que consiste en utilizar esta sintaxis alternativa:
<%: %>
Es decir, se utiliza el símbolo de dos puntos en lugar del igual.
Esta expresión tiene la ventaja de que todo el contenido que se insertará en la página se codificará como HTML automáticamente antes de ser insertado. Así, por ejemplo, si tenemos un formulario con un campo «Comentario», y el usuario incluye un Script o algún código malicioso dentro de él, escribiendo (en C#) lo siguiente:
<%: Request[«Comentario»] %>
nos aseguraremos de que la entrada del usuario es inofensiva.
¿Y qué pasa si quiero que no estén codificadas?
Bueno, siempre nos queda la sintaxis tradicional, pero aún así se nos proporciona una forma de conseguirlo usando la nueva sintaxis también. Se trata de devolver las cadenas de texto finales dentro de una clase HtmlString. Por ejemplo así:
<%: new HtmlString(Request[«Comentario»]) %>
Esta clase indica que la cadena que contiene no debe ser codificada como HTML, pues ya es HTML o una cadena codificada como tal, por lo que obtendremos tal cual el contenido de la cadena sin modificar.
En resumen
Es recomendable que utilicemos esta sintaxis en lugar de la anterior, heredada de ASP 3.0 clásico), sobre todo los programadores de ASP.NET MVC 2. Además es muy fácil adaptar vistas existentes puesto que basta con hacer una búsqueda y sustitución de «<%=» por «<%:» para tener todas las vistas actualizadas.
No te preocupes si realizas el cambio y ya te preocupabas de codificar como HTML algunos campos antes de insertarlos: la etiqueta está preparada para reconocer que una cadena ya se encuentra codificada y no volver a codificarla por segunda vez, lo cual podría ser desastroso.
¡Espero que te sea útil!