En un principio pensaba dar recomendaciones de programador, pero también es interesante la parte de como defendernos siendo usuarios finales de una página, dado que no podemos confiar en la mayoría de los "programadores" que andan dando vueltas, porque no conocen ni medio de seguridad (es una lástima, pero es así). Arranquemos así con lo que podemos hacer desde nuestra posición de usuarios web.
Trust no one
Nunca mejor aplicada esta frase de X-Files, cuando se trata de navegar por la Web, no podemos confiar en nadie, ni siquiera en nuestros amigos. Por esto, lo mejor es estar prevenidos y tener en cuenta algunos consejos para no ser víctimas del XSS. Estos consejos se aplican a ataques en general, aunque en me esté focalizando en XSS.
El primer paso a dar es utilizar un browser decente. La mayoría de la gente sigue utilizando damn vulnerable Internet Explorer, incluso versiones extremadamente vulnerables como la 6 que no proveen mucha ayuda al pobre navegante. Es verdad que Microsoft ha mejorado mucho con su browser en los últimos años, no leo sobre muchos exploits para la versión 8, pero las versiones 6 y 7 siguen siendo grandes víctimas y tienen gran presencia en la web. Por supuesto que no sólo IE es un gran problema, todos los browsers cuentan con su lista negra de errores, las versiones 1 y 2 de Firefox no ayudan mucho en cuanto a prevenir XSS. Por supuesto que Opera, Safari y Chrome también arrastran sus problemas.
Mi elección es utilizar Firefox 3+ con algunos complementos que nos ayuden a distinguir XSS. Chrome tiene un gran futuro, pero creo que todavía está bastante verde.
Los agregados pueden darnos una buena mano para prevenir ataques. NoScript para Firefox es un excelente ejemplo. Este agregado bloquea contenido JavaScript, Flash, Java y otros, permitiéndonos elegir qué páginas tienen permitido ejecutar qué. Además reconoce diferentes ataques y los bloquea, reportándolos al usuario. Internet Explorer 8 cuenta con filtros XSS que intentan acercarse a la funcionalidad de NoScript, aunque por ahora parecen estar basados solamente en listas negras con ataques conocidos.
Otro add-on interesante es Netcraft Anti-Phishing Toolbar disponible para Firefox e Internet Explorer que nos permite identificar sites que intentan robarnos información. Actualmente tanto Firefox como IE incorporaron una funcionalidad muy similar, así que tal vez no es tan útil como hace un tiempo.
El siguiente paso sería desactivar toda feature que no utilicemos. Existen múltiples formas de ejecutar ataques a través de tecnologías que muchas veces no utilizamos. Entre las más conocidas podemos encontrar JavaScript, ActiveX, Flash, Java, etc. La regla del pulgar nos dice, si no lo usamos, desactivemoslo. Es verdad que muchas páginas pueden no funcionar, pero al menos deberíamos poder bloquear selectivamente por página. NoScript nos da una gran mano para realizar esta tarea.
No clickear a lo tonto en todo lo que nos mandan. El comportamiento por defecto debería ser, desconfiar de todo link recibido por mail, foro, blog, red social, etc. Si la URL es muy larga, ya es algo muy sospechoso, y si incluye las palabras script o hacen referencia a algún script, es algo mucho más sospechoso. También son sospechosas las direcciones codificadas usando url, decimal o hexa encoding.
Tampoco deberíamos seguir links codificados con tinyurl o algún otro servicio de acortamiento de urls. Estos links podrían llevarnos a cualquier lado sin que nos enteremos. Existen algunos sites que nos permiten decodificar estas URLs pequeñas y ver de qué tratan realmente. Algunos ejemplos son http://longurl.org/ o http://kiserai.net/turl.pl
Programación Web Segura
Luego de tirar algunos consejos sobre cómo actuar al navegar por la red, nos metemos con la programación Web segura o "lo que diferencia un buen programador de uno mediocre". Si bien en un principio parece fácil solucionar este problema, existen más vueltas de las que uno se imagina. Por suerte, como cité en el primer artículo, existen algunas páginas con ejemplos para probar e imaginarnos cómo un atacante puede "encontrarle la vuelta" y vulnerar nuestro site.
El principio básico para evitar el XSS es el bien conocido "validar la entrada y filtrar la salida". Este principio que se aplica a todos los problemas de programación se usa poco y sin embargo nos salva de mucho. En el caso del XSS puede elegirse "validar la entrada" o bien "filtrar la salida", cada uno con sus ventajas y desventajas. Validar la entrada implica revisar todo lo ingresado por el usuario, mientras que filtrar la salida implica revisar sólo lo que se expone en la página, osea, si no todo se expone en la página, solo se debe filtrar una parte de todo lo ingresado. El problema con filtrar la salida es que quedan almacenados datos mal formados en bases de datos o archivos, algo que puede afectarnos si va cambiando la política de filtrado en la programación, pero los datos quedan intactos en los servers.
El consenso general es validar la entrada y evitarnos problemas futuros, además, filtrar la salida implica analizar los datos cada vez que se van a mostrar, mientras que validarlos a la entrada hace que el trabajo se realice una sola vez.
La mayor ventaja del filtrado de salida es que en esta etapa se sabe dónde se van a incluir los datos, es decir, no es lo mismo incluir los datos en el HTML que en una porción de código JavaScript, el tipo de filtrado puede cambiar en ambos casos. Por otro lado, qué sucede si el sistema que valida la entrada tiene un agujero en la validación y permite que algunos ataques pasen? una vez que los datos se almacenaron, quedan ahí... por más que parchemos el validador, los datos que ya pasaron seguirán estando y el ataque persistirá. Si por el contrario, usamos filtado de la salida y se descubre un bug en los filtros, una vez que lo parchamos, estamos salvados.
Leyendo todo esto, uno puede creer que lo mejor es implementar ambos controles, a la entrada y a la salida. Bueno, eso es cierto, sería ideal que el encargado de mostrar los datos no confíe para nada en los datos que tiene, y que el validador de la entrada haga su mejor esfuerzo pora que no pasen porquerías al almacenamiento. El problema, como siempre, es el agregado de procesamiento, algo que en un sistema con mucho tráfico nunca es deseado.
Una vez que tenemos decidido si validar la entrada o filtrar la salida, o ambos, debemos poner manos a la obra.
Escapando caracteres claves
Lo primero que viene a la mente cuando hablamos de inyección XSS es evitar los benditos delimitadores de tag "<" y ">", además de comillas simples y comillas dobles, que permiten ciertos trucos. Hay dos opciones para hacer esto, eliminamos estos caracteres o los codificamos de forma que el browser los interprete como texto. Existen varias formas de codificar estos caracteres para que el browser los interprete como texto y no como parte del HTML. Veamos cómo codificar los 5 caracteres más relevantes (llamados "big 5" en algunos lugares) y la barra hacia delante (usada para cerrar tags):
| Caracter | Codificacion HTML | Codificación Hexa | Codificación Decimal |
| & | & | & | & |
| " | " | " | " |
| ' | ' | ' | ' |
| < | < | < | < |
| > | > | > | > |
| / | / | / |
Esto quiere decir que si el usuario ingresa un >, nosotros deberíamos colocar un > (o & o &) en su lugar, para que no se interprete como código HTML. Por lo que he leído, algunas codificaciones en hexa o decimal pueden verse distintas en algunos browsers según la codificación de caracteres utilizada (UTF-8, ISO 8859-1, etc), así que recomendaría utilizar la codificación HTML.
Piensen ahora en alguno de los ejemplos anteriores, si antes el resultado de una inyección era:
Usuario: <B><SCRIPT>alert('XSS');</SCRIPT></B>escapando los tags obtendremos:
Usuario: <B><SCRIPT>alert('XSS');</SCRIPT></B>Como se ve, el código actual no ejecutaría ningún alert, sino que mostraría el código en la pantalla (como debería ser).
En muchos lenguajes existen funciones implementadas para realizar el trabajo de cambiar un caracter por su equivalente HTML, o bien para eliminar estos caracteres. A continuación les dejo algunos ejemplos:
PHP
- htmlentities nos ayuda a codificar los caracteres citados (utilizar la opción ENT_QUOTES para codificar comillas simples también).
- strip_tags nos permite eliminar tags de un dado string.
ASP.NET
- HttpUtility.HtmlEncode nos da una mano codificando HTML.
- No encontré una función para eliminar tags, pero si una solución interesante en el foro http://forums.asp.net/t/901364.aspx:
System.Web.UI.HtmlControls.HtmlGenericControl htmlDiv = new System.Web.UI.HtmlControls.HtmlGenericControl("div");
htmlDiv.InnerHtml = htmlString;
String plainText = htmlDiv.InnerText;
- ASP también cuenta con un parámetro seteable en el Web.config (o incluso en Machine.config) que valida la entrada y nos arroja una excepción cada vez que un parámetro contiene entidades HTML. Este parámetro se llama validateRequest. Si está en false, no se valida nada, pero si está en true ASP hace su magia. Eso sí, después capturen la excepción, porque vi varios ejemplos donde la página arroja un error horrible que el usuario no debería ver...
Pueden leer un poco más sobre validateRequest en http://www.asp.net/(S(ywiyuluxr3qb2dfva1z5lgeg))/learn/whitepapers/request-validation/
JSP
Al parecer a la gente de Sun no le resultó interesante incorporar una función para codificar caracteres especiales (ni para eliminar tags), así que Java no incluye entre sus librerías default una función que haga el trabajo. Por suerte en una entrada de la página de OWASP encontramos una función que haga el trabajo.
Como se pueden imaginar, si no contamos con funciones empaquetadas con el lenguaje (como el caso de java) siempre podemos construir nuestra función para codificar o eliminar tags. Eso si, hay que tener cuidado en la forma en que armamos expresiones regulares para eliminar tags, dado que algunas pueden no ser muy efectivas.
Escapando lo anterior estamos salvados?
Muchos autores han dicho (y muchos siguen diciendo) que si escapamos los "big 5" estamos a salvo del XSS... bueno, me apena decirles "WRONG!".
Dependiendo la situación en la que nos encontremos, no es estrictamente necesario utilizar los caracteres antes citados. En muchos casos nos basta con utilizar un event handler (manejador de eventos) como onClick, onError, onMouseOver, etc (existen casi 100 manejadores de eventos). Consideren un ejemplo donde el usuario decidió no cumplir con el estándar HTML y armó el siguiente código en php:
<INPUT TYPE=TEXT SIZE=30 NAME=search VALUE=<?php if(isset($_GET['user'])) print "<B>".$_GET['search']."</B>" ?> />
este es el clásico ejemplo del buscador (ja, ya parece nombre de ejemplo de libro de sistemas operativos). Como ven, el usuario no usó ninguna comilla, pero aún así, el código es válido para la mayoría de los browsers. Ahora, el usuario malo, podría ingresar lo siguiente en el campo de búsqueda: "nada onMouseOver=alert(String.fromCharCode(88,83,83))" (sin las comillas). El resultado HTML de la ejecución del código php será:
<INPUT TYPE=TEXT SIZE=30 NAME=search VALUE=nada onMouseOver=alert(String.fromCharCode(88,83,83)) />
ahora, cuando el usuario coloque el mouse sobre el campo de búsqueda, saltará el alert.
Observaron algo en el ejemplo? para el exploit no utilicé ninguno de los "big 5"!!! Tal vez se preguntan qué es la función String.fromCharCode. Esta función se encarga de obtener un caracter a partir del código ascii en decimal, el 88 representa la X y el 83 la S. De esta forma, no necesitamos incluir la comilla simple para el alert. Otra forma que también funciona es colocar "nada onMouseOver=alert("XSS")" donde usamos las comillas HTML codificadas.
Otro ejemplo es el de programadores totalmente kamikazes que se encargan de meter datos ingresados por un usuario en una función JavaScript! Si bien este código no debe estar necesariamente HTML escapeado, debería estar JavaScript escapado para no ejecutar código ingresado por el usuario. Un ejemplo rápido que se me ocurre, es el caso que queremos cambiar el color de una opción seleccionada por el usuario (tal vez un menú con varias opciones), por ejemplo:
<input type="button" id="home" value="home" onClick="window.location.href='test.php?opcion=home'" />
<input type="button" id="guest" value="guest" onClick="window.location.href='test.php?opcion=guest'" />
<?php echo $_GET['opcion']; ?>
<script>
var opcion = '<?php echo $_GET['opcion']; ?>';
if (opcion == "home")
{
document.getElementById('home').style.backgroundColor = "green";
document.getElementById('guest').style.backgroundColor = "red";
}
else if( opcion == "guest")
{
document.getElementById('home').style.backgroundColor = "red";
document.getElementById('guest').style.backgroundColor = "green";
}
</script>
El código anterior simplemente cambia el color de fondo del botón apretado, basándose en la opción seleccionada, la cual obtenemos de la URL. Ahora, que pasa si en la variable opción colocamos lo siguiente: "la'; alert('XSS'); //" el resultado en la variable anterior será:
var opcion = 'la'; alert('XSS'); //';
es decir, cerramos la asignación a la variable opción, luego ejecutamos un alert y comentamos el resto. Esto sin usar los delimitadores de tags, ni comillas dobles, ni ampersand, aunque sí comillas simples, pero si tenemos en cuenta que htmlentities por defecto no codifica comillas simples, podríamos correr riesgos aún usando esa función.
Vale aclarar que si tenemos habilitado el atributo magic_quotes de php, éste agregará back slash ("\") a las comillas y puede que el ejemplo no funcione. Igualmente existen formas para escapar los escapadores.
Y si quiero texto enriquecido?
Aca es donde empiezan los problemas mayores...
En muchos casos deseamos que el usuario pueda ingresar texto con formato, así que tal vez nos gustaría que puedan usar los tags <b> (negrita), <i> (cursiva), <a href> (links), <img> (imágenes), etc. Para este tipo de aplicaciones, no podemos utilizar una función que nos elimine todos los tags, sino que debemos hacer una eliminación/codificación selectiva...
Las cosas se pueden poner realmente feas dependiendo de lo que deseamos permitir. Recuerden que prácticamente ningún tag está a salvo de scripting, por ejemplo, en IE el código <B STYLE="xss:expression(alert('XSS'))"></B> les mostrará un alert...
Para arrancar, la política default debe ser: escapar/borrar todo tag a menos que esté explícitamente permitido (whitelist). Ahora, de los tags permitidos, debe hacerse un examen en busca de código potencialmente malicioso, o bien tener un formato predefinido de tag. Por ejemplo, si lo único que queremos permitir es el tag <B>, no deberíamos permitir cosas como <B STYLE="xss:expression(alert('XSS'))">. Hay que tener especial cuidado con el tag <IMG>, como pueden observar en la lista de RSnake, las cosas que se pueden hacer son muchas. Incluso armando expresiones regulares para buscar cosas como la palabra javascript en el código puede ser difícil. Por ejemplo, tal vez deseamos evitar que alguien ingrese lo siguiente:
<IMG SRC="javascript:alert('XSS');">pero también deberemos escapar cosas como:
<IMG SRC="jav ascript:alert('XSS');">o cosas más oscuras como:
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>
<IMG SRC=javascript:alert('XSS')>
<IMG SRC=javascript:alert('XSS')>
Los ejemplos anteriores funcionan solamente en IE 6 y Opera 9, pero hay que tener en cuenta la cantidad de usuarios (me animaría a decir millones?) que todavía utilizan IE 6...
Una buena recomendación es armar el texto resultante a partir de un formato fijo según lo ingresado por el usuario, y no dejar directamente lo que el usuario ingresó. Por ejemplo, si el formato de salida será <IMG SRC="http://algo">, no importa que el usuario ingrese <IMG SRC="http://algo" width="0" height="0" style="width:100px; height: 100px;" alt="">, el resultado será siempre <IMG SRC="http://algo">. También debería verificarse que el argumento SRC sea válido, esto es, que sea una referencia a una imagen y no un script.
Como se irán dando una idea, habilitar algunos tags trae varios dolores de cabeza. Por suerte existen algunas librerías creadas para tal fin. Una interesante es PHP Input Filter que ha sido premiada por su labor. Otros esfuerzos interesantes son el proyecto OWASP ESAPI que soporta los lenguajes Java, .NET, PHP, Classic ASP, Cold Fusion, Python, and Haskell, y AntiXSS para ASP.NET.
6 reglas de oro by OWASP
La OWASP nos provee 6 reglas (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet) para evitar ataques del tipo XSS. El artículo trata el problema de forma general y no ofrese una solución concreta para un lenguaje en particular, de eso deberá encargarse el programador. Estas reglas están muy bien pensadas y cubren todo lo que he tratado hasta aquí, si es que se implementan correctamente... claro.
A continuación les traduzco los principios básicos de cada regla, para la información completa diríganse a la fuente original:
Regla #0 - Nunca insertar datos no confiables excepto en lugares permitidos
La regla cero nos dice, negar todo!, es decir, no colocar ningún dato ingresado por el usuario en el HTML a menos que esté incluído en alguna de las reglas #1 a #5. Esta regla sirve como complemento a todas las demás, es decir, si no está incluido en las otras reglas, entonces no lo incluyas en tu HTML!
<script>...NUNCA PONER DATOS NO CONFIABLES AQUI...</script> directamente en un script
<!--...NUNCA PONER DATOS NO CONFIABLES AQUI...--> dentro de un comentario HTML
<div ...NUNCA PONER DATOS NO CONFIABLES AQUI...=test /> en el nombre de un atributo
<...NUNCA PONER DATOS NO CONFIABLES AQUI... href="/test" /> en el tag de un nombre
Regla #1 - Escapear HTML antes de insertar datos no confiables en el contenido de un elemento HTML
Esta regla sirve para cuando queremos poner datos no confiables directamente en algún lugar del cuerpo HTML. Esto incluye dentro de todos los tags conocidos como div, p, b, td, etc.
<body>...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...</body>
<div>...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...</div>
aplicar para cualquier otro elemento HTML.
Para escapar los datos no confiables, aplicar lo que expliqué en la sección "Escapando caracteres claves".
Regla #2 - Escapear atributos antes de insertar datos no confiables en atributos HTML comunes
Esta regla se utiliza para colocar datos no confiables dentro de atributos como width, name, value, etc. Esto no debería usarse para atributos complejos como href, src, style, o cualquiera de los even handlers como onMouseOver. Es extremadamente importante que para los even handlers se siga la regla #3.
<div attr=...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...>contenido</div> dentro de atributos sin comillas
<div attr='...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...'>contenido</div> dentro de atributos con comillas
<div attr="...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...">contenido</div> dentro de atributos con comillas dobles
Excepto los caracteres alfanuméricos, escapar todo caracter con valores ASCII menores a 256, con el formato #xHH (es decir, valor hexa) para evitar el problema de salirse de los atributos (como el ejemplo citado en "Escapando lo anterior estamos salvados?").
Regla #3 - Escapear JavaScript antes de insertar datos no confiables en datos JavaScript
Como tercer regla tenemos la concerniente a los event handlers de JavaScript que pueden ser especificados en varios elementos HTML. El único lugar seguro para poner datos no confiables es dentro de comillas.
<script>alert('..ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...')</script> dentro de un string entre comillas
<script>x='...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...'</script> a un lado de una expresión entre comillas
<div onmouseover='...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...'</div> dentro de un event handler entre comillas
Excepto los caracteres alfanuméricos, escapar todo caracter con valores ASCII menores a 256, con el formato #xHH (es decir, valor hexa) para evitar el problema de cambiar del contexto de datos al contexto script o en otro atributo. No utilizar escapeadores como la barra invertida porque los caracteres como las comillas serán reemplazados por su codificación HTML correspondiente.
Regla #4 - Escapear CSS antes de insertar datos no confiables en propiedades HTML de estilo
Esta regla existe para los casos en que se desee colocar datos no confiables en una hoja de estilo o en un tag de estilo. Debido al poder de CSS para realizar ataques, es importante que sólo se coloquen datos no confiables dentro del valor de una propiedad y no en otros lugares de los datos de estilo. Sobre todo debe tenerse mucho cuidado de no colocar datos no confiables en propiedades como url, behaviour, y custom. Lo mismo se aplica a las expresiones de propiedad de IE, las cuales permiten JavaScript.
<style>selector { property : ...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...; } </style> valor de propiedad
<span style=property : ...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...;>text</style> valor de propiedad
Excepto los caracteres alfanuméricos, escapar todo caracter con valores ASCII menores a 256, con el formato #xHH. No utilizar escapeadores como la barra invertida porque los caracteres como las comillas serán reemplazados por su codificación HTML correspondiente.
Regla #5 - Escapear URL antes de insertar datos no confiables en atributos URL
La última regla de esta lista se utiliza para los casos en que deseamos colocar datos no confiables en un link que apunta a otro lugar. Esto incluye a los atributos href y src. Existen otros atributos de locación, pero no es recomendable colocar datos no confiables en ellos. Algo importante de remarcar es que resulta muy mala idea colocar datos no confiables en URLs javascript:, pero de ser necesario se puede utilizar la regla #3 para ello.
<a href=http://...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...>link</a > un link normal
<img src='http://...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI...' /> fuente de una imagen
<script src="http://...ESCAPEAR DATOS NO CONFIABLES ANTES DE COLOCARLOS AQUI..." /> archivo script
Excepto los caracteres alfanuméricos, escapar todo caracter con valores ASCII menores a 256, con el formato #xHH. Incluir datos no confiables en URLs data: no debería estar permitido, debido a que no hay una buena forma de deshabilitar ataques con escapeado para prevenir el salirse de la URL.
Fumata final
Como pudieron ver a lo largo del artículo, la prevención de XSS no es la pavada que puede parecer al principio. Agregar editores de texto enriquecido (osea, aceptar código HTML ingresado por el usuario) complica considerablemente las cosas. Hay que tener mucho cuidado de codificar todo lo ingresado por el usuario, y evitar, siempre que se pueda, colocar datos no confiables en lugares peligrosos como dentro de un script.
Nunca se debe confiar en el browser del cliente. Distintos motores renderizan las cosas a su gusto y muchas veces de forma peligrosa. Por ejemplo, los browsers aceptan tags mal formados como <script (sin el > que cierra). Como pueden leer en las referencias, IE puede hacer cosas locas al intentar decifrar la codificación de caracteres o el contenido de un documento... Firefox también tiene problemas como el uso de la directiva moz-binding para incluir XML.
En fin, la vida del programador no es para nada fácil, pero es importante que al menos tengan noción de los peligros que enfrentan, y tratar de aplicar las 6 reglas que propone OWASP para minimizar riesgos.
Recomiendo altamente la lectura del documento ArticlesXSS de la sección Web Security de los HOWTO de google. También es una exelente lectura el libro XSS Attacks, pero este es pago y tal ves no puedan obtenerlo. Por supuesto que es indispensable leer los artículos de la OWASP para programar de forma segura.
La realización de este artículo me llevó mucho más tiempo que la de los dos anteriores, encontré mucho material y traté de incluir todo lo más relevante. Espero que les sea de utilidad, tanto para programadores como para entusiastas o simples aprendices =)
Si bien con esto cerraría la parte más grosa de XSS, espero poder escribir antes de terminar diciembre algunos complementos más, como el de ataques relacionados, o el de herramientas para detección de XSS. Como siempre, si tienen material para agregar, dejen referencias en los comentarios y tal vez lo incluya en un artículo versión "Lost Chapters" =)
Referencias
- XSS Attacks - Cross Site Scripting Exploits and Defence (Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anto Rager, Seth Fogie)
- XSS (Cross Site Scripting) Prevention Cheat Sheet - OWASP
- ArticlesXSS - Web Security - Google
- How To: Prevent Cross-Site Scripting in ASP.NET
- XSS (Cross Site Scripting) Cheat Sheet (RSnake)
- Browser Security Handbook
- Data Validation - OWASP
3 comentarios:
Buenisimo te felicito, Seria copado si puedes unir todo estos post sobre XSS en un pdf para ternerlo, en la biblioteca virtual.
Gracias..
Realmente un artículo que trae mucha luz al asunto del XSS. Van las Felicitaciones del caso.
Salu2,
J
Muy buen artículo, creo que es un complemento perfecto a los anteriores que escribiste.
Personalmente, creo que tal vez es un poco extenso, y da para dividirlo en la parte dedicada a programación, y la parte dedicada a "consejos en general".
Saludos
Publicar un comentario