1.) ¿Se plantean problemas de seguridad para insertar el texto sin formato en la página web?
El texto simple es solo texto ... no hay impactos de seguridad a menos que comience a inyectar el código que realmente se ejecuta en el lado del servidor. Además, lo que está describiendo es el cifrado / descifrado del lado del cliente. Como resultado, terminará con texto sin formato (= descifrado) o con un bloque de caracteres "aleatorios" (= encriptado, adivinar la codificación de base64 después del cifrado y la descodificación de bas64 antes del descifrado será más seguro cuando piense las transferencias por correo electrónico)
2.) ¿La página web (de modo que Gmail) puede detectar dicha inyección?
Como Google cambia / actualiza su código en una base bastante frecuente, es difícil decirlo. Actualmente no lo haría ... pero eso podría cambiar en cualquier segundo (dependiendo de cuándo empuja Google una próxima actualización menor en línea). Teóricamente, es posible que Google implemente una rutina javascript bastante simple que busque modificaciones de la página en sí misma o de elementos secundarios del documento (como el área de texto). En la práctica, actualmente no está hecho ... pero como dije: cuando Google cambia su código, podrías tener problemas y tu extensión quedará sin efecto antes de que esté realmente disponible.
3.) ¿Es vulnerable a un Hombre en el ataque central?
Si con "it", te refieres al cifrado / descifrado del lado del cliente ... no, como sucede en el lado del CLIENTE antes de enviar cualquier información a cualquier lugar.
Si con "it" quiere decir "tráfico de correo electrónico" al enviar los datos después del cifrado, debe saber que, en general, el tráfico de correo electrónico "can" puede ser vulnerable a los ataques MITM. Pero como el correo de Google tiende a imponer el uso de SSL, personalmente considero que está a salvo de los ataques MITM cuando los usuarios realmente mantienen el SSL habilitado en todo momento.
Hablando de vulnerabilidades, me gustaría señalarle otras dos cosas que debe considerar:
-
Dependiendo de la criptografía que vaya a utilizar, la forma en que implementará las cosas puede y tendrá un impacto importante en las posibles vulnerabilidades (relacionadas con la criptografía) que deben considerarse.
-
Las máquinas cliente del remitente y / o el receptor pueden verse comprometidas: interceptar y transferir los datos descifrados mediante malware como troyanos.
-
El envío de bloques de datos encriptados por correo electrónico puede y probablemente lo pondrá en el radar de cualquier agencia gubernamental que pueda estar interesada en el contenido de dichos "mensajes codificados". Se conoce desde hace años, pero las noticias recientes relacionadas con #prism nos recordaron a todos que "ellos" están analizando activamente el tráfico como correos electrónicos cuando algo parece sospechoso. Supongo que no tengo que explicar que usar criptografía no dice "No tengo nada que ocultar" , sino todo lo contrario.
Por último, pero no menos importante, recuerde que, cuando se trata del desarrollo de software en general, hay restricciones en la importación de criptografía y hay aún más restricciones relacionadas con la exportación de criptografía y exportación de criptografía en los Estados Unidos ) relacionada con las implementaciones criptográficas. Dependiendo de su residencia, esto podría tener un impacto en el producto que planea crear. Actualmente, muchos países, especialmente aquellos que participan en el Arreglo de Wassenaar , tienen restricciones similares. Por lo tanto, asegúrese de leer los documentos que vienen con el (los) algoritmo (s) criptográfico (s) que planea usar o podría tener otros problemas más adelante.