¿Es posible que una dirección de correo electrónico válida (algo que funcionaría si se usara enviar a gmail, para distintas definiciones de válido (el correo electrónico se recibiría no para el exploit)) contenga un javascript que pueda explotarse si se procesa y la salida? no está saneado (codificado adecuadamente)? Si es así, por favor proporcione un ejemplo.
Yo diría que en teoría (y prácticamente, según su función de saneamiento), sí , la parte local de un correo electrónico se puede usar en los ataques XSS.
El problema es que las direcciones de correo electrónico son complejas y pueden incluir una serie de caracteres especiales. Además, las direcciones de correo electrónico ofrecen características como comentarios y cadenas citadas, que permiten aún más caracteres especiales.
XSS en la parte local de la dirección de correo electrónico
[Estoy usando el informativo rfc3696 , porque es mucho más agradable de leer que el oficial rfcs.]
La regla exacta es que cualquier carácter ASCII, incluidos los caracteres de control, puede aparecer entre comillas o en una cadena entre comillas.
Por lo tanto, una dirección de correo electrónico válida sería:
"<script>alert(1)</script>"@example.com
Puede probar su validez aquí . Esto obviamente no es seguro.
Posibilidades adicionales
Incluso sin las cadenas citadas, un atacante al menos puede acercarse:
Sin comillas, las partes locales pueden consistir en cualquier combinación de Caracteres alfabéticos, dígitos, o cualquiera de los caracteres especiales. ! # $% & '* + - / =? ^ _ '. {| } ~
Esto ya es suficiente para ingresar a un contexto javascript, por ejemplo:
<a href='mailto:USER_EMAIL'>email me</a>
a través de:
foo'onclick='alert'foo='@example.com
El problema aquí es que ( no está permitido, pero no estaría cómodo si imprimiera esto al usuario final sin codificar. Como mínimo, un usuario podría cambiar el estilo: foo'style='color:red'title='imImportant'@example.com .
También puede colocar la carga útil dentro de un comentario de la parte local, por lo que no se aplican las posibles restricciones de su proveedor de correo electrónico, por ejemplo: ("<script>alert</script>")[email protected] , donde [email protected] es su dirección de correo electrónico (aquí, las mismas reglas que las anteriores) apply - < y > solo pueden estar dentro de cadenas entre comillas; además, no puede tener ( y ) , incluso en cadenas entre comillas).
Y esto es solo sobre la parte local. La parte del dominio le da a un atacante vectores de ataque adicionales.
Defensa adecuada
Esta es la razón por la que la prevención XSS no debe ser sobre el filtrado, sino la codificación adecuada. Todos los caracteres peligrosos (en la mayoría de los contextos - pero no todos - estos son al menos% co_dede %, ' , " y < ) deben estar codificados en HTML cuando se envían a un usuario, sin importar qué filtro se haya aplicado de antemano.
Además de la excelente respuesta de Tim , Gmail implementa una Política de seguridad de contenido para evitar que cualquier secuencia de comandos que logre omitir sus filtros se muestre en navegadores compatibles .
Entonces, sí, mientras que una dirección de correo electrónico puede contener etiquetas "<script>alert('foo')</script>"@example.com Me sorprendería si Google no la codificara correctamente y, como se dijo, tienen el CSP para proteger a los usuarios si no lo estuvieran. Dicho esto, hubo un error reciente en la aplicación Gmail en Android , que permitió que las direcciones parecieran falsificadas a primera vista.
Lea otras preguntas en las etiquetas penetration-test exploit javascript