Plug-in: zem_contact_reborn

neptho · 2006-02-11 16:28:19

> doggiez wrote:

> Thank you all, neptho, tranquillo and Stuart, for all your efforts to get this right. I just don’t understand half of what is said, so can someone tell me in plain English what I should do? Should I take Stuart’s latest update, should I take neptho’s code, should I remove all contact forms from my sites or should I just shut up and sit and wait ;)

It’s really up to you, to be honest. My code is just a basic rewrite of Stuart’s which implements the same exact thing, but cleans up a few things. Basically, “It works here, but if it doesn’t work for you, let me know what you’re doinjg, and what it does.”

There may be an even simpler way around the whole thing in the end, but I want to ensure that variables are not poisoned at all. One of the simplest ones are using a cookie, rather than a POST, which is set on your computer, and tested before mail is ever sent. If it is NOT found, you have the option of either returning an error, or silently ignoring it. Passing a simple string in the browser which matches the string locally is somewhat easy if you directly invoke the contact.

Now, to make the contact set a cookie that can be REVERSED or matched via two keys, or even just an internal hash which is unique to every site – this would stop the spamming dead in it’s tracks – however, we need to make sure that the system itself is secured once more.

Simpler reply: Try it. If it breaks, you get to keep BOTH pieces!

-P- · 2006-02-11 17:27:11

Another thing regarding security. Sorry if it is a stupid question but I just learned this week to be bit afraid of form mail functions.

Is there any chance of increasing security risks if having two separate forms on a site? Off course it doubles the number of forms that some can use maliciously for spamming but is there a possiblity of making unknowingly some additional query conflicts or what they are called?

The situation could be that I have on one section the “default” contat form with fields name, email and message.

Then on the other section of the site I call second time zontact_reborn form but this time it is used to order a T-shirt. That form has fields name, email, phone, dropdown list with selection of color of the shirt and checkboxes regarding the preferred size (small, medium, large) of the T-shirt.

Any risks with it? Not to mention the ugly T-shirt. :D

<blockquote> > thebombsite wrote:

I’ve just finished a redesign for FreshlyPressed with a complex contact form. Have a look. </blockquote>

I just started building a quite complex contact form too, with several dropdown fields and checkboxes. Few things/suggestions/ideas came to my mind. And don´t get me wrong, I love totally contact_reborn as it is and I am happy with it. And I know you have more important stuff to take care about with security etc.

But here we go anyway. Everything is in a way could it be possible/is it a good idea

Ability to save data. So when there´s form with several required fields and some that are not required. Fields required are of course marked as but were only human. So you hit submit button, you get an error ´cause you forgot to fill all the required fields. That is very ok. But it loses (at least I think) also all the checkbox data etc. you submitted. So could these values be somehow remembered that user don´t have to fill all the data again?

Preview of the data before sending it. Could also make spam bots life more difficult? And would be nice feature for all of us who make lots of typos.

Ability to “style” the output in the actual email received. Meaning that output could contain “not visible areas” for example ones that you marked with legend.

Contact details
Name: P
Email: me@somesite.com

Food you like us to feed you
Soup: Yes
Pasta: Yes
Meat: No
Carrots: No

and more perfect would be if the ones that are not selected (Marked “no”), would not show at all. So the email just would contain fields that were selected and “lose” all the data that is not needed. With company sites for example I guess the services that client wants to have more info are data needed and the rest is trivial.

Last edited by -P- (2006-02-11 17:33:35)

thebombsite · 2006-02-11 19:54:23

Yes, as neptho suggests, there is no harm in testing both, as neptho’s code above will load as a separate plug-in.

@-P- Thanks for the suggestions. I definitely like the “preview” idea. We shall no doubt visit these soon but we are just concentrating on the security side at this point. Shouldn’t be long though. :)

els · 2006-02-12 20:32:08

If I use neptho’s plugin code, I get "to" address is missing. (It is not.)

Champak · 2006-02-13 03:31:47

Here is an idea I’ve put to work with aspects of my site for protection. Why don’t you format the plugin to disable certain keypresses. Ex. the “@” and the “.”. Have those keys inputted by buttons, and a script to detect that it is ONLY inputted from the button.

THEN

Have captcha back that up. If you really want to be paranoid, have the captcha inputted by buttons as well…but I think that would be overkill and annoying to people.

neptho · 2006-02-13 05:26:52

> doggiez wrote:

> If I use neptho’s plugin code, I get "to" address is missing. (It is not.)

Yeah. Just noticed that I base64 encoded the more paranoid version. Really, the problem is that there are no ‘set’ variables, so zem_contact tries to take anything passed to it as a variable=what setting. I fixed this one instance, but if you make custom forms, my patches just won’t work – because they take out the core of this basic ‘open and insecure’ design.

At this point, I’m giving up on fixing zem. Stuart, if you have questions, feel free to let me know. I’ll try to answer – I just don’t have the time or patience.

tinyfly · 2006-02-13 21:13:37

Are the spam problems a result of adding the ‘send article’ functionality?

‘Send article’ gives a user or bot the ability to send mail to anyone, where with the normal contact form only mail gets sent to whoever is set in the ‘to’ attribute.

