Continuámos con el análisis de seguridad a la web de P.C. Green. Si te perdiste las entregas anteriores, las tienes accesibles desde aquí.
Hoy hablaré sobre como potencialmente podemos enviar correos electrónicos a terceros, usando su propia infraestructura.
Si accedemos a la página de contacto de P.C. Green, accesible desde www.pcgreen.com/wac2/webtemplates/m2/index.asp?trg=Comments.asp, o tal y como vimos el otro día, directamente por www.pcgreen.com/wac2/webtemplates/m2/Comments.asp, veremos que se nos presenta el conocido formulario de contacto.
Es en general una buena idea implementar este sistema en nuestros desarrollos en vez del típico mailto. Por un lado, no es necesario que el usuario tenga configurado ningún cliente o cuenta de correo en su equipo para ponerse en contacto con nosotros. Por otro lado, protegemos el buzón de email de destino de arañas spammers, y malos usos.
Échemos un vistazo al código fuente de la página, a ver que hay… ¡Horror! Es simplemente un form HTML, que utilizando el método POST manda los parámetros a un enviador de correos genérico situado en www.pcgreen.com/wac2/scripts/incSendMail.asp.
Si os fijais, se establece en un campo hidden, el buzón de destino, para más pistas, se le asigna el descriptivo nombre de To.
En efecto, vuestros pensamientos van en la linea correcta: Entonces si conseguimos duplicar ese formulario, cambiando el valor del campo To, ¡podríamos enviar emails anónimos a quien quisiéramos!
Pero bueno, no sería mejor, dejar que el propio usuario fuera el que especificase ¿a quien se lo quiere mandar?
Afortunadamente para ellos, el script de envío de emails parece ser que no funciona, con lo que no corren peligro. Hacer que no se entreguen los emails, es sin duda el segundo mejor sistema de protección contra usos mal intencionados. El primero, sería evidentemente, eliminar toda opción posible de contacto.
Como comentaba el otro día, esta amenaza quedaría resuelta simplemente comprobando los parámetros de entrada que recibe cada página.
En este caso concreto, quiero ir un poco más allá, y haceros ver, que si tenemos una infraestructura de software y hardware que nos permite alojar una web con bastantes visitas como es esta, gestionar una base de datos SQL Server (esto lo tocaremos en la futura entrega de SQL Injection), y además hemos tenido el dinero suficiente como para desarrollar una aplicación de esta complejidad, ¿verdad que no tiene sentido utilizar un script de envío de emails genérico?
Hubiera sido muchísimo más conveniente crear uno a nuestra medida, que los entregase a la dirección de correo que quisiéramos. No son ni 20 lineas de código, y así evitaríamos tener que publicar la dirección a donde se envían los correos en el código HTML.
Tal vez sea muy malpensado, y claro, si queremos reutilizar esa página para que se puedan enviar diferentes tipos de email, y a diferentes buzones, y desde diferentes sitios, lo mejor sería disponer de un script genérico, al que pasándole los parámetros necesarios, se encargara de enviarlo. Casualmente en P.C. Green el acceso de Trabaja con nosotros, apunta a otro formulario de contacto ubicado en www.pcgreen.com/wac2/imagesshop/pgreen/form.htm. Ahora podremos salir de dudas.
¡Vaya! que curioso, este formulario utiliza otro script genérico para enviar emails, el situado en 212.9.68.21/correo/EnviarCorreo.asp, y que por tanto, a pesar de intentar ser de uso general, es diferente al anterior.
Podríamos volver a repetir el proceso comentado anteriormente, pero os ahorraré los pasos, y os diré que en este caso los emails ¡si que se entregan!
La ventaja añadida de este nuevo formulario es que nos permite "configurar" además de la dirección de destino, también la del remitente, el asunto, y una URL a la que llevar al usuario dándole las gracias.
Los errores, son los mismos que ya he comentado anteriormente, aunque agravados por el hecho de que además es todavía más genérico, y no se comprueba nada en absoluto.
Por hoy esto es todo. No perderos las próximas entregas, porque ¡todavía quedan muchos puntos por comentar!
