Supongo que la codificación HTML de la entrada probablemente sea una mejor solución, pero tengo curiosidad de que simplemente eliminar cualquier carácter < y > sería una defensa eficaz contra los ataques XSS.
¿Al hacer esto, se mantendrá un sitio seguro contra XSS?
ACTUALIZACIÓN: si no me protege, ¿podría alguien explicar qué tipo de ataque podría pasar?
Depende del contexto en el que se produzca la inyección.
Obviamente, si la inyección se produce en el contexto de un contenido de elementos como este:
<p>Your search for "❌" has returned the following results:</p>
< es necesario para cambiar de texto a marcado. Pero incluso aquí, si hace eco de la entrada del usuario en un <script> , por ejemplo:
<script>var search = "❌";</script>
Necesitará buscar otros caracteres ya que no está en el contexto de texto sin formato. Aquí debe cuidar los caracteres que son especiales dentro de los literales de cadenas de JavaScript, así como ciertas secuencias que pueden denotar el script etiqueta final del elemento , por ejemplo, </script> o </script/ .
Del mismo modo, si imprime una entrada de usuario en el valor de atributo de un elemento:
<input type="text" name="search" value="❌">
Aquí debe ocuparse de los caracteres que son especiales para los valores de atributo entre comillas dobles , es decir, la delimitación " quote. Si está utilizando comillas simples o ninguna, se deben aplicar reglas diferentes.
Además, no solo tiene que buscar la sintaxis sino también la semántica. Al igual que hay javascript: y data: URI que se pueden usar para XSS. O hay un JavaScript que utiliza parte de los datos provistos por el usuario para alguna evaluación, o recuperación de algún código de script adicional, etc. Hay cientos de ejemplos .
Entonces siempre tenga en cuenta el contexto en el que desea colocar los datos proporcionados por el usuario y codificar esos datos de manera correspondiente.
Respuesta corta: No.
Respuesta larga: en muchos casos, sí, pero no lo hagas.
Alguien me corrige si me equivoco acerca de algo aquí.
Si , y solo si, el texto solo se envía al "cuerpo" de un elemento de estilo estándar, y si ese cuerpo no es agarrado por algún Javascript o de otra manera, entonces Honestamente tengo que decir que sí. Por cuerpo me refiero a que el texto se envía en la forma <b><u>$USERINPUT</u></b> ; es texto dentro del documento HTML y no es parte del marcado de alguna manera. Por lo tanto, no está dentro de alguna etiqueta o bloque especial.
Sin embargo, muchas veces este no es el único caso en el que las entradas del usuario se escribirán en la página. Si está escribiendo dentro de una etiqueta HTML, generalmente un valor de atributo, entonces se verá algo así: <img src="file.jpg" alt="$USERINPUT" /> . Aquí, el filtrado en < o > no ayudará, ya que el atacante puede ingresar " onload="alert('XSS')" o algo similar, y el HTML resultante se convertirá en <img src="file.jpg" alt="" onload="alert('XSS')" /> , lo que significa que se puede ejecutar un Javascript arbitrario.
Y si de alguna manera está colocando la entrada del usuario en algo dentro de una etiqueta <script> , hay una gran cantidad de cosas de las que debe preocuparse.
Básicamente, solo use una función de sanitización HTML buena y probada. No tendrás que preocuparte por todos los casos si lo haces.
No, porque hay formas de omitir el < > etiquetas La entrada debe tratarse como una cadena, por lo que debe codificarla correctamente. Le sugiero que eche un vistazo a la guía de prueba owasp v3
Lea otras preguntas en las etiquetas web-application xss