If this is so, would it be possible to pull this functionality out into a seperate plugin? Maybe using the new API.

alannie · 2006-02-13 21:49:12

I am also wondering if the spam problems could be prevented by providing an option to build contact forms that output variables to only the body of the email, and not to the header? Right now, zem_contact_reborn doesn’t allow me to specify that the “From” address be a static address and not the sender’s email address (a header variable that could be exploited). Yes, there’s a “from” attribute, but it still inserts the sender’s email address into the “Reply-To” field, thus easily allowing injection of exploitative code into the header.

cgiemail has similar vulnerabilities, and this tactic of not putting ANY variables in the header is recommended for cgiemail users. Could this work for zem_contact_reborn too?

roelof · 2006-02-13 22:54:13

hello,

maybe a stupid questuin but i use this plugin for my site and now i want to use css with this plugin.
What classes and so on can i use in my css-file ??

Roelof

tinyfly · 2006-02-13 22:56:45

View source for your form and you can see all the ids and classes

Bloke · 2006-02-14 02:09:15

This is a great plugin idea. Love all the styling options.

After reading the recent posts, I’ve disabled the “send to friend” (send_article="yes") part I was testing on one of my sites amid all these spam fears (my hoster is very hard on anybody whose forms are used as spam portals and just closes your account without warning…nice). I’ve left the standard “contact form” up: am I right in thinking the plugin’s fairly hardened in this mode because there’s no facility to inject an email address?

Wondering what this zem_contact_nonce hidden field is for. I initially thought it was some kind of session variable. Forgive me for being naive (happens a lot!) but can’t we use it as such to help counter the bots? Or does TextPattern not allow you to get/set SESSION info from plugin code? I’ve only dabbled in other people’s code so far and I’m a real rookie at this plugin stuff so apologies if that’s a stupid question.

Anyway, before I switched it off, I was trying out my send_article and it occurred to me that I’d like to be able to control the output a little better. For example, I set up my form to have 3 fields;

1) “Your name” (to make it obvious that the person sending should put their name there)
2) “Friend’s email” (again, trying to be explicit so they don’t send it to themselves)
3) “Message”

If I put my name in (for the sake of argument I’ll be Andy) and want to send the article to my mate Bob@bobbins.com, the email that Bob receives is a mite confusing. The first thing he sees at the top of the email is:

Your name: Andy

Which is a blatant lie, because he’s called Bob. Then it says:

Friend’s email: Bob@bobbins.com

Well, he already knows that ‘coz it’s his email address… I’ve tried every way I can think of to label the fields so they’re unambiguous to the sender and meaningful to the recipient but have so far failed. Is there an option somehow that’ll allow me to format a message, be it a txp form or a direct argument to zem_contact, something along the lines of:

Hi ::friend’s email::,

Your friend ::your name:: thought you might like this article. He says:

::message::

Enjoy!

And then the article title/excerpt/body follow as usual. Is this sort of thing feasible, now or in a future release, with the way the plugin functions or shall I just crawl back into my box and stop hassling y’all?

If I get half a chance I’ll look at the code and see what’s viable but with the number of options and amount of complexity in this plugin it’s probably above my tiny brain until I cut my teeth on some intermediate plugins first. Security in this plugin comes first of course; this was just a random thought I’m mentioning before I forget.

Oh, and can I just add my 2p about captchas in this plugin: no, please no!

imho, they’re not worth the bytes they’re printed on. With automated OCR being as good as it is now, it offers little measurable security improvement, there are numerous other ways round them, and they’re a pain for the end user.. the number of times I’ve had to have 2 or more goes at them to get them right because the letters are so distorted. And I regard myself fairly average.

I like the idea of the “hidden empty field” because unless a bot can make a decision about which (if any) hidden fields it will fill in, there’s always a good chance it’ll get it wrong. It does need to be used in tandem with some sort of throttling system though because the number of perms/combs of the fields in your average form is not that great and all combinations of fill/no-fill could be tried in a matter of seconds with at least one guaranteed successful spam.

I’m trying a backwards approach to this area of determining human/computer, but it’s still very early alpha stuff and I haven’t the time to devote it the resource it needs right now, nor do I know whether it’ll even work in practice. One sunny day maybe…

That was probably nearer a quid than 2p. I’ll shut up now.

-P- · 2006-02-14 07:50:38

Maybe everybody got that allready but let me point any way that it was not just “send this article to a friend”-feature that spammers used. It was the general php form mail functions that make whole zem_contact_reborn work.

Spammers hit on my sites via two different TXP installations and one Wordpress installation contact form. None of these had this feature on, only the “plain” contact form.

So meaning that you just left “send this article to a friend”-feature out, does not mean you´re safe it´s the system in general.

Last edited by -P- (2006-02-14 07:52:12)

els · 2006-02-14 20:44:21

Question: if I receive a spam email that does not have the subject line as defined in the plugin code, and it also does not have the usual Name: blah Email: blah Message: blah text, can I then be certain it is not sent through the contact form?

thebombsite · 2006-02-14 23:39:19

