I'm working on my contact form, and I want to make it as spam-proof as possible. I'm using a few methods to as counter-attacks:
Validate email legitimacy w/ a JavaScript regular expression
Validate if all fields have adequate values
Make an invisible field to entice bots
Disable the form if JavaScript is disabled
Now, my question is will a radio button asking the individual if he/she is human be a good method to avoid bots, or do bots have the ability to select a radio button?
They may have the ability, but would they select the right one?
Please leave suggestions below!
(Preferably something not captcha. More PHP or Javascript.)
Unfortunately, bots can select a radio button.
But the invisble field is a good idea and you can also try Askimet, an anti-spam service.
In case of radio, spam bots may either choose default choice or the first choice. this link might help you
Most bots just select the de facto form or common norms previously set up within your application.
If you're attempting to fight email spam then you're better off with server side validation of email formatting and cross referencing SPF records. This prevents abuse from the client side(and bots are basically automated client software).
A captcha is another method of preventing spam.
However the best method that has come out in the industry as of late is the use of OAUTH and requesting a service like Facebook or Google+ to get a valid email address from your users.
Related
I want to add two buttons to my gmail messages YES and NO if we pressed on YES then show one Textbox and a submit button .and if we press on submit button the value od the textbox must be saved. how can i achieve that . Am sorry for my bad language
You can do this simply using google form. Just follow the steps below
1) Go to google forms create a new form as you like
2) then click on send form choose send via email option mention the to email address, subject and message. Don't forget to check Include form in email option.
Then click on send button.
When the recipient receive this email that would contain an embedded google form. The responses of google form can be retrieve via email or it can be save into a linked excel file on google drive.
I think the easiest way to your problem is to put Links in your E-Mail, which redirect the user to a website of yours. If he presses no, then your website (where the user was redirected from the no-button) can just save the response and close the tab again. If the user presses yes, the user can enter the information in the textbox (in your website from the link from the yes-button) and save it on your website after the user submitted it.
That's usually the practice how such things work. Another example for this is unsubscribing from newsletters. There you also get redirected to the website of the sender of the newsletter and may enter your e-mail and the reasons why you unsubscribe.
Hope I could help :)
it may be a number in the textbox like number of persons ,and it save
to a web server . can we do that ?
In pure e-mail based on HTML and JavaScript? No. You can't. You need PHP to send response to server and this is not allowed in e-mails and with JavaScript is basically impossible to do it. next problem is, that you cant use iframe or something like this, because Gmail and other e-mail clients don't allow it.
But how?
You can create good looking button with HTML/CSS and on it add link to answer to your page, where you can easily process user data. If you haven't got many programming skills you can use Google Forms. Google Forms is easy to use for any user and you can create your own form without having server, because all data will save at google for free
+ it have API.
Plus Google Forms have function for sending forms via e-mail!
(Sorry for Czech in image.)
Good luck!
I have website which is luckily on top of Google but there are spam messages with backlinks of different websites from spammers too so what i thought a solution to prevent visitors from putting back links in Multiline Text Area ?
I have tried with required field validation and some other ways but unlucky yet.
I am bit familiar with Javascript but after searching i did not find any javascript to prevent backlinks in text area.
If any one can help me a bit or just give me an idea ?
Client-side validation is easy to bypass, but server-side validation should not.
I mean that client-side validation may work with human users but spam bots may send requests to your server bypassing your form or they even don't understand JavaScript.
Do the whole client-side validation for human users but repeat the same validation in the server-side so no one will be able to bypass your rules.
I would like to know more about the solutions to restrict registering for a website for humans only.
Captcha may seem a proper solution but as it turns out it's not as good as it sounds.
And it's not a problem if a solution is not an option for blind, deaf people etc..
My newest web app uses a process that makes this really easy for the user and secure for me.
User goes to login page, enters their email address and clicks an "I am signing up" checkbox.
The user clicks "register", their email address gets inserted to a temporary SQL table (called signups) and an email with a verification link is sent to the email address.
The user clicks the verification link which takes them to a "create password" page.
After the user creates his password, the email address and password are inserted into the users table–and the entry in the signups table is deleted.
This makes it easy and reliable.
The signups table also includes a random SHA1 hash (for the verification link), a timestamp set for 12 hours after the sign up, and IP Address.
All entries in the signups table that have an expired timestamp get removed at certain parts of the day.
Update
Since writing this answer, I have found that keeping a signup form secure from robots is a never-ending battle.
As time goes on, new technologies and methods are being developed to circumvent security measures. The best thing any dev team can do is periodically be checking the quality of signups, and thinking of ways to make their signup form both more secure and intuitive to use.
Yeah, it is a good bit of work and resources that go into it, but having confidence in your signup form and quality of signups is well worth the expense.
Depending on how targeted your site is, using a honeypot can be quite effective.
In short, you have a field on your form with a common name -- let's say email. Your actual email field has some other random name like larp.
Hide the email field using CSS, and include a text label instructing users to leave that field blank, should they happen to see it.
If any registrations come in with the email field filled in, send a success message back then drop it.
Verifying the e-mail address and allowing only users who have verified their e-mails is the easiest and quickest solution.
You could have users listen to an audio file, and enter the word into a text box. That's what I wanted to do for phpBB3, but alas, they do not allow HTML markup for their verification questions. Alternatively, you can do defense in depth, and have a CAPTCHA be only part of the process.
Instead of captcha (typing in words displayed in an image) I've seen websites that require you to answer a question, usually basic math. I haven't implemented these, but I've seen them several places so it must be something that's a plugin for various CMSes and soforth.
Bottom line is, any system will eventually be circumvented. You can minimize bot-registrations, but I can tell you from experience that there are people out there who will pay other humans (who can pass just about any test) money to sign up for web sites - the pay is generally really poor, but there are always people who will find that acceptable.
So along with whatever solution you use, you'll want to periodically re-evaluate that solution, AND you'll want to have a human being review new registrations (maybe once a day?) to weed out the few 'bots that do get through.
I been reading on asp.net mvc learning site about JavaScript injection and man it is an eye opener.
I never even realized/thought about someone using JavaScript to do some weird ass injection attacks.
It however left me with some unanswered questions.
First
When do you use html.encode? Like do you use it only when you are going to display information that that user or some other user had submitted?
Or do I use it for everything. Like say I have form that a user submits, this information will never be displayed to any of the users, should I be still using html.encode?
How would I do it like I am not sure how to put inside say and Html.TextBox() the html.encode tag.
Second
What happens say I have on my site a rich html editor. The user is allowed to use it and make things bold and whatever. Now I want to display information back to the user through a label. I can't Html.Encode it since then all the bold and stuff will not be rendered.
Yet I can't leave it like it is since what would stop a user to add some Javascript attack?
So what would I do? Use Regex to filter out all tags?
Third
There is also another tag you can use called "AntiforgeryToken" when would you use this one?
Thanks
Edit
Almost everyone says use a "White List" and "Black List" how would I write this list and compare it to incoming values(examples in C# would be nice)?
Good question!
For the first answer, I would consider looking here at a previous asked question. As the answer discusses, using HTML Encode will not protect you completely against all XSS attacks. To help with this, you should consider using the Microsoft Web Protection Library (AntiXSS in particular), available from Microsoft.
As has already been mentioned, using a list of allowed tags is the best thing to do, leaving others to be stripped out.
The AntiforgeryToken token works to prevent request forgery (CSRF) because it gives the user a cookie which is validated against the rendered form field when the page is posted. There's no reason that I am aware of that means that you can't use this in all of your forms.
Use HTML Encode for any data being displayed that has been submitted by a user. You don't need to use it when submitting into the database otherwise you would get odd data like: Simon '&' Sons. Really I don't see the harm to use it on any content written to the page dynamically.
Use a list of allowed tags and discard everything else for your HTML editor. As people said, use a whitelist.
The third one is meant to prevent a Cross-site request forgery attack. You use this to stop people being able to do a POST using a 'stolen' cookie from the user. So you may require a authenticated cookie before accepting a post but a malicious user could take that cookie when a user visits their site and then submit a form to your site claiming to be them.
See here for more:
http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx
How to use it:
http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
Always validate the input received against a whitelist. If you use a blacklist you could and probably will come up against encoding issues. Always use a whitelist when validating input.
Do not rely on client side validation to validate the user input. Client side validation is great for helping the user input correct data. But a malicious user will not use this and could bypass the client side validation. Client side validate is should never be considered as a security fix. Using javascript to validate input should not be used. As you can see javascript is very easy to change and modify on any html page. Also javascript can be disabled in browser. So give additional check in your code behind file.
Additionally validate the input every time, not just when the data is initially accepted. For example if you set a cookie, make sure that cookie is the same value and it is correct on each and every request. A malicious user could modify and change the value anytime during the session.
There are various levels of security that can be implemented based on the design considerations of your application.
I would go with the following basic rules:
Sanitize all input, removing known malicious sections (for instance, <script> tags in a rich HTML editor). Regex based pattern matching is commonly used for this kind of sanitization.
Remove all input that are not in your white-list of allowed values.
Encode any HTML before storing in the database and Decode it back when it is being retrieved for display.
Edit:#Phoenix talks about validation in this context so I thought I'd add this. I have said this before and I reiterate: I am not against script based validation. I only caution people not to rely on it expressly. A common design pattern is to validate basic criteria using script based validation and apply rigorous validation on the server side when that data is submitted.
I am working on a website and would like for my users to be able to give feedback as easily as possible. I know one way but I've always hated it:
Click Here to be annoyed!
Is there a way in JavaScript or HTML to allow my users to email me without having to go through a lot of trouble?
A CONTACT FORM:
avoids spam bots that pick up 'mailtos'
allows you to validate that the form user is 'human' (optional captcha)
gives you total server-side control over data format
allows you to change your email easily from the server, anytime
hides your favorite, real email from your visitors/members/site users
gives you the option to control the topic (via select menu, etc.)
gives you an opportunity to have the user check off something extra
e.g., a survey question, subscription opt-in, interest in services, quote, etc.
gives you an opportunity to return a thank you (or sales page) after submission
gives you another opportunity to look professional
There's no question the link is the easiest initially-- a simple click; but, all things considered, I whole-heartedly agree that a contact form is the way to go for most purposes, for the reasons I listed above, and more.
Well, since Tom challenged me, ;) Here are a few copy-and-paste contact widgets that you can have up and tested in a minute or so.
Some Customizable Flash Contact/MailTo Widgets:
http://www.widgetbox.com/widget/contactify-widget-beta A customizable contact form. The style is highly customizable.
http://www.widgetbox.com/widget/contact-emailer-version3-rajwidgetbox
Use this gadget in your web site's
contact page. Avoid spams by not
providing your email address in your
site or blog. This gadget is highly
customizable. This uses image
verification code feature. Multiple
languages are supported. Version 3.
3300 downloads
http://www.widgetbox.com/widget/ultimate-antispam-email-link
Now, if you really do not want a
form, but do want an email link that
spam bots cannot pick up, here's the
widge for you. In the custom area,
you define your parties and mailto
addresses. It's a simple flash
button, so the user doesn't see it
until it opens their mail client.
The way you describe is the easiest way in my opinion.
If you want the email typed up there in the page like a form, you might want to create an email/suggestion form or alternative.
You can provide a multiline text box for comments and a submit button, POST the text to your server, and then mail it to yourself on the server. That spares your users a trip to their mail clients, at the cost of depriving you of a reasonably-likely-valid reply-to address.
You could even use AJAX and spare them a screen refresh.
Google Docs supplies creating webforms that can be easily embedded in websites. It collects all data in an on-line spreadsheet which you can download at anytime in various formats. You can even set e-mail notification if a visitor filled out your contact form.
I would create a form that users can provide feedback in, and then have your server write this into a database. Writing to a DB is likely going to make it more efficient for you to wade through feedback. Having users fill a form instead of sending you free-form email also help you enforce some kind of structure on the feedback or the metadata associated with the feedback (bug/feature request/comments, etc).
The most reliable way would be to send the email with the help of some server side processing.
You can also do it using an HTML form with the help of the action attribute:
<form action="mailto:user#example.com">
...
</form>
But this method may not be reliable for all browsers.