Spam via PHP – Mejoras a mail() en 5.3.0

Como ya todos los que tienen un sitio, o trabajan en una empresa de webhosting, saben, si no se implementa bien, el uso de la funcion mail() puede ser abusada por atacantes para enviar spam y otras porquerias.

Desde PHP 5.3.0 estan disponibles dos opciones de configuracion (via php.ini, ini_set() o via apache php_value) piolas. Una, mail.add_x_header, agrega una cabecera X-PHP-Originating-Script a cada mail saliente, indicando UID y path al script que generó dicho mail.

La otra, mail.log, hace que php grabe, justamente, un registro del uso de la funcion mail.

Piola, no? Así que esten atentos a la salida de 5.3.0 (o mejor, 5.3.x, jej).

Artículos relacionados:

Si te gustó este articulo, ¿ Porque no dejas un comentario a continuación y continuas la conversación, o te suscribes a los feeds y recibes los artículos directamente en tu lector?

Comentarios

En realidad ya viene un parche para eso desde la 4.X , en mi caso exim marca tambien los uid, scripts con path, usuarios y quien envia (aparte de esto es un buen agregado)

Pasanos un ejemplo de que exim haga eso… porque si no lo provee PHP (o el lenguaje de scripting que se use, o el propio apache) el exim no va a saber nada mas que lo obvio.

Por otra parte, el parche que menciones: obvio que da vueltas hace rato, pero lo interesante son cosas que ya pasan a ser mainstream, y no que se necesiten compilar a mano… una cosa es un servidorcito estatico o embebido, donde lo armas como se te canta, y otra cosa son fedoras y otras cosas asi para cpanels, y eso…

Aunque, por otra parte, si el exim de puta casualidad levanta esa data al ser el sendmail o inject ejecutado como un child via mail()… entonces si podria levantar algunos datos extra, pero seria muy dependiente de la implementacion. Por eso me suena raro. Quiero ver esos headers, bet0x, please.

mail() sirve para cosas chicas, después tenés librerías como Swift mailer que se comunican directamente con el MTA y ahí se te terminó el rastreo, al menos del lado de PHP.

Si, pero justamente de esas ‘cosas chicas’ los atacantes se aprovechan… nunca falta el web developer que dice ‘bue, hago este formulario de contacto asi nomas con mail y sin cuidar mis inputs ni headers ni nada’ y asi es abusado despues.

Hay que prestar atencion a los nuevos ataques!

Perdon Buanzo, me re colgue con lo que tenia que pasar, si no lo tenes resuelto decime a que email te lo envio.

Saludos

Sorry, the comment form is closed at this time.