@Els – Doesn’t it tell you where the email came from? Or am I grabbing the wrong end of the stick here?

@-P- I am aware your spam came through the normal form functions however Bloke makes a good point about keeping the core code to a minimum and using the new API to add extra functionallity, but only if YOU want it. With this in mind I will have a word with Tranquillo and Anura about whether the “Send Article” and the hopefully soon to come “Select Recipient” can be separated into their own plug-ins.

I have also fixed the “isError” for the “zem_contact_select” function so that should now be as stylable as the other inputs. I have also reduced the number of “returns” made dependent on “zemRequired” to a single instance which has taken out a nice little chunk of code. Still haven’t been able to get a “button element” to work properly yet. :(

Tranquillo is currently reviewing neptho’s code for possible inclusion into the base code but this may require a major rewrite so don’t hold your breath.

In the mean time it would be interesting to see if the current plug-in is working properly to stop spam, particularly from those who were having problems last week.

Last edited by thebombsite (2006-02-15 12:18:21)

Bloke · 2006-02-15 08:43:34

@-P- : Thanks for clearing that up. I must have misunderstood your earlier post. It was late in the day, sorry. Upon reflection, I think I may have been a bit obtuse in my last post on a few counts, but hey I’m still learning. Forgive me…

Regarding the whole spam thing, while I agree it’s a pest to receive unwanted spam to your own email address, I am more concerned about spammers using various injection attacks/bots to use zem_contact_reborn as a jump-off point to send spam to other people. I don’t particularly want my brand diluted by a spammer sending a message to a few hundred thousand people by inserting carefully-crafted headers into the form fields, because the people who receive it will think it’s from me. I then get a slew of angry people asking why I sent them stuff about xanax from my company e-mail address. Not to mention that if it does happen, my hoster will shut me down. That’s what I meant by “am I right in thinking the plugin’s fairly hardened in this [vanilla contact form] mode because there’s no facility to inject an email address?”

I think my question still stands under this revised definition. Who has tried to:
=> fake a form submission from other domains
=> call the script directly with bogus information
=> add SQL/HTML code into various input fields
=> call the script repeatedly from behind an IP randomizer
=> overflow the fields
=> add fields to the input data to try and get past those poor people (like me) whose hoster insists on leaving register_globals on
=> many more, I’m sure

What were the results? Does the script hold up? My guess is it does (when used as a pure contact form) because the code appears to set all the necessary headers like Content-type with the proper newline sequences, and uses htmlspecialchars() to escape input, etc. It’s unclear what will happen with the article_send form. My guess is that since you can put whatever email address in you like (as long as it’s a valid domain, right?) the message will go to the person/people in the field. And repeatedly calling the script with a bot and a faked subject/body could result in a bajillion messages being sent.

The only extra protection I can think of is SESSION vars. I just don’t know if that’s possible in TextPattern, or even if it helps. From my cursory look at the code it appears the nonce string could be used (if it isn’t already – haven’t figured out what it does yet, anyone care to point me in the right direction?) to check if the values match on two consecutive form submissions from the same client. Not sure if that system works – haven’t thought it through yet.

Tackling the other spam issue of people just sending thousands of messages to your home email from the form will hopefully be reduced with a combination of the various suggestions from people like P (preview message is an excellent idea) and the hidden fields thing, plus some kind of throttling protection if possible.

@thebombsite : I concur with splitting the functionality into various related plugins using a common “core” engine to save rewriting the transport ‘sendmail’ part each time, and then allowing people to bolt on the type of contact plugin(s) they want. Makes a lot of sense.

If/when I get up to speed on the TextPattern API (I’m slowly getting there but some functions are still a little obscure to me) I’ll gladly offer my services to help build this plugin up.

Gee, another massive post. One day I’ll learn to be concise :-p

Textpattern CMS

Textpattern CMS support forum

#256 2006-02-11 16:28:19

Re: Plug-in: zem_contact_reborn

#257 2006-02-11 17:27:11

Re: Plug-in: zem_contact_reborn

#258 2006-02-11 19:54:23

Re: Plug-in: zem_contact_reborn

#259 2006-02-12 20:32:08

Re: Plug-in: zem_contact_reborn

#260 2006-02-13 03:31:47

Re: Plug-in: zem_contact_reborn

#261 2006-02-13 05:26:52

Re: Plug-in: zem_contact_reborn

#262 2006-02-13 21:13:37

Re: Plug-in: zem_contact_reborn

#263 2006-02-13 21:49:12

Re: Plug-in: zem_contact_reborn

#264 2006-02-13 22:54:13

Re: Plug-in: zem_contact_reborn

#265 2006-02-13 22:56:45

Re: Plug-in: zem_contact_reborn

#266 2006-02-14 02:09:15

Re: Plug-in: zem_contact_reborn

#267 2006-02-14 07:50:38

Re: Plug-in: zem_contact_reborn

#268 2006-02-14 20:44:21

Re: Plug-in: zem_contact_reborn

#269 2006-02-14 23:39:19

Re: Plug-in: zem_contact_reborn

#270 2006-02-15 08:43:34

Re: Plug-in: zem_contact_reborn

Board footer