Envío una solicitud de AJAX y cuando el HTML se vuelve a cargar, recupero los valores de algunos elementos de la IU en el lado del cliente y se los presento al usuario, de este modo:
var displ="<h1>"+$( "#myslider" ).slider( "values", 0)+</h1>
$("mydiv").append(displ);
¿Se puede cambiar el valor de #myslider o cualquier otro elemento como un cuadro de selección por un valor como <script>...</script> y crear una inyección XSS?
Respuesta corta: Sí .
Respuesta más larga: Sí, si el <select> ya contiene un <option> con una carga útil XSS (de alguna manera, ver más abajo), y también depende de qué tipo de control deslizante () la función hace. Si toma su otro ejemplo (una entrada de selección), usar val () sin limpiar el contenido causará este problema. A menos que el control deslizante () limpie el contenido HTML de alguna manera, puede hacer lo mismo.
Esta es una forma de secuencias de comandos entre sitios basadas en DOM
. Ejemplo de trabajo (con <select> ): enlace
Probado en Chrome para Mac OS X.
addString();
$("select").change(addString);
function addString() {
var displ=$("select").val()+"<br/>";
$("div").append(displ);
}
Donde hay un <select> y uno <div> en la página.
Explotación práctica
La otra pregunta es ¿cuándo un atacante puede explotar esto prácticamente? Para que esto sea práctico para un atacante, el valor de un select <option> tendría que provenir de una fuente no confiable, ya sea directamente de un parámetro de solicitud controlable por el usuario (incluyendo encabezados HTTP, cookies, etc.) para el XSS reflejado, o donde la carga útil es cargado desde el almacenamiento (base de datos, etc.) para XSS almacenados.
El ejemplo anterior ya tiene la carga útil XSS en la página, por lo que básicamente se supone que ya se ha producido una entrada que no es de confianza.
Ejemplo # 1
Aquí hay un ejemplo que está completamente basado en DOM. JavaScript establece el valor de una opción para el hash de ubicación de URL. Por lo tanto, si la víctima es atraída a una página con una carga XSS después de un # en la URL, se puede activar el XSS.
Ejemplo # 2
Uso una tecnología del lado del servidor (PHP en este caso) para crear una página con un elemento <option> generado dinámicamente a partir de un parámetro de URL controlable por el usuario. Como soy un desarrollador súper inteligente, sé que si se pueden escapar las comillas dobles, la página será vulnerable al XSS reflejado en el elemento <option> , así que me aseguro de eliminar las comillas dobles de la cadena. , pensando que estaré a salvo.
// User controlled parameter
$value = $_GET("value");
// "Sanitise" the value by removing double-quotes
$sanitised = str_replace('"', '', $value);
// Output to the page
echo "<option value=\"" . $sanitised . "\">Choose Me!</option>";
Debido a que el desarrollador ha eliminado las comillas dobles, este problema no puede ser directamente explotado. Es decir. el atacante puede poner todo tipo de caracteres dentro del valor de la opción, pero no puede inyectar cosas como "> para finalizar el elemento de opción y comenzar uno nuevo.
Sin embargo, debido al XSS basado en DOM, el Javascript aún tomará esta cadena, que posiblemente contenga elementos HTML, y la enviará directamente a la página. Por supuesto, el desarrollador debe tener:
Las referencias son cheatsheets de OWASP.