Parches 9521 y El 11290 hace varios años intenta mitigar este problema, aunque no pretende eliminar completamente la posibilidad de XSS. He estado ejecutando en jQuery 2.x algunos de los exploits que afirman que aún existen, pero no parecen estar funcionando, por lo que definitivamente no puedo confirmar y negar si el código que proporcionaste es suficiente para explotar.
Para lo que vale, también es posible que ocurra esta vulnerabilidad si haces algo con el objeto jQuery. Digamos que permitió a los clientes enviar HTML, y un cliente envió lo siguiente:
<div id="xss">alert('xss');<div>
Y por alguna loca razón, tenías el siguiente código en la página que muestra este HTML:
eval(jQuery(window.location.hash).text());
Un hash de URL de #xss causaría que se active una alerta.
Así que puedo confirmar que esto es posible, aunque sería muy difícil explotarlo de esta manera en particular sin escribir el código específicamente para ser vulnerable.
Recomiendo hacer una verificación de validación en el valor de window.location.hash o eliminar los caracteres especiales antes de pasarlo a jQuery() , y como siempre, piense en lo que hace con el objeto jQuery.
Como menciona la respuesta de Goose, parece que había algunas versiones anteriores de jQuery que eran vulnerables a esto.
Dado que la función jQuery puede convertir cadenas en elementos DOM como este ...
$(‘<p>Something</p>’);
Si su código tuviera:
$(location.hash);
Y un atacante le hizo acceder a su página con una URL especialmente diseñada que terminó con un fragmento de hash como:
#p=<img src%3D/%20onerror%3Dalert(1)>
Luego, jQuery interpretaría el hash como HTML, crearía los elementos DOM necesarios y, en el proceso, ejecutaría cualquier controlador JS adjunto a ellos.
Las versiones futuras de jQuery parecen haber mitigado esto al dar prioridad a los selectores de ID sobre HTML, por lo que cualquier cosa que comience con un hash se trata como un selector CSS, no como HTML.
¿Por qué adivinar? Simplemente desinfecte con \ w primero, es muy fácil. Parece bastante aterrador si tienen el control completo sobre esa línea jQuery, incluso si debe comenzar con un hash. En las palabras del enlace de Goose 9521 ,
Supongo que la pregunta es si este es un movimiento tan común que necesitamos priorizar un selector de id sobre HTML para este caso. yo podría estar convencido.
y
Sin embargo, no estoy seguro de cómo podemos proteger en general contra esto. los El símbolo de hash es solo texto y la cadena es HTML válido. Los usuarios deben no está pasando una entrada no confiable a $ () que podría contener un script.
Entonces, según al menos un desarrollador de jQuery, esto ni siquiera se considera una vulnerabilidad en absoluto. Y quiere dejar que el programador no lo haga. Incluso si no lo agrega ahora, un mantenedor posterior probablemente lo notará y agregará window.location.hash.replace(/[^\w]/g, "") . (O [^\w-] si usa guiones). Nada se salva realmente al evitarlo. Claro que pueden mitigarlo, pero no creo que esta actitud sea la fuerza líder detrás de su seguridad web.
Mi entrada para la entrada del usuario es un archivo JS especial en la parte superior que maneja todas las entradas de desinfección y almacena cosas como window.location.hash en una variable "UserHash" que ya está desinfectada, con un saneamiento documentado para que otros sepan qué ellos pueden asumir Descubrí que no hacer esto llevará inevitablemente a vulnerabilidades más adelante. Alguien dirá "Oh, es seguro aquí, así que será seguro aquí", dejando las cosas al borde de la semiseguridad cayendo en una vulnerabilidad real.