Solución simple para XSS

Esto parece una solución tonta para un problema ya resuelto:

1. Use una biblioteca de purificadores HTML para permitir solo un subconjunto seguro, O
2. Los caracteres de entrada cuestionables de escape HTML como <>'"& a sus equivalentes (por ejemplo, < va a < ). Además, si necesita permitir algún formato (por ejemplo, los usuarios pueden enviar enlaces, insertar texto en negrita) use un subconjunto seguro de un lenguaje de marcado liviano para convertir las entradas de usuario como [google link](http://www.google.com) a enlace de google .

Si su esquema fue perfecto e insertó cada carácter de la entrada de usuario no confiable, carácter por carácter, entre su propia etiqueta como <i>h</i><i>e</i><i>l</i><i>l</i><i>o</i> , personalmente no veo que un atacante realice fácilmente un ataque XSS, aunque alguien más podría hacerlo. pensar en algo

Líneas de ataques que podrían funcionar:

• tal vez puedan desordenar el DOM (insertando símbolos < > ) y algún navegador aleatorio intentará arreglarlo y corregirlo de alguna manera insegura.
• tal vez algún navegador permita que un atacante inserte la tecla de retroceso (Unicode 08) y escape de sus etiquetas de alguna manera
• o algún navegador optimiza internamente las etiquetas consecutivas, por ejemplo, las convierte en <i>hello</i> .
• o su método de analizar el carácter de entrada del usuario por carácter es defectuoso y superado.

Además, con su método no veo cómo su esquema le permitiría hacer cualquier cosa que desee hacer; por ejemplo, permite a los usuarios dar formato a texto o publicar enlaces o cualquier cosa elegante. En este caso, es más simple simplemente prohibir los caracteres <>&'" que tienen un significado especial en HTML.

¡Felicitaciones! He pensado un poco en esto y este es un sistema de escape bastante sólido. Aunque puede conducir a errores, no creo que esto sea muy útil para un atacante. La razón principal por la que una codificación de separación de caracteres es mejor que una codificación html tradicional es que causa problemas con la carga útil de un atacante.

Por ejemplo, los filtros XSS a veces no logran evitar que XSS dependa de dónde está escrito en la página. Si un filtro XSS toma en consideración el <> usual mientras ignora una doble cita, entonces este es un vector xss que usa la carga útil ";alert(1)// :

<script>
var j="";alert(1)//";
document.write(j);
</script>

Sin embargo, el uso de un método de codificación de separación de caracteres provocará un error de análisis de Java:

<script>
var j="<i>"</i><i>a</i><i>l/i><i>e</i><i>r</i><i>t</i><i>";
document.write(j);
</script>

¡La codificación HTML no es una panacea! El navegador descodifica automáticamente los valores dentro de una etiqueta HTML y esto puede llevar a xss en eventos DOM:

<a href="" onclick="alert('hi&#39;);alert(/xss/)//'">click</a>

En este caso, se mostrarán dos cuadros de alerta porque ' se descodificará automáticamente a una sola cita ' antes de que se evalúe como javascript. Sin embargo, si solo puede inyectar un solo carácter, obtendrá una excepción en la carga útil.

La codificación HTML es buena porque el navegador decodificará los valores HTML como <form value="o&#39;connel"> en el o'connell esperado antes de enviarlo como una solicitud. Si utiliza cualquier otro método de codificación xss, todos los valores entrantes deberán decodificarse, lo que podría causar problemas de filtrado o daños en los datos.

No creo que la sobrecarga adicional de este método de escape justifique la seguridad provista. Es preferible utilizar una codificación HTML tradicional. Un buen sistema de plantillas facilita la defensa contra xss.

Si su carácter especial es <i> y </i> y los datos que está tratando de codificar o visualizar incluyen < , i o > , entonces deberá "escapar" de esos caracteres. (o el trío de 3 caracteres) Como son caracteres bastante comunes, creo que deberás asegurarte de que siempre estén codificados / descodificados correctamente.

Entonces, ahora lo que tenemos es una solución que requiere que el desarrollador garantice un escape adecuado, también debemos tener en cuenta que no todo se escapa en todos los casos. Es decir, la etiqueta <title> .

En un caso, un Título puede contener nombres de usuario, nombres de productos, etc. Si se usa esta función, el escape condicional de la entrada del usuario es una cosa más que el desarrollador deberá recordar. Lo siguiente a considerar es JSON y Javascript. Las cosas no son tan simples ahora.

La solución que está proponiendo es crear el mismo problema que intenta resolver, aunque de otra forma: Exigir al desarrollador que escape de forma condicional los caracteres en función del contexto del valor que se mostrará.

Para complicar aún más esto, es cualquier DHTML creado por javascript que también debe mostrarse en el navegador, o si se utiliza la entrada del usuario para descargar una imagen:

   <img src="http://example.com/hackedUserDisplayName.js">

Enesecaso,eldesarrolladorqueríausarlaentradadelusuarioparaincluirenlapágina,peronolalimpiócorrectamente.Elenfoquedeetiquetadonoseusaríaaquíyhabríarotolaurldelaimagensilofuera.

Lofelicitoporpensarenmedidasdeseguridadproactivasytratardeencontrarunenfoquedetallaúnica,pero debe probar sus ideas con los ejemplos de XSS enumerados en esta página.

Sigue intentándolo y haznos saber si eres capaz de inventar un enfoque más consistente para arreglar XSS. El resultado más probable es que estarás bien versado en XSS. Es un ganar / ganar.

XSS es un problema resuelto. El hecho de que se sigan encontrando vulnerabilidades de XSS no significa que no se haya resuelto. Simplemente significa que alguien de manera incorrecta, o no implementó una solución.

Esta solución que planteas aquí es interesante, pero no la usaría.

Por un lado, probablemente tendrías que usar elementos span en lugar de i elements. Eso es un <span> seguido de 1 carácter seguido de </span> . multiplicado por la cantidad de caracteres de entrada que permita su aplicación web. Imo, eso es una hinchazón innecesaria en los datos que se deben almacenar. Además, aún debe considerar una entrada errónea como los caracteres NULL, & lt ;, & gt ;,;, ', "y otros símbolos.

Además, es mejor desinfectar la entrada antes de almacenarla en una base de datos y nuevamente después de recuperarla de una base de datos. La solución que tiene aquí no haría nada por recopilar datos al recuperarlos de una base de datos; lo digo porque estoy seguro de que ambos estamos de acuerdo en que no sacarán un carácter de la base de datos y lo insertarán dentro de un espacio. etiqueta.

Si busca eliminar por completo las posibilidades de ser vulnerable a los ataques XSS, agregue esto a su script PHP. Cuando toma la entrada del usuario y la inserta en una variable, como esto: $input = $_POST['input']; , en lugar de eso (que es 100% vulnerable) vaya: $input = htmlspecialchars($_POST['input']); . O también puedes ir: htmlentities($input = $_POST['input']); .