El XSS consiste básicamente en inyectar javascript malicioso aprovechando las debilidades de los sitios que lo permitan, no se deben tomar a la ligera por cuanto puede llegar a se muy dañinos Tomando como referencia la Wikipedia hay varias formas de llevar a cabo este tipo de ataque, pero para nuestro ejemplo nos centraremos en el ataque directo, que normalmente consiste en inyectar código en un textbox cuyo dato posteriormente se mostrará, por lo que al dibujar el contenido del control se convierte en un script que se ejecuta dentro de la pagina.
Tomemos la pagina de prueba de nuestro tutorial de creación de controles.
Como se puede apreciar consiste en un textbox, un botón y un label. Lo que escribimos en el TextBox al hacer clic sobre el Botón se mostrará en el Label. Imaginemos una pantalla donde el usuario digita algunos datos y otra donde estos se muestran solo como lectura, la mecánica es similar.
Que pasa si en la caja de textto incluimos algo como
Así como esta nuestro control (sin utilizar un UpdatePanel) pasaría lo siguiente:
Como se puede ver el ASP.Net incorpora un mecanismo por medio del cual se validan las entradas que realizan los usuarios. Esta activada por defecto, pero es tan sencilla de deshabilitar, como agregar la directiva validateRequest="false" a la página o por medio del archivo de configuración para todo un sitio.
Supongamos que esta barrera esta de habilitada o que fue superada y el script logró ser introducido. ¿Que sucedería? Pues que nuestro label personalizado como cualquier Label de .Net se dibujará como un elemento HTML tipo span y el script inyectado se ejecutaría.
El riesgo es bastante alto. Imaginemos que el script ingresado hubiese sido:
El sistema ingresaría en ciclo infinito de mensajes. Por supuesto que hay script mucho más peligrosos, con fines más específicos, pero ha modo de ejemplo con esto basta para darnos cuenta que nuestro control, nuestro Label personalizado, debe contar con alguna forma de lidiar con este tipo de ataque.
La respuesta está en HttpUtility.HtmlEncode del namespace System.Web, por medio de este prevenimos que elementos propios de script o manipulaciones de DOM como tratar de incluir iframes, divs, etc. se puedan ejecutar, ya que parsea los caracteres especiales en códigos html y al final los muestra como simple texto.
Al final del método Render de nuestro control personalizado, podemos modificar el finally para que quede de la siguiente manera
Una vez hecho esto, ejecutamos de nuevo las pruebas de ataques XSS para demostrar que, por lo menos con esta ajuste, ya estamos mejor preparados.
Como desarrolladores de aplicaciones Web debe estar conscientes de la existencia de este tipo de ataques, para poder preparar nuestras aplicaciones para lidiar con ellos.
<script>alert ('Vulnerablidad XSS'); </script>.
Así como esta nuestro control (sin utilizar un UpdatePanel) pasaría lo siguiente:
Supongamos que esta barrera esta de habilitada o que fue superada y el script logró ser introducido. ¿Que sucedería? Pues que nuestro label personalizado como cualquier Label de .Net se dibujará como un elemento HTML tipo span y el script inyectado se ejecutaría.
El riesgo es bastante alto. Imaginemos que el script ingresado hubiese sido:
while(1)alert("Este mensaje saldra indefinidamente");
El sistema ingresaría en ciclo infinito de mensajes. Por supuesto que hay script mucho más peligrosos, con fines más específicos, pero ha modo de ejemplo con esto basta para darnos cuenta que nuestro control, nuestro Label personalizado, debe contar con alguna forma de lidiar con este tipo de ataque.
La respuesta está en HttpUtility.HtmlEncode del namespace System.Web, por medio de este prevenimos que elementos propios de script o manipulaciones de DOM como tratar de incluir iframes, divs, etc. se puedan ejecutar, ya que parsea los caracteres especiales en códigos html y al final los muestra como simple texto.
Al final del método Render de nuestro control personalizado, podemos modificar el finally para que quede de la siguiente manera
finally { Text = HttpUtility.HtmlEncode(Text); base.Render(writer); }
Una vez hecho esto, ejecutamos de nuevo las pruebas de ataques XSS para demostrar que, por lo menos con esta ajuste, ya estamos mejor preparados.
Como desarrolladores de aplicaciones Web debe estar conscientes de la existencia de este tipo de ataques, para poder preparar nuestras aplicaciones para lidiar con ellos.
Desarrallador y líder técnico, con experiencia en tecnologías Microsoft desde los tiempos del VB6 y el asp clásico hasta el .Net Core, pasando por COM+, javascript, angularjs, Ionic, xaml, cordova, MVC, Web Api, Sql Server, Oracle... . Ávido lector, apasionado programador.
0 comments:
Publicar un comentario