Estoy probando una aplicación que solo omite los símbolos < y > . La entrada del usuario que se valida siempre se inserta entre etiquetas html como <b> , <span> , <div> , etc. y nunca se pasa a la página como un atributo. ¿Es suficiente protección o hay una manera de evitar este tipo de filtro?
Ejemplo:
<a href="http://www.site.com" style="color:white">
UserInput
</a>
Saludos.
Esto no es suficiente protección
Hay muchas maneras en las que un atacante podría colarse en una secuencia de bytes que el navegador de alguien interpretará como marcado.
En su caso, incluso podría ser posible usar ampersand encoding para pasar < y > chars.
Si falla, doble codificación se puede usar para omitir sus filtros, o incluso excesivas secuencias de utf-8 (sin embargo, esta última está un poco desactualizada y la mayoría de las pilas de software no se lo permiten).
Esos son solo algunos ejemplos, pero hay muchas más formas de evitar los filtros de marcado simple como el tuyo. Este bit en particular es relevante.
Oh, por dónde empezar ...
Si hay un principio de seguridad que se demuestra una y otra vez, es que las listas negras fallan.
Juegue el juego largo: asegúrese de que su aplicación web pueda resistir la cantidad limitada de ataques que lanzó hoy, pero Internet podrá probar miles de cosas más con miles de variables más (nuevo código, diferente navegadores, diferentes conjuntos de idiomas, etc, etc, etc).
"La entrada del usuario que se valida es siempre", dice usted hoy. ¿Qué sucede cuando te mueves y otro desarrollador hereda ese código? ¿Comprenderán y honrarán los compromisos que asumieron en su cabeza? Si ingresas la validación y la codificación de salida, le das una oportunidad de pelea al siguiente jugador.
Continúa y elimina "" < script > ", ¿qué sucede cuando alguien envía" "< scr < script > ipt >" "?
¿Quién proporciona el HREF dentro de la url que proporcionó aquí?
<a href="http://www.site.com" style="color:white">
UserInput
</a>
Si se extrae el href de una etiqueta de entrada. Entonces este es solo otro caso de no filtrar o escapar lo suficiente de la entrada del usuario. Todas las aportaciones de los usuarios deben considerarse malvadas.
Por ejemplo, si es el usuario el que proporciona la URL para esa etiqueta de anclaje en su caso de ejemplo, es completamente posible que este sXSS funcione y se cargue con cada mouse sobre:
URL: http://www.site.com" onmouseover="javascript:alert(1)"
Alternativamente, puedes cambiar el onmousover to onload y ahora tienes tu javascript ejecutándose en cada carga de página. Deshabilitar eventos DOM desde etiquetas HTML es otro método para prevenir este tipo de ataque sXSS.
Lea otras preguntas en las etiquetas web-application xss