homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Hardware and OS Related Technologies / Website Technology Issues
Forum Library, Charter, Moderators: phranque

Website Technology Issues Forum

Subscription form attack
What to do when someone abuses your "confirm mail" facility?

 1:36 pm on Oct 27, 2002 (gmt 0)

We are using a *nix/Perl program called Post Office Pro 4.0 for administrating subscriptions and mailings for our newsletters. It has its quirks, but mostly does what it is supposed to do. The program has never been misused by hackers trying to use our mail gateway to send out spam.

In order to stop people form signing up other subscribers than themselves, we have implemented an autoresponder that sends subscribers an confirmation request mail. Subscribers have to click on a special link in this mail to be added to the database.

During the last couple of weeks someone has started using this feature to send a large number of confirmation mails to various existing and non-existing AOL addresses, i.e. they fill in the form repeatedly with the same AOL address, and our program faithfully sends a confirmation request mail to these addresses. Needless to say, our mailbox is filled with AOL error messages, and we have got complaints from AOL members getting dozens of such confirmation request mails from us.

We are having difficulties seeing why someone would abuse our system in this way. It could be that we have enemies we do not know of, people who are trying to get our IP addess banned from AOL, but that's a wild guess.

We have checked our logs and do find the relevant mailings. Here's one example (we have altered the name of the newsletter): - - [23/Oct/2002:12:39:53 -0600] "GET /cgi-local/post/manager.pl?email=453ergd@aol.com&group1=Name_of_newsletter HTTP/1.0" 200 11714 "-" "-"

The IP address changes every now and then:, etc.

First of all: Are there anyone of you who have experienced anything similar?

Also: Is there a way to stop such abuse?

We are grateful for any comments.



 3:33 pm on Oct 27, 2002 (gmt 0)

And not getting AOL visitors is a *bad* thing?

Most of my suggestions assume you can control the behaviour of the program in some way or other...

1) If the IP is pretty consistent for a number of requests and then changes why not consider putting in a rule which says a single IP can only ask for a signup once per N hours?

2) Have you tried reverse dns lookups or whois on the names to figure out if they are all from the same organisation or potentially coming through proxies, or if you put each ip into your browser do you get a website appearing? (In other words can we see a pattern? If so you might be able to stop them)

3) If all else fails add an extra stage before you send that mail - create random text in an image and ask the user to enter the text then submit the form. As only humans can see the text and write it down this will stop the bots.

4) If you make any forms use the POST method rather than the GET method it makes programming stuff to mess with them a fair bit harder. (Trust me on this one - a monkey can program a bot to do GETs but it takes a lot more effort to program a bot to do POSTs)

5) Make the script which sends data to the mail-out script generate a one-way hash (md5?) of the input data. Next make the mail-out script check this hash against the input data, if the do not match then do nothing. As long as you use a combination of input elements and fixed text when you generate the hash then it will make it really hard for them to fake that hash!

- Tony

[edited by: Dreamquick at 3:43 pm (utc) on Oct. 27, 2002]


 3:43 pm on Oct 27, 2002 (gmt 0)

You can stop it but it will require some modification to the script. One way you could stop the abuse is to encode each E-mail address.


Subscriber submits E-mail address. Script encodes E-mail address and passes the encoded variable to the autoresponder. Subscriber confirms subscription by clicking on the link in the confirmation E-mail. Script decodes E-mail address and verifies it's authenticity.



would look like:


Everything else gets tossed.


 3:51 pm on Oct 27, 2002 (gmt 0)

4) If you make any forms use the POST method rather than the GET method it makes programming stuff to mess with them a fair bit harder. (Trust me on this one - a monkey can program a bot to do GETs but it takes a lot more effort to program a bot to do POSTs)

A perl monkey´s GET request:

$ua->request(GET 'http://www.ac.com/?age=14&cool=yes');

A perl monkey´s POST request:

$ua->request(POST 'http://www.ac.com/', [age=>14, cool=>'yes']);

Not that much more of an effort ;)



 3:57 pm on Oct 27, 2002 (gmt 0)

...and there I was adding my #5 when you beat me to the punch key master!

Personally I prefer adding a one-way hash rather than a simple encoding scheme as there are only so many common encoding techniques around and theoretically you could just scan them all until you broke the scheme you were using (since encoding is a two-way process rather than just one-way so you can get the data out of it if you know what you are doing).

Also I kind of like the idea of messing with their heads by making it very clear what the new protection scheme is because I know full well that unless they got access to the source they will not be able to crack it without a great deal of effort. :)

- Tony


 4:05 pm on Oct 27, 2002 (gmt 0)


I turn my back to make a counter post and someone finds a fault in my logic - it shows that I'm not a perl user don't it? :)

You're absolutely right that POST requests are *really* easy if you know how (or have good toys), but due to the seemingly aimless nature of what they are doing I wouldn't class them as professionals and so I thought it was more likely to be a simple bot / script which would be limited to GET requests without some changes to the code.

- Tony

[edited by: Dreamquick at 4:08 pm (utc) on Oct. 27, 2002]


 4:08 pm on Oct 27, 2002 (gmt 0)

You can scramble or add varibles to an encoded E-mail address to make it virtually impossible to crack. I added a check variable to the example in my previous post. Can anyone tell me what it was (it's pretty simple).

But, I think I misread perkoch's original question. We need to eliminate multiple submissions to the same page. I think a simple cookie would do the trick. Simply put- no cookie, no treat and only one treat per cookie.


 4:12 pm on Oct 27, 2002 (gmt 0)

{dreamquick raises his hand}

Ohhh! Me Sir! Me Sir!

Did you turn the characters into their hex values and also add a counter onto the end containing the number of characters?

Other answers to the orignal question include logging the email addresses being used and denying repeat emails for X hours - personally I wouldn't trust cookies to provide me with a sense of security, especially if the attackers know their stuff.

There are moments like this when I think an official IRC channel for certain forums would be a really good idea. Real-time conversation rather than post, read, reply delays.

- Tony


 8:46 am on Oct 28, 2002 (gmt 0)

Thank you all! While we were sleaping on the other side of the Globe, you have been coming up with all these great suggestions! We will bring the suggestions to the attention of the people who make the program we use and I am sure we will be out of the woods in no time.


 9:40 am on Oct 28, 2002 (gmt 0)

perkoch you say it is to maintain and sign up subscribers to a newsletter and that:

"they fill in the form repeatedly with the same AOL address"

Surely some improvement in the back end would solve this, for example only one request for inclusion to any email address * ever * repeated requests are denied.

Plus perhaps log IP and program id for each request into a db to gain evidence on perps ... look for duplicates and select .. then contact their ISP with evidence and get their dial ups removed.

Global Options:
 top home search open messages active posts  

Home / Forums Index / Hardware and OS Related Technologies / Website Technology Issues
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved