Casi todas las organizaciones tienen alguna forma de hacerles llegar comentarios en la web. En algunos se trata de un simple ‘mailto:‘ pero en otros casos nos encontramos frente a un ‘formulario de contacto‘.

Por otro lado, quizá como un vestigio de la era pre-redes sociales, todavía siguen existiendo formularios de ‘envía a un amigo‘ en muchas páginas.

Quiero compartir aquí algunas experiencias con estos formularios que, si no se hacen bien, pueden presentar ciertos riesgos.

mailbox

El principal riesgo es la posibilidad de envío de correos desde las redes y servidores del afectado de forma automatizada hacia direcciones de correo arbitrarias. Otro riesgo consiste en saturar los destinatarios internos con múltiples consultas a través de estos formularios.

En el primer caso, se puede utilizar para realizar ataques de phishing, con la ventaja de que realmente los mensajes salen de un servidor ‘confiable’.

Veamos algunos errores a la hora de diseñar estos aparentemente inofensivos formularios.

No hay CAPTCHA

Si no hay CAPTCHA o algún mecanismo que limite el uso automatizado, podemos encontrarnos con las situaciones arriba descritas de saturación de buzones internos o, en el caso de que el formulario lo permitiese, envío automatizado de mensajes.

Muchos formularios no lo incluyen porque es un coñazo para el usuario descifrar el CAPTCHA, que cada vez lo ponen más difícil.

El CAPTCHA es repetible

Hay veces, que ya me he encontrado más de una, en las que el CAPTCHA es ‘repetible’. O sea, que el sistema te permite re-utilizar los mismos datos. Normalmente suele ir asociado a que almacenan un hash de la solución en el HTML. Esto es claramente inefectivo y se puede automatizar muy fácilmente.

Nunca se debe confiar en lo que envías al navegador. Siempre tiene que haber algún chequeo en la parte del servidor.

El destinatario puede elegirse

En en caso de ‘enviar a un amigo’, el destinatario puede elegirse y, el problema recae en hasta qué punto es posible manipular el contenido.

En el caso de un formulario de contacto, ya he visto varios en los que puedes elegir al destinatario porque se codifica en campos hidden del HTML.

Se pueden elegir múltiples destinatarios

En algunos casos es posible separar por puntos y coma varios destinatarios, lo que hace que aumentemos nuestros poderes de Spammers. Imaginaos que se puede enviar hasta 50 direcciones… pues os hacéis una idea del peligro, ¿no?

El servidor envía un mensaje automático al remitente

Hay veces que el servidor envía un mensaje automático al supuesto remitente. Como ahí puedes poner cualquier dirección ‘origen’, el resultado es que realmente le estás enviando un mensaje a quién tú quieras.

El contenido puede manipularse

Este es interesante en los formularios de ‘enviar a un amigo’ es importante asegurar que el remitente no puede controlar el texto a enviar. Por ejemplo, me he encontrado formularios que deja poner la dirección de correo origen y el nombre del remitente y lo mismo para el destinatario. En este caso, si no se limita el tamaño del nombre ni se filtra (véase el siguiente epígrafe) resulta que es posible insertar un texto considerable e incluso HTML.

Igualmente, he visto casos en los que el texto estaba en un campo hidden del formulario.

En los casos de formulario de contacto está claro que el contenido debe poder ser manipulado por el usuario, pero hay que tener cuidado en evitar que pueda modificarse el título del mensaje, por ejemplo. En muchos casos, se mete como un campo hidden en el código, por lo que mejoraría nuestra capacidad para crear mensajes falsos.

Se puede modificar el enlace a la página

A veces para el formulario es importante la página origen. Por supuesto en ‘enviar a un amigo’ lo es. En el contacto, puede serlo si se trata de alguna notificación respecto a la página.

En este caso, suele ocurrir que la página se envía en un campo adicional o se toma del Referer y en ambos casos, se puede manipular.

Si se trata de una URL completa, tenemos suerte y podemos sustituirla por otra.

Si se trata de una URL relativa, dependerá de si somos capaces de insertar o no HTML para añadir nuestro propio enlace (véase el siguiente epígrafe).

El contenido no se filtra

Si no se filtra el contenido (aunque sea el nombre del usuario, el enlace, el propio mensaje, etc.) nos encontramos con la posibilidad de introducir código HTML o incluso javascript.

El éxito dependerá de cómo lea el correo el destinatario. Si lo hace en el navegador con un sitio web no muy cuidadoso (o sea, no con Gmail) podemos tener suerte. No he probado demasiados sitios pero los que utilizan un servicio web propio suelen ser más laxos en este sentido.

Si controlamos el HTML podemos meter imágenes, iframes, enlaces, código para lanzar acciones cuando el usuario pase por encima, etc.

Se pueden enviar mensajes a usuarios internos

Una gracia de seleccionar la dirección de correo es que el que la resuelve es el servidor de aplicación. Por lo tanto, se puede intentar enviar correo a usuarios locales o a listas internas.

Por ejemplo root@localhost.localdomain me ha colado alguna vez. Y si conseguimos llenar el disco a base de mensajes…

No se monitorizan los mensajes

Los mensajes que envía el servidor de la aplicación no se monitorizan de forma habitual. Suele ocurrir que si alguien aprovecha estos inofensivos formularios para enviar Spam no se da cuenta nadie. A menos que los Spammers sean tan poco cuidadosos de no dejar de mandar mensajes a saco, en cuyo caso ya saltará alguna alerta de uso de la red o alguien avisará de que está recibiendo Spam o los meterán en algunas listas negras.

Pero en definitiva, no hay monitorización que permita detectar esto pronto.

Almacenamiento online del mensaje

Lo peor que he visto ha sido un formulario de contacto que no enviaba un correo, sino que guardaba el mensaje “sin filtrar” en una base de datos Notes (sí, no es broma) a la que podías acceder siempre que quieras con el identificador correspondiente y además, enviaba un mensaje al emisor.

Así que tenemos XSS almacenado más mensaje de la fuente fidedigna al usuario para que se lo crea del todo.

Sin palabras.

Concluyendo

Pensándolo bien, lo mejor es no tener ninguno de esos formularios. Para compartir, añadid los típicos botoncicos de las redes sociales y listo.

Y para contactar con la organización pues casi mejor el mailto: o también a través de las redes sociales. Todo lo demás es meterse en problemas y, por otro lado, molestar al usuario con CAPTCHAs.

Ah, por último, yo para hacer pruebas de estas cosas siempre uso Mailinator, un servicio que te permite usar cualquier cuenta de correo que se te ocurra (siempre con sus dominios) sin necesidad de registro ni de nada. Muy útil para registrarse en sitios y que no te manden publicidad y también para hacer pruebas de envíos de mensajes.