¿Por qué escribir en el portapapeles en JS se considera un agujero de seguridad?

Question

Parece que actualmente no hay un método de JavaScript puro para acceder al portapapeles del sistema usando la mayoría de los navegadores modernos, Internet Explorer es una excepción. En numerosas otras preguntas sobre desbordamientos de pila (por ejemplo, Clipboard access using Javascript - sans Flash?), se explica que esta limitación es una medida de seguridad deliberada para proteger contra sitios web que leen contraseñas u otros datos confidenciales del portapapeles.

Aunque parece obvio que la lectura desde el portapapeles sería un gran riesgo para la seguridad, no es claro por qué escribir en el portapapeles habría. ¿En qué escenario, si hay alguno, están protegiendo los buscadores al negar a JS la capacidad de copiar datos en el portapapeles?

Answer 1

Escribir en el portapapeles es una forma de que los sitios web maliciosos (u otros códigos que se ejecutan dentro de los sitios, como los anuncios basados ​​en flash) engañen a los usuarios para que propaguen el malware. Esto sucedió hace unos años con anuncios basados ​​en flash que copiaban una URL de malware en el portapapeles, con la esperanza de que los usuarios pegasen cuando tenían la intención de pegar algo más, contaminando así cosas como publicaciones de Facebook, foros y correo electrónico. En lugar de un enlace a una foto del gato de la tía Tilly, pegaría un enlace a algún malware drive-by. Por lo general, estos fueron los "fraudes antivirus falsos que le han infectado con un virus, paguen $ 50 por el software de eliminación". Hice algunas investigaciones al respecto, ya que muchos de mis clientes de ClipMate se preguntaban por qué estas desagradables URL aparecían repentinamente en ClipMate. Mientras investigaba, fui atacado por anuncios basados ​​en flash en MSNBC y DIGG. El portapapeles se ha bloqueado posteriormente en Flash 10. Puede leer más sobre mi saga aquí: http://www.clipboardextender.com/defective-apps/clipboard-virus-not-exactly-but-still-dangerous

Espero que la restricción de JavaScript evite que sucedan cosas similares.

Answer 2

¿Qué sucede si el usuario no desea sobrescribir su portapapeles?

Answer 3

Si el usuario espera que su portapapeles contenga una cosa, pero de forma encubierta ha sido reemplazada por otra cosa, incluso eso es un problema potencial de seguridad, no solo una molestia.

Aunque es un vector de ataque poco probable, no es irracional pensar que se podría imaginar algo que involucre ingeniería social: convencer al usuario de pegar información alterada secretamente en un campo de contraseña en un recurso de destino. Ese recurso estaría protegido por una contraseña conocida por el atacante.

Answer 4

Además de los problemas de vulnerabilidad mencionados anteriormente, hay al menos un escenario en el que la implementación impráctica de la API del portapapeles de JavaScript puede plantear algunos problemas de seguridad.

Hoy en día tenemos nuevas API para establecer conexión entre ventanas separadas sin invocar el lado del servidor, como postMessage, MessageChannel o, por ejemplo, BroadcastChannel recientemente introducido a Firefox. Estas API tienen diferentes niveles de compatibilidad con el navegador, pero todas ellas están considerando problemas de origen cruzado. Es decir, debería ser imposible recibir un mensaje de una ventana en un host diferente a menos que esta ventana realmente lo permita explícitamente.

Esto no se cumple con la API del portapapeles. Imagine que algún código en la página pega el código al portapapeles y este portapapeles es escaneado por alguna otra ventana. Este es un escenario muy extraño y altamente hipotético que depende de algunas suposiciones bastante extrañas y exóticas, pero vale la pena mencionarlo.