¿La comparación de entradas de usuarios no saneados es suficiente para ser vulnerable a XSS?

Question

¿La comparación de entradas de usuarios no saneados es suficiente para ser vulnerable a XSS?

#1 de Anders (1 votos)
#2 de Pascal (0 votos)

1

Diga que recibo una entrada de usuario de window.location.hash . ¿La comparación de esta entrada no saneada con los valores de la lista blanca es suficiente para abrirme a las vulnerabilidades de XSS?

Toma el siguiente código de ejemplo:

jQuery(function ($) { 
  var hashVal = window.location.hash; 
  $('.some-container').children().each(function(){ 
    var link = $('a', $(this));
    if(hashVal === link.attr('href')){
      //do something with link
    }
  }); 
});

Lo he probado contra algunas cadenas potencialmente problemáticas sin éxito (o éxito total dependiendo de cómo lo mires).

Tengo curiosidad por si el if(hashVal === link.attr('href') podría explotarse con algo como #1 || true){}; //some malicious code...; // .

xss javascript

pregunta Ben.12 01.03.2017 - 18:28

fuente

2 respuestas

1

Tu código se ve bien y no es explotable.

Una cadena de JavaScript solo contiene, bueno, una cadena de letras. A veces esas letras forman una pieza de código. Eso no es peligroso en sí mismo, ya que JavaScript solo lo trata como una colección de letras la mayor parte del tiempo, por ejemplo. cuando haces comparación de cadenas.

Para que abra una vulnerabilidad XSS, algo debe ejecutar el código. Hay dos formas en que puede ocurrir:

Si asigna la variable como entrada a una función que ejecuta la cadena como código. El principal aquí es eval , pero también hay new Function , setTimeout y setInterval .
Si coloca la cadena en el DOM, por ejemplo. utilizando innerHTML .

Mientras se mantenga alejado de esos dos, el código no se ejecutará.

respondido por el Anders 01.03.2017 - 18:57

fuente

Lea otras preguntas en las etiquetas xss javascript

¿Cómo ayuda PKI a demostrar que un sitio es legítimo? [duplicar] ¿Cómo puedo protegerme mejor en una red encriptada con usuarios no confiables?

score 0 · Accepted Answer

La respuesta de Anders ya explica por qué su código está bien. Me gustaría concentrarme en la siguiente declaración:

el if (hashVal === link.attr ('href') podría ser explotado con algo como # 1 || verdadero) {}; // algún código malicioso ...; //.

Parece que estás asumiendo que el #1 || true){}; // some malicous code ; // llevaría a lo siguiente:

if(#1 || true){}; //some malicious code...; // === link.attr('href') {
   // do something with link
}

(lo cual no tendría mucho sentido de todos modos porque el # 1 no es un javascript legal, que yo sepa). Sin embargo, no es así como Javascript (o cualquier lenguaje de programación que conozco) evalúa las expresiones.

Para mí, su ejemplo parece que está intentando usar un ataque de inyección SQL en Javascript. La inyección de SQL se realiza correctamente porque las personas pegan consultas de esta manera (en lugar de utilizar consultas parametrizadas):

query = 'SELECT * FROM users WHERE loginname = "' + name + '"'

Este es un error horrible porque el nombre podría contener algo como 1"; drop table users; # .

Al pegar una cadena de consulta como la que permite a un atacante escapar de la protección de la cadena citada a SQL sin formato.

Pero no estamos en la misma posición al escribir código Javascript. Para poder hacer posible el tipo de vulnerabilidad que temía en Javascript, tendría que pegar el código como si la gente pegara las consultas de SQL, tal como esto:

var jscode = 'if (' + hash + ' === link.attr("href") { ... }'

Luego si hash contenía algo como true) { malicious_code() } , y si como dijo Anders, pondrías el contenido de jscode en el DOM o hacer eval(jscode) , el código malicioso se ejecutaría.

De lo contrario, está muy bien aislado dentro de una cadena inofensiva.