Sumário

• 1. Introdução
• 2. Mensagens enviadas por formulários
• 3. Mensagens enviadas por linguagens de conteúdo dinâmico

1. Introdução

Servidores Web podem ser abusados para enviar spam dependendo dos serviços disponíveis, portanto o administrador de sites também é responsável pela prevenção. As fontes de abuso mais comuns são o envio de mensagens através de formulários e funções de linguagens de geração de conteúdo dinâmico capazes de enviar e-mail.

Spam vindo de servidores Web são particularmente difíceis de combater, porque eles vem de MTAs legítimos, com fila e retransmissão, e com envelopes consistentes com o endereço IP, passando assim tanto por graylisting quanto por teste de SPF. Por conta disso a ação preventiva nestes casos é fundamental.

2. Mensagens enviadas por formulários

O caso mais conhecido de abuso de envio de mensagens por formulários é o do script CGI FormMail.pl, que envia o e-mail utilizando-se de informações vindas do formulário e que pode ser abusado para prover anonimato para um spammer.

Existem mecanismos automáticos de busca por formulários vulneráveis que, ao localizar páginas contendo formulários, analisam seus campos e submetem diretamente ao script CGI um e-mail para um endereço de teste. Se o CGI for vulnerável o endereço de teste receberá uma mensagem. Vale ressaltar que o spammer não precisa invadir o site, basta acessar diretamente a URL do CGI, com argumentos especialmente construídos.

Qualquer programa que envie e-mail a partir de um formulário, independente da linguagem em que é escrito, não deve receber o endereço de destino do próprio formulário, mas sim tê-lo como uma constante interna, inacessível ao usuário. Além disso, vale a regra de que qualquer programa deve validar todos os campos submetidos pelo usuário e tratá-los como potencialmente hostis.

Ao escrever esse tipo de script é fundamental tomar cuidado para que o conteúdo da mensagem, vindo do formulário, não injete linhas de cabeçalho no e-mail a ser enviado. Para evitar isso é aconselhável, após a construção do cabeçalho, que o script insira uma linha em branco contendo o par CRLF, e só então inclua o conteúdo da mensagem que veio do formulário.

Este cuidado deve ser redobrado em servidores de hospedagem de sites, onde o usuário pode, inadvertidamente ou não, utilizar um script vulnerável à exploração por spammers. Há relatos de spammers que contratam um serviço de hospedagem somente para ter uma plataforma para envio de spams.

É necessário que esses serviços possuam uma política bem definida em contrato sobre o envio de e-mails a partir do site hospedado. Também é interessante prever a possibilidade de auditorias com a intenção de localizar scripts vulneráveis, incluindo a análise de logs do MTA e do servidor Web.

3. Mensagens enviadas por linguagens de conteúdo dinâmico

A maior parte das linguagens de geração de conteúdo dinâmico possuem algum método para envio de e-mails. Estes métodos podem ser utilizados para envio de formulários e geração de alertas, entre outras funcionalidades. E, a exemplo dos scripts CGI, também podem ser abusados para o envio de spam. Um exemplo é a função mail() da linguagem PHP, disponível na grande maioria dos servidores que suportam essa linguagem.

Funções como essa podem ser abusadas de duas maneiras: ou o spammer contrata o serviço de hospedagem de sites e então disponibiliza seus programas ou ele compromete algum site e utiliza seu programa neste site.

Para evitar o abuso por parte clientes de serviços de hospedagem, aconselha-se possuir uma política de uso aceitável ou prever os termos de uso de serviços de e-mail em contrato, além de possuir informações cadastrais completas sobre o cliente, permitindo a identificação de possíveis spammers reincidentes.

Também é possível mitigar este problema com as seguintes providências:

• filtrar as mensagens vindas do servidor Web: normalmente o servidor Web chamará um MSA para fazer o serviço de envio da mensagem. No caso de uso de Sendmail e PHP, por exemplo, é possível configurar o sistema para que envie a mensagem primeiro para um filtro, ao invés de ir diretamente para o Sendmail. Deve ser configurada a variável sendmail_path do PHP, que apontará a mensagem para o filtro, este verificará se a mensagem obedece a uma política pré estabelecida e só repassará para o Sendmail aquelas mensagens que forem aprovadas. Este esquema, porém, pode ser driblado pelo acionamento direto do Sendmail real via popen() ou system();
  
  
• analisar bounces: muitos spams são enviados para listas de e-mails que contém endereços que não existem, gerando muitos bounces. A análise de bounces causados pelo servidor Web pode identificar o abuso por parte de um spammer;
  
  
• possuir um usuário para cada site hospedado: nem sempre isto é de fácil implementação, mas facilita a análise de logs do MTA e dos bounces recebidos;
  
  
• descredenciar o servidor Web junto ao MTA: não dar permissão para que o servidor Web utilize o MTA como relay, mesmo que seja o localhost. Deste modo, para poder enviar mensagens para domínios externos ele deverá se autenticar. Essa providência, entretando, pode impedir o funcionamento de programas legítimos e, também, permitir o envio de spam para domínios locais.

Do ponto de vista de quem recebe spam vindo de servidores Web há algumas características peculiares, mas que não devem ser usadas como único critério de bloqueio, pois podem gerar muitos falsos positivos:

• o MAIL FROM do envelope (conseqüentemente o campo Return-Path: do cabeçalho) apresenta um nome de usuário normalmente associado ao servidor Web, tal como nobody, wwwrun, apache, etc;
  
  
• há dois campos Received: no cabeçalho, um colocado pelo MTA de destino e outro pelo de origem, ao receber a mensagem do servidor Web. Este último normalmente mostra o endereço 127.0.0.1 como origem.

Ao receber um spam suspeito de ter sido gerado por um servidor Web é aconselhável contatar o responsável pelo servidor Web, normalmente acessível pelo endereço webmaster@domínio (de acordo com a RFC 2142 esse endereço deve existir). Caso esteja sendo recebido um volume muito grande de spams, pode-se considerar a inclusão das informações de envelope em uma lista de bloqueio.