Caso de aplicación de JavaScript limitado: vectores de ataque y mitigación

  

• ¿Qué vectores de ataque hay en este tipo de escenario?
  

XSS basado en DOM es el más grande.

Normalmente, esto permite una gran cantidad de cosas: registro de claves, extracción de datos en la página, XSRF, redirección a un sitio de phishing, manejo por descargas.

Pero siempre que se vuelva a mostrar al usuario que ingresó y no persiste, no es realmente un problema.

  

• ¿Qué harías para mitigar cualquier vector de ataque?
  

Use document.createTextNode(plainText) para insertar texto en el DOM en lugar de node.innerHTML = plainText .

Asegúrese de no rellenar previamente el cuadro de texto con datos de la URL para que sea realmente cierto que el usuario ingresa los datos.

No permita que el encuadre de su sitio impida que la página de un atacante envuelva su página e ingrese al usuario para que copie y pegue contenido en el cuadro de texto.     

Las dos amenazas más importantes son Clickjacking y acceder al almacenamiento sin conexión. Se puede acceder al almacenamiento sin conexión con XSS basado en DOM o si la máquina que lo ejecuta se ha visto comprometida. Incluso si su aplicación no usa GET / POST / Fragmento como entrada, una de sus bibliotecas podría hacerlo.

Evite XSS del lado del cliente (también conocido como XSS basado en DOM). Lea OWASP para recursos sobre este tema. Consulte también El consejo de Adam Barth sobre este tema , que es excelente.

Una versión corta: por el amor de Dios, no use setInnerHTML , document.write() o eval() en el texto que el usuario ingresa en el área de texto. Use setInnerText (o document.createTextNode etc.) en lugar de setInnerHTML .

Suponiendo que no se lean datos desde ningún lugar (como los parámetros GET), el único ataque posible es que el documento html se manipule cuando se carga. Si se carga localmente, la versión en el disco puede ser manipulada; si se carga desde un servidor sin https, el documento puede modificarse durante la transferencia o cambiarse en el servidor.

Aparte de eso, si no hay entrada o salida (además de lo que está escrito y visible en la pantalla; me refiero a cosas como guardar en disco), no veo qué ataques podría ejecutar que no pueda realizar cada otro campo de entrada en el sistema.

Edit: Oh, se perdió esta parte: Any input will need to be redisplayed to the user who has entered it. La oración anterior a esa sugería que se eliminaría. De hecho, ese podría ser un vector de ataque, por ejemplo cuando se manipula ese caché. Sin embargo, no creo que haya grandes riesgos en esto.