RE: [swinog] Formmailer-Scripts and Spam
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... java script is client side. it only prevents that a form can be submittet. what if you circumvent that and post directly? as we know, simulating a post ist quite easy: telnet to host port 80: POST /superposter/gna.php HTTP/1.1\r\n Host: www.blabla.ch \r\n User-Agent: whatever you want\r\n Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai n;q=0.8,image/png,*/*;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n Connection: keep-alive\r\n Referer: www.blabla.ch/urli/index.php Cookie: PHPSESSID-111\r\n Content-Type: application/x-www-form-urlencoded\r\n Content-Length: 100\n \r\n action=loginnick=usernamepassword=passwordsubmit=LOGIN \r\n if you get that you cannot check if he used your javascript or not ,-) he might check your session-id, but what if the client gets a session id and uses that one to fill in the form. that soo easy :-) (i'm using such a tool as a proxy for an online game since about 5 years ,-)) -steven ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
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 ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
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 ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
Glogger Steven wrote: 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... java script is client side. it only prevents that a form can be submittet. what if you circumvent that and post directly? as we know, simulating a post ist quite easy: telnet to host port 80: POST /superposter/gna.php HTTP/1.1\r\n Host: www.blabla.ch \r\n User-Agent: whatever you want\r\n Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai n;q=0.8,image/png,*/*;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n Connection: keep-alive\r\n Referer: www.blabla.ch/urli/index.php Cookie: PHPSESSID-111\r\n Content-Type: application/x-www-form-urlencoded\r\n Content-Length: 100\n \r\n action=loginnick=usernamepassword=passwordsubmit=LOGIN \r\n if you get that you cannot check if he used your javascript or not ,-) he might check your session-id, but what if the client gets a session id and uses that one to fill in the form. that soo easy :-) (i'm using such a tool as a proxy for an online game since about 5 years ,-)) you still didn't get the point Look at my post from 15.08.2006 18:59 I dont prevent a user from sending the form - I know this is pointless But rather I use JS to write some (optionally dynamic) value into the form before sending. If that value isn't present in the POST request the formmailer script refuses to send the mail. This effictively defeats any non-JS-aware machine including spammers, robots and lynx. Like i said earlier this can be combined with dynamic data close to what Markus Wild also said for example by using some varying string containing a timestamp or something like that. This is a step more effective than Markus' idea with the session as it not only requires to gather a very up2date version of the form but additionally the execution of JS You could write a function which calculates the value so you can't just easily copypaste it out and so on.. The forms I'm using this on have not ever been abused anymore since the introduction of the JS-Check since it would really require massive user interaction Matt ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
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. -- Kirill Ponazdyr Technical Director Codeangels Solutions GmbH Tel: +41 (0)43 844 90 10 Fax: +41 (0)43 844 90 12 http://www.codeangels.ch http://www.codeangels.com ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Formmailer-Scripts and Spam
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 _ ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
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 pgpht7RgWaJ19.pgp Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
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 ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
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 pgpUgWzuBczlI.pgp Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
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-verhindern.html Cheerz - Dan ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
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 ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
@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 [EMAIL PROTECTED] 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 -- Confidentiality Note: This message is intended only for the use of the named recipients and may contain confidential and/or privileged information. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorized use of the information contained in this message is prohibited. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
