Hi Folks!
We're facing a growing amount of automatically generated HTTP POST requests, all containing spamvertising links like http://19.altribeati.com/homoerectus/
As far as i know, there are the following ways to handle that:
a) Spamfilter of recipient shall filter that
b) Web-user has to enter a unique number (generated image) in the form to prove, he's a human being.
c) Badword-Filtering in the formmail-script, some reqular expressions a.s.o.
Does anyone out there has better ideas? How have you solved that problem?
Best wishes, Matthias
_________________________________________
mhs @ internet AG Zürcherstrasse 204, CH - 9014 St. Gallen Phone +41 71 274 93 93, Fax +41 71 274 93 94 http://www.mhs.ch _________________________________________
Hi Folks!
We're facing a growing amount of automatically generated HTTP POST requests, all containing spamvertising links like http://19.altribeati.com/homoerectus/
As far as i know, there are the following ways to handle that:
a) Spamfilter of recipient shall filter that
What about implementing a spam filter on your host? formmail should call sendmail -i -t. You should be able to do a pre-queue filtering (with milter or with postfix pre-queue filtering with amavis) to prevent the mail from being sent.
Regards. Jean-Pierre
Matthias Hertzog wrote:
Hi Folks!
We're facing a growing amount of automatically generated HTTP POST requests, all containing spamvertising links like http://19.altribeati.com/homoerectus/
As far as i know, there are the following ways to handle that:
a) Spamfilter of recipient shall filter that
Thus you want to be a spam source? :) Listing this as option Z would give you some credit as simply having thought of it, having it as option A though doesn't give you the benefit of the doubt...
b) Web-user has to enter a unique number (generated image) in the form to prove, he's a human being.
Captcha's are easily defeated. But they indeed deter a bit. See http://sam.zoy.org/pwntcha/ for more details. There have been people claiming that it is discrimination against folks who have bad sight/blind etc as they won't be able to complete it. But one can then easily claim that Flash also falls in that slot ;)
c) Badword-Filtering in the formmail-script, some reqular expressions a.s.o.
Effectively what you want to do is run SpamAssassin over the submitted content.
Does anyone out there has better ideas? How have you solved that problem?
What about not having stupid scripts like formmail!? There are only very few cases where this can be useful and in those cases the destination address should be fixed. Then at least the person who is using the script gets the crap and not other people.
There was a similar question on NANOG last couple of days, where somebody was wondering how to block the webcafe's downstream from spamming: top it at the source. In your case that is clearly the formmail.
Greets, Jeroen
Jeroen Massar wrote:
Matthias Hertzog wrote:
Hi Folks!
We're facing a growing amount of automatically generated HTTP POST requests, all containing spamvertising links like http://19.altribeati.com/homoerectus/
As far as i know, there are the following ways to handle that: Does anyone out there has better ideas? How have you solved that problem?
What about not having stupid scripts like formmail!? There are only very few cases where this can be useful and in those cases the destination address should be fixed. Then at least the person who is using the script gets the crap and not other people.
There was a similar question on NANOG last couple of days, where somebody was wondering how to block the webcafe's downstream from spamming: top it at the source. In your case that is clearly the formmail.
Even some badly written scripts with fixed recipients have been abused in the past - seen and fixed lots of em on my server
Often they insert a reply-to or from header in the mail containing the senders e-mail If this field isn't properly validated it's very easy to send thousands of spams with header injection.... So don't feel so safe if you use fixed recipients...
One thing I have been pretty successful in blocking spam is javascript... Of course one can argue not all browser support or execute JS but today when every 3rd site completely relies on JS this is no valid point anymore IMHO I use a onSubmit script which sets a variable before submitting. only if this value is received correctly in the script the form is processed...
Matt
Salut,
On Tue, Aug 15, 2006 at 06:19:21PM +0200, Matthias Keller wrote:
One thing I have been pretty successful in blocking spam is javascript... Of course one can argue not all browser support or execute JS but today when every 3rd site completely relies on JS this is no valid point anymore IMHO I use a onSubmit script which sets a variable before submitting. only if this value is received correctly in the script the form is processed...
Do you really think a spammer will sit in front of his browser typing in all the spam? Those are scripts, and these scripts just send you data without ever considering to look at your JavaScript foo.
Tonnerre
Tonnerre LOMBARD wrote:
Salut,
On Tue, Aug 15, 2006 at 06:19:21PM +0200, Matthias Keller wrote:
One thing I have been pretty successful in blocking spam is javascript... Of course one can argue not all browser support or execute JS but today when every 3rd site completely relies on JS this is no valid point anymore IMHO I use a onSubmit script which sets a variable before submitting. only if this value is received correctly in the script the form is processed...
Do you really think a spammer will sit in front of his browser typing in all the spam? Those are scripts, and these scripts just send you data without ever considering to look at your JavaScript foo.
Correct. And that's the way it works :) consider this: <form method="POST" action="post.php" onSubmit="this.somefield.value=123"> <input type=hidden name="somefield" value=""> ... </form>
If the post.php receives the POST request without $_POST["somefield"] == "123" it refuses to send the mail...
Since the scripts won't interprete javascript they wont send the 123 as a value for somefield and thus all their tries wont succeed
Matt
Salut,
On Tue, Aug 15, 2006 at 06:59:21PM +0200, Matthias Keller wrote:
Correct. And that's the way it works :) consider this:
<form method="POST" action="post.php" onSubmit="this.somefield.value=123"> <input type=hidden name="somefield" value=""> ... </form>
If the post.php receives the POST request without $_POST["somefield"] == "123" it refuses to send the mail...
And what if they do send the 123?
Tonnerre
Tonnerre LOMBARD wrote:
Salut,
On Tue, Aug 15, 2006 at 06:59:21PM +0200, Matthias Keller wrote:
Correct. And that's the way it works :) consider this:
<form method="POST" action="post.php" onSubmit="this.somefield.value=123"> <input type=hidden name="somefield" value=""> ... </form>
If the post.php receives the POST request without $_POST["somefield"] == "123" it refuses to send the mail...
And what if they do send the 123?
They wont
Because that would need some user interaction upon collecting the data at the first time. And just in CASE they would start with it - no worries, you can always make it more dynamic.. consider using some formula which involves the current day which gets calculated on the client AND on the server side or whatever...
As long as they dont evaluate the javascript VERY regularly they cant spam - and i dont think they'll go so far as to executing JS as it's lots more complicated than just capturing form data and is potentially dangerous (infinite loops and stuff)
As you said - these are SCRIPTS and as soon as you start to require something not doable by scripts you make it MUCH harder for them.
Matt
@MK: Your method implies, that the user has a javascript enabled browser, else the post would fail. This means in the end you loose customers, because they're surfing with lynx.
Peter
On 8/15/06, Matthias Keller hostmaster@mindblow.ch wrote:
Tonnerre LOMBARD wrote:
Salut,
On Tue, Aug 15, 2006 at 06:59:21PM +0200, Matthias Keller wrote:
Correct. And that's the way it works :) consider this:
<form method="POST" action="post.php" onSubmit="this.somefield.value=123"> <input type=hidden name="somefield" value=""> ... </form>
If the post.php receives the POST request without $_POST["somefield"] == "123" it refuses to send the mail...
And what if they do send the 123?
They wont
Because that would need some user interaction upon collecting the data at the first time. And just in CASE they would start with it - no worries, you can always make it more dynamic.. consider using some formula which involves the current day which gets calculated on the client AND on the server side or whatever...
As long as they dont evaluate the javascript VERY regularly they cant spam - and i dont think they'll go so far as to executing JS as it's lots more complicated than just capturing form data and is potentially dangerous (infinite loops and stuff)
As you said - these are SCRIPTS and as soon as you start to require something not doable by scripts you make it MUCH harder for them.
Matt _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
And what if they do send the 123?
They wont
they will - i've seen some spammers really trying to analyze some feedback forms, etc. - next day the customer "fixed" it somehow, and the spammer found out again how to circumvent it.
for the php users i've found a solution where i patched tha mail() function to not allow linefeeds etc. in header and to: lines. i've documented it some time ago here: http://wiki.hidden.ch/index.php/PHP#Patch_von_mail.c_f.FCr_mail.28.29-funkti on
(i'm not telling you that THIS is the solution, but it helped a lot if you do hosting and have some dummy users ;-))
but also for me: the correct way to suppress such spam is directly at the source (in this case the formmail/mailer/whatever script). this can be some session tricks, captchas (btw: http://sam.zoy.org/pwntcha/ is really impressive; seems that spammers have the knowledge to circumvent captchas) are ways to "harden" your script.
-steven
Salut,
On Tue, Aug 15, 2006 at 11:39:15PM +0200, Steven Glogger wrote:
for the php users i've found a solution where i patched tha mail() function to not allow linefeeds etc. in header and to: lines. i've documented it some time ago here: http://wiki.hidden.ch/index.php/PHP#Patch_von_mail.c_f.FCr_mail.28.29-funkti on
The good thing about PHP's builtin input sanitizing and security functions is that they contain the majority of bugs. mail() is one of them. ;-)
Tonnerre
On Wed, Aug 16, 2006 at 07:29:25AM +0200, Tonnerre LOMBARD wrote:
The good thing about PHP's builtin input sanitizing and security functions is that they contain the majority of bugs. mail() is one of them. ;-)
I will never recommend PHP to a customer or even a friend; however I heard about an Apache module (by SuSE apparently) which is designed as a security layer for mod_perl and mod_php. I haven't even tried it yet, but I will the next time I need to support others' bad decisions.
I will never recommend PHP to a customer or even a friend; however I heard about an Apache module (by SuSE apparently) which is designed as a security layer for mod_perl and mod_php. I haven't even tried it yet, but I will the next time I need to support others' bad decisions.
If you know what you are doing and develop PhP application with security in mind from the first moment, 95% of all potential PhP exploits can be avoided.
Absolutely strict, brutal and dictatoric input validation as a first action of the application is a must in any PhP project. Only variables explicitly allowed to pass should be passed and checked at least for their data types and sizes. Plus additional checks if needed. The CPU cost of such checks are fairly low.
On a sidenote: mail() is not very optimal solution for mailings anyway, full SMTP stack implementations such as PHPMailer are better, although not exploit free solution.
Salut,
On Tue, Aug 15, 2006 at 05:35:26PM +0200, Matthias Hertzog wrote:
b) Web-user has to enter a unique number (generated image) in the form to prove, he's a human being.
The problem here is that spam bots are apparrently exceptionally good already at reading these characters out of the picture. In fact, they are even better than the average human reader, that's at least my experience.
Also note this screenshot to the topic:
http://www.thedailywtf.com/images/200608/look_harder.JPG
Tonnerre
Matthias Hertzog wrote:
b) Web-user has to enter a unique number (generated image) in the form to prove, he's a human being.
Works fine, but you think of the visually impaired. There are captchas which provide the number also as sound. But I wouldn't use captchas on business websites, it's to annoying for the users to type in the number.
c) Badword-Filtering in the formmail-script, some reqular expressions a.s.o.
Often it helps if you give the fields "unsuspicious" names. "meinfeld4" instead of "recipient" and so on...
I use mod_security [1] with the rules from gotroot.com. mod_security blocks the spam before the form gets processed. Additionally, it protects the server from SQL-injection and other attacks.
Greets, Manuel
On Tue, 2006-08-15 at 17:35 +0200, Matthias Hertzog wrote:
We're facing a growing amount of automatically generated HTTP POST requests, all containing spamvertising links
We are also struggling with this issue, but not only since a few days or weeks. I get 3-6 abused forms each day!
IMO it's the 'programmers' fault, who should parse the rubbish, which his form receives. Here two cool links (sorry, in german):
http://www.heise.de/security/artikel/66815 http://forum.jswelt.de/tutorials-php/28074-spam-ueber-kontakt-formulare-verh...
Cheerz - Dan
One that is less cumbersome than the "type in the word in the weird image" approach is to set a cookie-like hidden parameter from the server when it generates the form (I'm assuming php or perl behind a dynamic server). In the cookie you can put the timestamp and encode the thing using a simple cipher. When you get the cookie back, you check whether the timestamp is within a reasonable range. The spambot would have to refetch the original form, insert his crap and resubmit it, since it's not able to generate the hidden parameter on its own. Most (all?) won't do that.
Cheers, Markus
Markus Wild wrote:
One that is less cumbersome than the "type in the word in the weird image" approach is to set a cookie-like hidden parameter from the server when it generates the form (I'm assuming php or perl behind a dynamic server). In the cookie you can put the timestamp and encode the thing using a simple cipher. When you get the cookie back, you check whether the timestamp is within a reasonable range. The spambot would have to refetch the original form, insert his crap and resubmit it, since it's not able to generate the hidden parameter on its own. Most (all?) won't do that.
Well, IMHO this is no better than my solution using JS What do you do if someone has cookies disabled? I for my part often reject cookies 'just because' when I dont feel they're really needed... So I dont know which part of all surfers is bigger, those with lynx or those with js disabled Actually in the last 7 day there wasn't a SINGLE lynx hitting ALL of my hosted domains...
But of course this is always a matter of opinion and it can vary a lot depending on the website. But IMHO if a user using lynx cant add an entry to a guestbook this is no big loss for me...
Just my 2c
Matt
About that lynx discussion...
I don't think you're losing a single customer because your websites don't support lynx. Usually people want to see a picture of the product they're buying. And then there's the aspect, of who your target-market is. Usually it's not the Linux-Geek (and even if it is, you're better off to sell stuff with images - see thinkgeek.com).
Cheers, Viktor
Matthias Keller wrote:
Markus Wild wrote:
One that is less cumbersome than the "type in the word in the weird image" approach is to set a cookie-like hidden parameter from the server when it generates the form (I'm assuming php or perl behind a dynamic server). In the cookie you can put the timestamp and encode the thing using a simple cipher. When you get the cookie back, you check whether the timestamp is within a reasonable range. The spambot would have to refetch the original form, insert his crap and resubmit it, since it's not able to generate the hidden parameter on its own. Most (all?) won't do that.
Well, IMHO this is no better than my solution using JS What do you do if someone has cookies disabled? I for my part often reject cookies 'just because' when I dont feel they're really needed... So I dont know which part of all surfers is bigger, those with lynx or those with js disabled Actually in the last 7 day there wasn't a SINGLE lynx hitting ALL of my hosted domains...
But of course this is always a matter of opinion and it can vary a lot depending on the website. But IMHO if a user using lynx cant add an entry to a guestbook this is no big loss for me...
Just my 2c
Matt _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Markus Wild wrote:
One that is less cumbersome than the "type in the word in the weird image" approach is to set a cookie-like hidden parameter from the server when it generates the form (I'm assuming php or perl behind
Well, IMHO this is no better than my solution using JS What do you do if someone has cookies disabled?
I said "cookie-like", not cookies:
<input type="hidden" name="yourgrandmother" value="some encrypted hash">
with "some encrypted hash" being some encrypted (and binhex64 encoded) serialized record containing the sending IP, a timestamp and whatever else you fancy including.
Cheers, Markus
On Tue, Aug 15, 2006 at 05:35:26PM +0200, Matthias Hertzog wrote:
We're facing a growing amount of automatically generated HTTP POST requests, all containing spamvertising links like
We all do...
a) Spamfilter of recipient shall filter that
If you are the only recipient and your spamfilter is good... but it doesn't take the load off the server and the net.
b) Web-user has to enter a unique number (generated image) in the form to prove, he's a human being.
Quite a problem to keep accessibility for blind users.
c) Badword-Filtering in the formmail-script, some reqular expressions a.s.o.
I prefer bayes filtering for that. My way to do it is available at https://sourceforge.net/projects/spfgb (public domain). I used it for a guestbook but the system can be adapted (Quit ugly code yet, but working quite well!).
Regards Peter
-
Daniel Kamm -
Jean-Pierre Schwickerath -
Jeroen Massar -
Kirill Ponazdyr -
Manuel Krummenacher -
Markus Wild -
Matthias Hertzog -
Matthias Keller -
Peter Guhl -
Peter Stockli -
schaefer＠alphanet.ch -
Steven Glogger -
Tonnerre LOMBARD -
Viktor Steinmann