Evasión de la variable de JavaScript cuando la comilla se escapa, pero no la nueva línea

2

Estoy buscando una forma de evadir adecuadamente una variable de JavaScript para realizar XSS. Una entrada de usuario normal dará var a='<b>user input</b>' .

a no es eval en ninguna parte y no se puede utilizar. Sin embargo, he encontrado algo interesante. Una entrada como %0a%0dalert(1);// se procesará como:

var a='<b>
alert(1);//</b>'

Mi navegador me está advirtiendo sobre un error de token ilegal. Esto es normal, y debido a que var a no se cierra.

¿Hay alguna manera de hacer que esto funcione? Ejecutando la función de alerta ignorando el error anterior. ' se escapa como \' y \ como \ . Otros elementos básicos Los caracteres HTML también se codifican de manera normal ( &quot; &lt; &gt; &amp; )

    
pregunta Xavier59 27.05.2016 - 23:05
fuente

2 respuestas

4

Para causar una inyección en este contexto, necesita:

Cerrar la etiqueta de script:

por ejemplo

</script><script>alert('xss');

O cierre el contexto de la cadena de comillas simples:

por ejemplo

'; alert('xss');

Sin embargo, como la primera opción daría como resultado &lt; , etc, y la segunda opción daría como resultado que los caracteres \' se emitieran (y no es posible escapar \ debido a \ ), lo haría decir XSS no es posible en este caso.

La única esperanza es que si el conjunto de caracteres es UTF-7 o se pueda cambiar a tal para UTF-7 XSS .

El único defecto de seguridad aquí es que, de lo contrario, un atacante podría causar una denegación de servicio al evitar que se ejecute otro código JavaScript e impedir que la aplicación funcione según lo previsto.

    
respondido por el SilverlightFox 12.07.2016 - 15:20
fuente
0

Tendré que coincidir con la evaluación de SilverlightFox de que la explotación exitosa de este "posible" vector de ataque se verá seriamente obstaculizada (como es la intención de la codificación en primer lugar).

Parece que no hay ninguna forma de "consumir" (es decir, sobrescribir) los caracteres en UTF-8, y los caracteres que necesitas eliminar ya se están escapando. Su pregunta esencialmente es paralela a lo que ya se ha hecho aquí: ¿Cómo se puede vencer el saneamiento que escapa de las comillas simples mediante la inyección de SQL en SQL Server? >

La respuesta corta es "Hay algunos pocos (énfasis) casos en los que la función de escape fallará:"

  • El contexto no emplea comillas simples circundantes (lo que es tuyo, por lo que no se aplica)
  • Si se filtra una subcadena; Este es bastante desagradable porque el atacante intenta usar sus rutinas de codificación / filtrado en contra de su aplicación. Si, por ejemplo, sus reglas de filtrado hacen una sola pasada, eliminando todas las apariciones de "onclick" en la entrada del usuario, pero luego su atacante pasa "ononclickclick", sus resultados de filtrado en "onclick" se escriben en la página. Por supuesto, esto requiere que usted modifique sus filtros para asegurarse de que no está dejando de lado a los personajes que podrían escapar de su rutina de codificación.
  • Los ataques Unicode fueron compatibles (es decir, la base de datos acepta GBK , etc.)

Fuente: enlace

    
respondido por el rdev5 13.07.2016 - 01:25
fuente

Lea otras preguntas en las etiquetas