On 10/18/07, Anders Nawroth <[EMAIL PROTECTED]> wrote: > Ray Leventhal skrev: > > As a matter of preference, I generally try to eliminate all mailto: > > links on any site I've been asked to work on. In place, I use a contact > > form, > > Me too :-) > > But then you get form-post spam after a while ... > > I have begun to add a random "token" as a hidden field to forms (which > is then checked on the server side, ensuring that a form can only be > posted once), stopping bots that don't actually read the form every > time. (I actually think most of them don't ... when I change the field > names in forms the spam form posts continue to use the old ones for a > long time.)
Mail forms (badly coded ones at least) are also vulnerable to SMTP header injection. Once spammers find a vulnerable form, they can use tools like curl to POST data to your mail processing script without even loading the form. Challenge tokens like yours are a good solution to this problem. FYI, I ran into a nasty problem with Safari related to a challenge string embedded in a logon form. Funnily enough, the solution is to change the field name, as you're doing, Anders. Here's the problem and a solution just to save someone else some headaches. Forgive me, all, if this is getting too far afield for this list. I generated the challenge string server-side and stuffed it into a hidden input field with a name and id of "challenge". When I submitted the form I was sent to ProcessLogin.xxx. If I then hit the back button (say because my password was rejected), Safari respected my cache control directives and reloaded the page from the server, thus getting a new challenge string. BUT, once the page was loaded, Safari helpfully repopulated the input fields with the values they held prior to form submission. This was nice in the case of the userid because it saved me some typing, but it caused a problem with the challenge field because Safari *overwrote it with the old challenge string*. The order of events was as follows: 1) I hit "back: 2) Safari gets a new copy of the page from the server. This creates a new challenge string that embedded in the "challenge" field of the page. 3) Safari (re)populates form fields with the values they held when the form was submitted. 4) Safari executes the page's Javascript. What was very confusing was that even "View Source" showed that the page had the new challenge string but it was the old string that was sent over the wire when I resubmitted the form. (Thank you Wireshark.) Because of the order of 3 & 4, I could have solved this problem by (re)setting the challenge field in the onLoad event. But that might not fix the problem if there's another browser that has the same quirk but executes those steps in a different order. Instead I came up with the solution of using the challenge string as the field id/name instead of its value. (The value is simply "challenge".) Safari's "helpfulness" leaves this field untouched since it has a new name every time the page is loaded. The challenge string still gets transmitted to ProcessLogin.xxx, I just have to find it by looking through the form field names rather than their values. Note that since the challenge string appears as a form control name and form control names must begin with a letter per the HTML spec, challenge strings have to start with a letter. -- Philip http://NikitaTheSpider.com/ Whole-site HTML validation, link checking and more ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
