Is it good to use "required" in input like this:
Name:<input type="text" name="name" required>
Or should I remove it and use "isset" in PHP? If I understand properly, both show you error, when you want to proceed next without filling input's, but required just awares you, while isset throw's you mostly to new page and reset the form(not good if you only forgot to fill one input).
Or should I remove it and use "isset" in PHP?
Why do you feel the two are mutually exclusive? Use both.
The required HTML attribute provides a smoother client-side user experience. It allows some basic validation without having to re-engage the server. It does not, however, do anything to validate incoming requests in server-side code. isset (among lots of other potential logic) can and should be used server-side to do just that.
Use client-side validation logic to present users with a better user experience. Use server-side validation logic to actually validate the user input before conducting business logic. Validation can live in lots of places for lots of reasons.
Related
Is it good practice to put the Sensitive Data like cart price or user balance information in Form hidden field and process the form.
<input name="usr_bal" id="usrBal" value="9.0" type="hidden">
I think its vulnerable since the value can be altered by inspecting the browser. My problem is I get the balance information of a user from database and do some calculation and send the calculated value to database. For now I am using hidden field and its a Rails application. So, please suggest me if there is any other way to protect the data.
It's not a good idea - as you correctly pointed out, it can be easily altered. Generally, you want to store sensitive info on the server side (with some stuff never leaving the database, like login credentials, for instance).
How do we get rid of these spambots on our site?
Every site falls victim to spambots at some point. How you handle it can effect your customers, and most solutions can discourage some people from filling out your forms.
That's where the honeypot technique comes in. It allows you to ignore spambots without forcing your users to fill out a captcha or jump through other hoops to fill out your form.
This post is purely to help others implement a honeypot trap on their website forms.
Update:
Since implementing the below honeypot on all of my client's websites, we have successfully blocked 99.5% (thousands of submissions) of all our spam. That is without using the techniques mentioned in the "advanced" section, which will be implemented soon.
Concept
By adding a invisible field to your forms that only spambots can see, you can trick them into revealing that they are spambots and not actual end-users.
HTML
<input type="checkbox" name="contact_me_by_fax_only" value="1" style="display:none !important" tabindex="-1" autocomplete="off">
Here we have a simple checkbox that:
Is hidden with CSS.
Has an obscure but obviously fake name.
Has a default value equivalent 0.
Can't be filled by auto-complete
Can't be navigated to via the Tab key. (See tabindex)
Server-Side
On the server side we want to check to see if the value exists and has a value other than 0, and if so handle it appropriately. This includes logging the attempt and all the submitted fields.
In PHP it might look something like this:
$honeypot = FALSE;
if (!empty($_REQUEST['contact_me_by_fax_only']) && (bool) $_REQUEST['contact_me_by_fax_only'] == TRUE) {
$honeypot = TRUE;
log_spambot($_REQUEST);
# treat as spambot
} else {
# process as normal
}
Fallback
This is where the log comes in. In the event that somehow one of your users ends up being marked as spam, your log will help you recover any lost information. It will also allow you to study any bots running on you site, should they be modified in the future to circumvent your honeypot.
Reporting
Many services allow you to report known spambot IPs via an API or by uploading a list. (Such as CloudFlare) Please help make the internet a safer place by reporting all the spambots and spam IPs you find.
Advanced
If you really need to crack down on a more advanced spambot, there are some additional things you can do:
Hide honeypot field purely with JS instead of plain CSS
Use realistic form input names that you don't actually use. (such as "phone" or "website")
Include form validation in honeypot algorithm. (most end-user will only get 1 or 2 fields wrong; spambots will typically get most of the fields wrong)
Use a service like CloudFlare that automatically blocks known spam IPs
Have form timeouts, and prevent instant posting. (forms submitted in under 3 seconds of the page loading are typically spam)
Prevent any IP from posting more than once a second.
For more ideas look here: How to create a "Nuclear" honeypot to catch form spammers
We found that a slight (though simple) variation on the suggestions here made a huge difference in the effectiveness of our contact form honeypot. In short, change the hidden field to a text input, and make the bot think it's a password. Something like this:
<input type="text" name="a_password" style="display:none !important" tabindex="-1" autocomplete="off">
You'll note that this mock-password input keeps to the same basic guidelines as the checkbox example. And yes, a text input (as opposed to an actual password input) seems to work just fine.
This apparently minor change resulted in a drastic drop in spam for us.
One suggestion to really force the no-autocompletion :
change autocomplete="off" by autocomplete="nope" OR autocomplete="false"
Since the given value is not a valid one (values for autocomplete are only on or off), the browser will stop trying to fill the field.
For more details, How to Turn Off Form Autocompletion.
Hope this helps.
SYA :)
If you are using Ruby on Rails, you can try invisible_captcha gem. A solution based on this honeypot technique.
It works pretty well! At least for small/medium sites... I'm using it in production, for years, in several Rails apps with very good results (we hardly receive spam since its implementation in "contact" forms, sign-up, etc).
It also provides some extras (already listed in https://stackoverflow.com/a/36227377/3033649):
time-sensitive submissions
IP based spinner validation
Basic usage
In your form:
<%= form_for(#user) %>
<%= invisible_captcha %>
...
<% end %>
In your controller:
class UsersController < ApplicationController
invisible_captcha only: [:create]
...
end
And you're done! Hope it helps!
I am not 100% sure if this is as big an issue has I seem to think it is right now but I think I may of found an issue or at else an hole within the Inspect Element viewer within Chrome.
I was using (I have now changed my settings) hidden ID's to set a number of defaults, one was users levels, another was to make the user active by default.
However when I view these ID's within the inspect Element view and then changed the values, submitting the form would submit the NEW value to the server and not the value I had given it.
For Example:
I had something like the following within my code,
<input type="hidden" name="data[user][level][id]" value="1" id="MyID">
I then changed it within the Inspect view to,
<input type="hidden" name="data[user][level][id]" value="2" id="MyID">
Then I submitted the form and was surprised that the NEW value was submitted, I was always under the inpresion that hidden ID's where not changeable and the browser should only submit the default values held within.
I have now changed this to letting the database default to a basic user and then I can change the users setting has I want to. But in some cases this may not be an option, so I was hoping for an answer or some feedback about how to make this more safe.
Am I just a bit slow, are there better methods (different ones) to passing 'hidden' data from forms to the server?
I was thinking about maybe using JQuery to add the needed hidden fields to the forms once the user had selected / submitted the form, but i am not sure if this is 100% safe or even if its a good idea.
Any ideas / feedback are very welcome.....
Many Thanks,
Glenn.
I had the same problem passing the database data into a modal,the solution i know is to use jquery ajax to get the informations from the database requesting a file,adding them into variables and compare the variables
$.ajax({
url: "test.html",
context: document.body
}).done(function() {
$(this).addClass("done");
});
I used this code sample to do it.
Of course there are a few modifications to be done depending on your script
I found a better way of doing this, at lest in CakePHP. The CakePHP framework has inbuilt security calls. These in-built functions when added give you all sorts of stuff but the main reason I used them was to stop this sort of form tampering.
I am not 100% sure how it does this, but it adds a token to all forms and it checks to see if the form being submitted is right? Again not sure how the token works.
But here is the code I used ::
public function beforeFilter() {
$this->Auth->allow('index', 'SystemAccess');
$this->Security->blackHoleCallback = 'blackhole';
}
public function blackhole($type) {
$this->Auth->logout();
$this->Session->setFlash('Sorry a security issue has been detected, please try again or contact us for support.', 'default', array(), 'bad');
$this->redirect($this->Auth->redirect('/'));
}
Now I will add that the call the Auth logout I added to this for extra added security, as the user maybe have logged in on a system and it just not be them that is trying to do things that they should not.
Hope that helps others out!
But this is only a fix for when CakePHP is in use. I would take it that other frameworks would have their options but if your only using basic HTML? or a CMS like Drupal again there might be in built security.
Many Thanks
Glenn.
The only safe and best solution that I found for this issue is to check on the server side whether the user_id sent with the form is the same user_id logged in with or not.
Although using jquery is good idea, but, did not work with my case as am using data: $(this).serialize(),
However here's my code on the server side (Note, am using Laravel 5.4, but am sure it won't matter with your case)
if ($request->user_id != Auth::user()->id)
return json_encode("F**K YOU ! Don't Play Smart -_- !");
else
raw_material_category::create($request->all());
Hope this helped ;)
I am using web2py forms and i want to have some fields only visible to user (as fixed which cannot be edited). I tried making various combinations of editable, writeable, readonly but was of no use. I looked into web2py book too but that also seems insufficient. It would be great if someone can tell me how to do this.
You mean some fields visible to all visitors and some fields visible only if logged in?
If that's the case, then build your form conditionally:
form_fields = [
Field('pubfield'),
Field('pubfield2')
]
if auth.user: # This is true if the end-user is logged in and you're using the built-in auth
form_fields.append(Field('private_field'))
return dict(form=FORM(form_fields))
Unless you're not talking about logged in users, and just want to make the fields be visible, but not editable. Then, use writable=False like you tried, but I think you have to either use crud.create/crud.update or SQLFORM / SQLFORM.factory (the latter does not require a data model)
SQLFORM.factory(Field('my_readable_field', writable=False))
If you the form is based off of a database, you can use CRUD (you'll need to modify the settings for CRUD if you're not using authentication, so that CRUD forms are accessible)
crud.create(db.some_table)
or
SQLFORM(db.some_table)
I'm creating a forum for a website, and plan on implementing a "Report this content" function.
In all honesty, I'm not sure how useful (lit. necessary) the feature will be, since a user account (created by admin) will be required for posting, but the solution interests me.
So in short, this is the scenario:
For all users, there will be read-only access to all (non-restricted) content on the forum. For unidentified users there will be a reply button and report this content button present. The former will proceed to require a login, while I had planned that the latter wouldn't, so that anyone would be able to flag suspicious or offensive content.
The problem I'm thus facing is basically "robot clicks", or rather how to implement the system so it won't be fooled by "robot clicks".
There are a few methods that come to mind:
1) User-agent
2) Requiring several flags (in a predefined timespan?) before reacting in any way
3) robots.txt
4) Requiring human input on a second form (captcha or "specify reason")
What I think of them:
1) Unreliable (as sole solution)
2) This requires a mass of users which might lead to the event never being triggered
3) This is probably the "right" way to go, but will only work for those who respect it
4) Meh, I hate captcha and requiring a reason might raise the bar too high to keep the function useful
What methods would the (highly enlightened) community have to share with me?
You could append the 'report this' <form> to the DOM with javascript's appendChild();.
This would prevent a lot of spam.
It would also prevent users not running javascript from seeing the report button. But since this is a feature that does not hinder the user-experience, it is probably an acceptable option.
window.onload = function() {
var f = document.createElement('FORM');
f.method = 'post';
f.action = 'report.cgi';
var b = document.createElement('INPUT');
b.type = 'submit';
b.value = 'Report this';
f.appendChild(b);
document.body.appendChild(f);
}
Note:
The rel="nofollow" attribute makes sure search engines do not 'count' the link, they do however follow it (yes, the name suggests differently).
If you want the search engines not to touch a certain file, use robots.txt
Note 2:
Reporting something is an action that 'changes' something on the server. Thus, it should not be a GET request Instead it should be a POST request. In other words: do not use a <a href""> but instead submit a <form> with its method argument set to "post".
You could simply redirect to a form where the user needs to enter a reason for reporting the content. A robot probably would not enter anything here and the form would not be processed if the user didn't enter anything.
You missed making the link a nofollow one, but I'd opt for a combination of requiring human input (reason, details of complainant) to counter robots and requiring a number of flags to stop people just flagging people they disagree with/don't like on the forum.