Inyectar información en una página web (Gmail). ¿Plantea problema de seguridad?

3

Estoy desarrollando una extensión de Google Chrome que cifra / descifra los correos electrónicos de los usuarios de Gmail. Por lo tanto, detecto correos electrónicos encriptados cuando el usuario abre un correo electrónico sobre el uso de etiquetas. Una vez que se ha detectado un correo electrónico cifrado, se le pide al usuario una contraseña y el texto sin formato se muestra en una ventana emergente.

Quiero usar el diálogo de la interfaz de usuario de Jquery para mostrar el texto sin formato. Si conoce un poco del cuadro de diálogo Jquery UI, sabe que debe insertar una etiqueta div en la página web (gmail aquí) en la que coloca las cosas que desea mostrar en la ventana emergente. Y luego llamar al diálogo sobre esta div.

Así que mis preguntas son:

1.) ¿Se plantean problemas de seguridad para insertar el texto sin formato en la página web?

2.) ¿La página web (por lo que Gmail) puede detectar dicha inyección?

3.) ¿Es vulnerable a un Hombre en el ataque central?

Lo ideal sería que no quisiera que Gmail lo detectara y obtuviera el texto sin formato, especialmente cuando ahora conocemos el programa PRISM, pero si solo Gmail lo puede detectar y nadie más es bueno para un comienzo.

    
pregunta Kheil 02.07.2013 - 22:15
fuente

2 respuestas

3
  

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:

  1. 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.

  2. Las máquinas cliente del remitente y / o el receptor pueden verse comprometidas: interceptar y transferir los datos descifrados mediante malware como troyanos.

  3. 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.

    
respondido por el e-sushi 03.07.2013 - 03:06
fuente
2
  1. Gmail filtra seriamente el contenido de los correos electrónicos mostrados para evitar ataques de XSS. Cuando comience a enviar correos electrónicos encriptados, debe ocuparse de estas cosas si inyecta datos proporcionados por el usuario en el contexto de Gmail. Esta tarea dista mucho de ser trivial, sugiero echar un vistazo a las soluciones de listas blancas como HTML Purifier .
  2. Si estamos hablando solo de la parte de inyección, Gmail necesitaría que se genere un código especial del lado del cliente para detectar el código inyectado. Sin embargo, Gmail teóricamente podrá detectar que estás enviando datos encriptados al lado del servidor (según los metadatos que generas para tu solución o simplemente mediante la medición de la entropía), y utilizar esta información para indicar que la inyección de código probablemente tendrá lugar. Quizás pueda usar algún tipo de esteganografía pero tenga en cuenta que los servicios de inteligencia son realmente inteligentes.
  3. Basándose en el segundo punto, Gmail (NSA, Big Brother, el pirata informático que se hizo cargo de Gmail, etc.) tendrá formas de detectar el hecho del cifrado y siempre que vuelva a colocar el texto sin formato en origin , tendrán formas de leerlo.
respondido por el buherator 02.07.2013 - 23:04
fuente

Lea otras preguntas en las etiquetas