I am trying to learn as much as possible about running a high-profile website. I designing some user registration screens and was thinking about the typical CAPTCHA, or annoying alternatives. In my opinion, having them either causes accessibility issues, or simply bothers potential customers and inhibits their registration process.
My question is whether spambots recognize and trigger JavaScript events, such as the keydown or keypress event on an input field. From what I can gather, most bots simply do form posts via the action attribute and don't programmatically "fill out" web forms.
In theory, I could add JavaScript that something like the following:
<input name="email" />
<input name="human" type="hidden" />
<script>
var emailField = document.getElementById( 'email' );
emailField.onkeydown = function( ) {
document.getElementById( 'human' ).value = "human";
};
</script>
Then, on the server side, I could verify that the post data includes a value of "human" for the hidden form field.
Is this a viable solution, at least as effective as typing in a bunch of random, difficult-to-read characters? Would using a random generated value from the server be more helpful in repetitive attempts than a static value of "human"?
Most spam bots will simply look for a <form> on your page and then post data directly to the URL specified in the action attribute. This is very simple, lightweight, and easy to do.
Some spam bots will actually use a headless browser (such as PhantomJS) which executes JavaScript on the page. These spam bots are much harder to fool, but few bots use this method since it is much more expensive (in CPU and RAM).
I've found that it's generally fine to go for blocking the most common spam bots through a honeypot (field on the page that is removed programmatically, and other similar methods). Some bots will get through, and anyone who does manual analysis to find a way to exploit your page will still get in. For most sites, this is good enough, and provides a good balance in preventing spam while keeping your site usable.
Related
I'm pretty new to HTML, like 1 week new. I am making a web store and I want to be able to login into an "admin panel" to make it easier for me to manage my products. Add new, remove, rename etc. My problem is, I have my login information stored in the html code and I use if-statements to check the validity.
When I was testing the code, I was curious and wanted to inspect element. Unsurprisingly, there was my entire login information and anybody can have access to it.
I need to somehow hide it, or hide the login fields from users except me. But I do not know how to approach that. I thought of a few solutions like have a hidden part on the store page and if I click it a certain amount of times then it will show the fields. But I think I'm complicating it.
Any ideas are greatly appreciated. Thanks. Below is my function for logging in.
function login()
{
var username = "test username";
var password = "testpassword";
if(document.getElementById("username field").value == username && document.getElementById("password field").value == password)
{
var btn = document.createElement("BUTTON");
document.body.appendChild(btn);
<!-- hide the user name field after login -->
document.getElementById("username field").hidden = true;
<!-- hide the password field after login -->
document.getElementById("password field").hidden = true;
<!-- hide the login button after login -->
document.getElementById("login btn").hidden = true;
<!-- show a message indicating login was successfull -->
window.alert("Login successfull! Welcome back admin!")
}
else
{
window.alert("Sorry, you are not authorized to view this page.");
}
}
And this is a screenshot of the inspect element. I don't want anything too crazy like a database because I'm the only user, just a way to be able to access the admin panel without exposing myself. Thanks again.
Inspect Element Screenshot
EDIT:
I am not using my own server, I am using Wix.com to make the initial website and then using the HTML widget to create a webstore. I don't think they allow people to have any communication with their servers whatsoever.
Username and password validation should never be done on the client side. It should always be done on the server. Do not use javascript for this task. Allow your user to enter their username and password in a form, and then submit the form to a server side script to validate their credentials. Doing it on the client side will never be secure.
There's no easy solution to your particular request, but before I oblige you with the details I'd like to stress three very important points.
1: Javascript is not Safe
Javascript is a client side language, which means every piece of data you'll ever be dealing with that comes from your user can be directly modified. These include, but are not limited too, any values or attributes of HTML tags, inline Javascript, loaded image files, etc. Essentially, anything that is cached on the user's computer can be modified and might not be what you're expecting to receive.
As such, a Javascript authentication system is absolutely not safe by any definition of the word. For a local page that only you can access, it would do the job, but that begs the question of why you need authentication in the first place. Even then, as a new developer you'd be widely encouraged to never try do it anyway. There's no point practising and learning how to do something in a completely insecure way and nobody is likely to suggest it.
2: Authentication is a tricky topic
Authenticating logins is not an easy thing to do. Yes, it's easy to make a login script but it's not easy to do it properly. I would never try to discourage anyone from making something themselves nor discourage a new developer from pursuing any goal, but authentication is not something you should be learning only a week into HTML. I'm sorry if that comes across as harsh, but there are people who have been masterminding applications for years who still don't do it securely.
3: Third Party are Best
It's possible to make your own authentication system that likely only the most determined of attackers could access, but it wouldn't involve Javascript authentication. Consider Javascript to be more of a convenience to the user than a solution for the developer. Javascript can do some remarkable things, but being a trusted source of data is something it will never do. Please understand this important point, because the source code you have provided is riddled with security flaws.
--
Now, on to what you want to do. Identifying that you're the "admin" user is something you're putting a password in to do. If you could figure out you're the owner of this site before putting in your password, you wouldn't need the password, right? In short, you can't do what you want to do; not reliably, anyway. It's possible to only show those forms if you're using a particular IP, but IPs can be masked, imitated and changed, which makes it insecure.
There are several third party authentication methods that you can use to do all the heavy lifting for you. All you do is put the fields on your page and they'll handle the rest. You can use any Social Media login (Facebook, Twitter, Google Plus, etc) or you can use O Auth, which deals with all the heavy lifting of authentication for you.
I don't mean to discourage you, nor anyone else, from pursuing their own authentication methods but if I'm honest with you I think this is something way beyond your skill level that you shouldn't be considering right now.
If you serve the pages via a server, you can enforce basic HTTP auth. Should be really simple to set up and you would have the benefit of a standard of security.
Here are the Apache docs for this, for example.
I have 2 pages
Page 1
<span id="error"></span
<input type="text" name="email" id="email"/>
<input type="password" name="pass" id="pass"/>
<input type="button" value="register" id="reg"/>
<script>
var email_r=$('#email').val();
var pass_r=$('#pass').val();
$('#reg').on('click', function(){
$('#error').load('register.php',{ email:email_r , pass: pass_r });
});
</script>
Page 2
on page 2 I check unique email Id and registration is done,
anyone can set the value through browser and perform infinite registration bomb,
how can I secure my login process that will restrict user to misuse it?
instead of using just javascript as a security feature why not try to use some PHP as well.
here is something to get you started.
http://www.wikihow.com/Create-a-Secure-Login-Script-in-PHP-and-MySQL
This isnt all secure but once you get the jits of it , you will understand security parameters required
Hope this helps
Basically there is no easy solution to prohibit malicious activities. You always have to leave the possibility to use the site (since it is the reason you implemented it at first) and this leaves room for malicious activities. You have to differentiate the malicious requests from the "good" requests. This is not easy.
You might search for "captcha" or "honeypot" on the internet and implement an own solution or use an existing one (e.g. http://areyouahuman.com). This is a topic which cannot be answered in one sentence and there is no fits-all solution.
If you have no clue at all and do not want to invest too much time, I would recommend searching for an open ready-to-use captcha provider. There are some out there, although I cannot recommend one. These are easy to integrate and provide a good basis.
If your problem is more like a DOS (denial of service) "attack" (like 10 registrations per second), you might search for this keyword. This topic is even more complicated.
This question already has answers here:
How to Prevent SPAM without CAPTCHAs or a Centrally managed system (e.g. akismet)
(10 answers)
Closed 9 years ago.
I have a simple form that users use to register their email address for a newsletter.
I want to prevent spammers submitting 000's of fake emails. What's the best way to do this?
I thought about limiting the number of inputs from each IP address to, say, 60 per hour, but then thought anyone determined will simply spoof their IP as part of the attack.
Any ideas?
*EDIT: I am looking for a server-side solution. In this situation, UX is important so I don't want to use a captcha, or ask the user to validate with a token
You could use negative captcha. Idea is to have a field in the form that is not visible to humans but bots would enter values in it. On server side you can ignore requests that have a value in the negative captcha field.
Adavatage is that normal users do not see any extra steps like enter captcha words or validate the email. Cons is that the method works as long as people would not customize bots specifically for your site.
Example of a negative captcha. Include this in your form.
<div style="position: absolute; left:-2000px;"><input type="text" name="email_name" value="" /></div>
On server side do somethig like
if (params[:email_name] != "") //bot
else //not a bot
I found a great technique somewhere on the interwebs. I enhanced it, and it is now available (open source) at www.formspammertrap.com .
It uses some javascript to replace the form action, and requires actual 'clickage' of a live user.
No captchas, hidden fields, etc.; those might work temporarily, but usually doesn't work long-term.
It is free, and it works great on any site I put it on. PHP-based, but will also work in WordPress (not a plugin).
You could do something like this,
function validEmail($email){
if (filter_var($email, FILTER_VALIDATE_EMAIL)){
list($user,$domain) = explode('#',$email);
return checkdnsrr($domain, 'MX');
}
return false;
}
it may not pick up every fake email, but I always validate their email by sending them a validation email with a link.
EDIT:
As for spam on a form use CSRF, that should prevent most spam (at least in my experience)
When a user types their email address into the bar, run a script that sends them an email to the address specified that contains a link, when they click the link it will activate that email address for newsletters.
You could use capthcha - which is broken and annoying to users.
What I use is a simple question (how many logs does a dog have) and then use the input of <input type='text' name='email2' value=''>. I then do the necessary checks on the server-side of things. But one thing I do not do is to notify the person that something was wrong i.e. invalid number entered in the email2 textbox.
Anyway, just a thought.
A common approach is, to add another textfield to the form-section. In your stylesheet (not the style-tag!), you set its css-property to display:none, since most spambots fillout every available input-element, but doesn’t load external .css-files.
When your script gets the request, you check this hidden textfield – if it’s blank, you have good chances that this wasn’t spam.
I've made a contact form:
<form action="mailto:myemail#me.com" method="post" enctype="plain/text">
<label for="name">Name:</label> <input type="text" name="name" />
<label for="email">Email:</label> <input type="text" name="email" />
<br clear="all" />
<input type="submit" value="Compose" />
</form>
I want to create a javascript form validator without having to use a server-side language like PHP. Any ideas?
This is a bad idea. JavaScript and JavaScript validation can be bypassed in a number of ways.
The user could tell the browser to not execute any of the JavaScript on the page. If the form itself does not rely on JavaScript, the form will still show up, and the action page will still be there, but all your validation is gone.
The DOM can be edited by the user. Web page developer tools like those in Chrome, Firefox, and IE make it a cinch to change attributes of a form. This includes removing attributes like onsubmit from a form. Or, the user could simply remove JavaScript function from the resources used by the webpage entirely. This allows the user to avoid going through validation.
A user can send POST or GET data directly to the action URL without going through your page. This is great for attackers, since they can inject a malformed form into your server without even going through a browser--they can use a terminal instead, which is much more convenient.
In summary, do not do this. Allowing the user to control validation is a bad thing. Users can turn off client-side JavaScript, but they can't turn off PHP server-side validation. Use PHP validation if you don't want to suffer from embarrassing cross-site scripting attacks and other vulnerabilities.
If you are looking for a PHP form validation library, you can find a number of them around the Internet. For instance, I personally have contributed to one such library that does a good job of evaluating fields in either a POST or GET type form. I apologize for the self promotion, I must insist that you do server-side validation for the sake of security.
That isn't to say that client-side validation is awful and should never be used. But it should always be backed up by server-side validation. You should view client-side validation as a way to inform the user that there is a problem with their form input without reloading, but always use server-side validation to actually look at the input for problems.
Take a look on this live example.
$('#form1').submit(function() {
// Store messages
var msgs = [];
// Validate name, need at least 4 characters...
var name = $('[name=name]', this);
if(name.val().length < 4) {
msgs.push('- Name need at least 04 characters;');
}
// Validate email [...]
// {CODE}
// Validate otherthings [...]
// {CODE}
if(msgs.length !== 0) {
alert("We have some problems:\n\n" + msgs.join("\n"));
return false;
}
});
be careful not to mix things up. you want to do client-side validation, which is nice-to-have, but not as required as server-side validation, which you can only do on the server.
any script-kiddie will still manage to post some crazy data to your server, so you will have to check your requests and sanitize the data on the server-side.
BUT, if you want to do validate your form data before submitting (which is definitely a good standard), you should use one of the many available jQuery plugins to get the biggest bang for the buck.
here is one: http://docs.jquery.com/Plugins/Validation#Example
if you don't like to use jQuery, you can always specify onBlur=myFunction() to execute whatever logic you need when an input field loses its focus.
I want to add a simple Contact form to my web site so that customers can contact me easily.
<form>
NAME
<input type='text' name='name' />
EMAIL
<input type='text' name='email' />
MESSAGE
<textarea name='message' />
<input type='submit' />
</form>
This form would simply email me the customers message.
But, I also want to reduce (not, I'm not saying eliminate but at least reduce), SPAM.
I've looked into using CAPTCHAs but, ultimately, I don't want to hinder the customer with having to fill out extra information.
Any ideas of a good simple spam prevention/reduction method I could use for my Contact form.
A very simple trick I've been using with a surprisingly good success rate is this: Provide a text field that is hidden from human users with style="display: none", but with an enticing name like email. Most bots will fill in something in this field, but humans can't see it so they wont. At the server, just make sure the field is empty, else treat the submission as spam.
If you want to do a completely front-end solution I have had success recently by leaving the form action attribute blank, and populating it via a $(document).ready function. Most spambots use a browser that has javascript disabled, or are looking for hidden fields to avoid detection.
Example:
Your html would be:
<form method="POST" action="" id="contact-form">
and anywhere in that page you can use this to populate it.
<script>
$(document).ready(function(){
$("#contact-form").attr("action", "/yourMailScript.cgi");
});
</script>
A bot browser with no javascript will not get a form action, and they will get a 404 upon submission. Anyone with a normal browser (unless they have JS disabled for paranoid reasons) will get the normal behavior.
The only (client-side) way other than a CAPTCHA type user confirmation would be to write the whole thing dynamically. A lot (but not all) of robots would probably ignore the dynamic content. Eg
document.write("<"+"form>"
+" NAME "
+" <"+"input type='text' name='name' /> "
+"EMAIL "
+"<"+"input type='text' name='email' /> "
+"MESSAGE "
+"<"+"textarea name='message' /> "
+"<"+"input type='submit' /> "
+"<\/form> ");
Use Google or Yahoo mail account. They have good anti-SPAM filters.
Hidden fields, silly questions (what is 3+4?), etc, are not very effective at blocking spam on forms, IMHO.
I researched this several years ago, and came up with a solution I call "FormSpammerTrap". It uses JavaScript code to 'watch' for focus/onclick on required fields. Automated processes, unless highly customized for a specific site (which takes more time than spambot owners want to take), can't 'focus/onclick' a required field. (And there are some other techniques I use.)
I have a free solution at my www.FormSpammerTrap.com site. And there's a form there that spambots can try to spam...and they haven't, for more than 3 years. You are welcome to try it out...it's all open source, so you can see how it works. (And, if you use the form, I don't harvest your email. I reply once, then delete your email.)
My technique is much more effective in blocking spambots, IMHO. They haven't been able to spambot the contact form on that site.
**Added 12 Jul 2018 **
The trick is to add an on-click/on-focus event that changes the action parameter to the actual processing page. Otherwise, the default value I use is a honeytrap-type site. I think it's hard for a spammer to simulate those events, although possible perhaps. The technique blocks a lot of bot-spammers.
And still, after a couple of years using the technique on that site, the form hasn't been spammed by bots. (I define a bot spammer that sends multiple submits via the attack, not just one submit.)
Works for me.
You can add simple question, each serious person who wants to contact you, can easily answer. For example a field where he should enter the first letter of the domain. Most bots don't understand the question and will enter nothing or something random.
You could also try to track the time how long the user needs to input data. If he tries to send the form earlier than 5 seconds before typing the first word just don't allow to send it. Bots usually just parse the site, fill out everything and then post it and go to the next website.
#sec {
visibility: hidden;
padding: 0;
margin: 0;
height: 1;
}
<form method="POST" action="www.google.com">
NAME
<input type='text' name='name' />
<br /> EMAIL
<input type='text' name='email' />
<br /> MESSAGE
<textarea name='message' /></textarea>
<br />
<input type='text' name='security' id='sec' placeholder="Do not enter anything here" />
<input type='submit' formaction="" />
</form>
**Here, only a user who clicks on the submit button actually could submit the form. using auto submit simply redirects the bot to google.com.
**
*Also the input 'security' is an input field that is hidden to users, and visible to certain bots, known commonly as HoneyPot Captcha. On the server side, you can simply skip all the requests that has the 'security' field filled. Not every bot can be tricked this way, and this is where the attribute formaction comes into play *
grep for URI methods, urlencoded characters, or the two HTML markup characters, seems to work.
Use an anti-spam API like Akismet or Cleantalk. You can use the traditional checks for less sophisticated bots before hitting the API. An anti-spam API is the only way to catch spam submitted by a human.
I think that nowadays, most of the solutions posted are either inefficient or outdated.
reCAPTCHA is not a hassle for users any more
google documentation
reCAPTCHA v3 returns a score for each request without user friction.
The score is based on interactions with your site and enables you to
take an appropriate action for your site.
OP states that he needs an alternative to CAPTCHA, in order to avoid hassle for his users (up to v.2, reCAPTCHA requires user interaction). However, as of v.3, reCAPTCHA can detect bots "silently", without requiring user interaction.
Front-end-only solutions are inefficient
The honeypot (hidden input that only a bot could fill) and simple questions methods, as well as other front-end implementations, are still vulnerable to spam attacks. First of all, the spammer can bypass all front-end and post directly to the server. Therefore, a server-side check is required.
In addition, if someone wants to spam your site, specifically, he can easily read your source-code and build a script that is "clever" enough to not be caught by the front-end protection.
On the other side, reCAPTCHA v.3 tracks data and works behind the scenes, in Google's back-end, to determine if the user is actually human. Its logic is hidden, therefore, the attacker can not easily develop a "smarter" bot. In addition, the attacker can not just bypass the front-end; a token is created, is passed server-side and then to Google's back-end to be validated.
TL;DR
Nowadays, reCAPTCHA seems to be the best solution in all aspects. No user friction and the most secure.
Use JS technology. Like if a user comes on your contact page then javascript will generate a string or anything like that you prefer and put the information on a hidden text field. But it is not the actual solution, smart bot can easily crack it.
Another way is, You can also use email verification after contact form submission. And store the data on your database. If customer verifies the url through email then the contact information will mailed to you from database.
And also use delay to prevent continuous robot attack. Like sleep() in PHP code. This will add few delay in your code. By this way you can reduce random attacks but this is not the prevention method.
I found a nice idea on this page:
http://www.evengrounds.com/developers/alternatives-to-captcha
You can make your SUBMIT button display a confirmation page, on which you explain to user that he has to hit CONFIRM button to actually send a message. Spambots would usually only submit first form and skip the second step.
If you dont want to use recaptcha then you can use a service like Real Email and validate the emails server side before processing. Keep in mind that your probably want a way to report to the user if there is something wrong with the input.