I was wondering if it is really necessary to validate in both JS and PHP?
I have my submit button with JS document.myform.submit()sending with PHP POST to the same page.
If a user disables JS he can not send the form anyway.
So I wanted to ask about security, can someone send the variables in another way bypassing the javascript? How would they do this?
And if they can, the answer if I should validate in PHP as well would be YES, right?
The answer is simple.
Server-side is obligatory and must be done unconditionally.
Client-side validation is optional, just for user's convenience.
Thus, validating on both sides isn't necessary but preferred for sake of usability
If a user disables JS he can not send the form anyway.
lol. user can save your form on their local disk and edit it in a way they want.
yes, someone can send the variables using urllib2 in python for instance. This is very easy to do. If you are only going to do one set of validations, do it server side. doing it client side is nothing more than a courtesy to your users.
as an example of how easy it is:
import urllib2
variables = {'variable1': value1, 'variable2': value2}
urllib2.urlopen('http://yoursite.com/index.php/yourform', variables)
# your form has now been spoofed.
Adding headers and cookie management to spoof any user agent is just as trivial
ALWAYS validate on the server side. javascript validation is nice to have, but could be bypassed easily.
an attacker can forge an HTTP POST request with malicious data to your form's URL, which will then enter your system unsanitized.
Just as everyone answered - never rely only on client side validation only. This is so easy to abuse, one doesn't even have to save your webpage to disk, he can use libcurl or any other HTTP library, or just play with Firebug ect.
Validation on the client side is very "user friendly" though. You can add Ajax validation to your forms, and still this just convenience and should rely on server side code.
I completely agree with everybody above - client side is mainly to benefit the person filling in the form. Server side is more to make sure you're not being targeted.
If you want a nice looking client side validation script, I've written one - free to download and use and very customisable. It'll even catch wrongly spelled email addresses and suggest a correct version. You can get it here if you're interested:
http://www.blackboxtechnology.co.uk/free-stuff/javascript-form-checker.php
Enjoy!
Related
I saw here that:
As you probably already know, relying
on client-side validation alone is a
very bad idea. Always perform
appropriate server-side validation as
well.
Could you explain why server-side validation is a must?
Client-side validation - I assume you are talking about web pages here - relies on JavaScript.
JavaScript powered validation can be turned off in the user's browser, fail due to a scripting error, or be maliciously circumvented without much effort.
Also, the whole process of form submission can be faked.
Therefore, there is never a guarantee that what arrives server side, is clean and safe data.
There is a simple rule in writing server application: Never trust the user data.
You need to always assume that a malicious user accesses your server in a way you didn't intend (e.g. in this case via a manual query via curl instead of the intended web page). For example, if your web page tries to filter out SQL commands an attacker already has a good hint that it might be a good attack vector to pass input with SQL commands.
anyone who knows basic javascript can get around client side.
client side is just used to improve the user experience (no need to reload page to validate)
The client you're talking to may not be the client you think you're talking to, so it may be ignoring whatever validation you're asking it to do.
In the web context, it's not only possible that a user could have javascript disabled in their browser, but there's also the possibility that you may not be talking to a browser at all - you could be getting a form submission from a bot which is POSTing to your submission URL without ever having seen the form at all.
In the broader context, you could be dealing with a hacked client which is sending data that the real client never would (e.g., aim-bots for FPS games) or possibly even a completely custom client created by someone who reverse-engineered your wire protocol which knows nothing about any validation you're expecting it to perform.
Without being specific to Javascript and web clients and to address the issue more widely, the server should be responsible for maintaining its own data (in conjunction with underlying databases).
In a client-server environment the server should be ready for the fact that many different client implementations could be talking to it. Consider a trade-entry system. Clients could be GUIs (e.g. trade entry sysems) and (say) data upload clients (loading multiple trades from .csv files).
Client validation may be performed in many different ways, and not all correctly. Consequently the server shouldn't necessarily trust the client data and perform integrity checks and validation itself.
In case the attackers post their own form.
You can turn off/edit JavaScript.
Because the user agent (e.g. browser) might be a fake. It is very easy to create a custom application to create an HTTP request with arbitrary headers and content. It can even say it is a real browser—you have no way of telling the difference.
All you can do is look at the content of the request, and if you don't check it you don't know it is valid.
Server-side validation is a must because client-side validation does not ensure not-validated data will arrive in the server.
Client-side validation is not enough because its scope of action is very restrict. The validation is performed in the browser user-interface only.
A web server "listens" to and receives an HTTP request containing data from the browser, and then process it.
A malicious user can send malicious HTTP requests by many ways. A browser is not even required.
The client-side validation, performed using JavaScript, in the browser, is an important usability, user-interface enhancement. But it does not prevent malicious data to be sent by an user that knows how to circumvent the browser default behaviour of building the HTTP request that will be sent to the server. This can be done easily with some browser plugins, using cURL, etc.
In general, it's best for EVERY piece of an app to do it's own checking/verifications.
Client-side checks are good for maximizing the user-experience and speeding up the feedback to the client that they need to fix something, and to reduce the amount of problems encountered in the server-side checks.
Then at each major point of transition on the server-side code, you should have checks in place there too. Verify inputs within the application code, preferably via whitelist input validation, and then have any interactions with the database use parameterized queries to further ensure problems do not occur.
You should perform server-side validation on any data which, if invalid, could be harmful to anyone other than the entity posting the data. Client-side validation may be suitable in cases where invalid data would have no ill effects for anyone other than the entity posting it. Unless you can be certain that the ill effects from bad data will not spread beyond the entity posting it, you should use server-side validation to protect yourself against vandals or other rogue clients.
Client sided validation is for saving the client from entering wrong data. Server sided validation is for saving the server from processing wrong data. In the process, it also introduces some security into the submission process.
Client side validations presuppose a safe browser, a client side language, or HTML 5. All these elements could be disabled, partially unusable, or simply not implemented. Your website have to be used from every person, with every browser.
The server side languages are safer, and -if they aren't bugs- the validation will be surely safer and right.
Buddy , Suppose if a person turnsoff the javascript in his browser , the validation became dead . Then if he post some malcious content through that form to the server side . It will lead to serious vulnerabilities like sql injection or xss or any other type of problems . So beware if you are going to implement a client side javascript validation .
Thank you
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why is client-side validation not enough?
What is the purpose of using the both validations at the same time? Because it's extra burden on the server for validating the form inputs in php if javascript validation is successful. Can not we use a flag and set or unset its value depending upon whether javascript validation is successful or not? And if the flag value is set, we will skip the php validation. Is it not possible? If it's not possible can you explain with a valid real life example? Or can a user modify the value of the flag even if we pass it in header?
Waiting for some logical answers.
Thank you.
Validating with JavaScript saves you a trip to the server, and creates a nice responsive user experience.
Validating with PHP is necessary so you don't get broken data, or worse (the user could disable JavaScript or post data to your PHP application in a number of ways).
JavaScript can be disabled by the user. It can also be manipulated because it is client side.
One thing to always keep in mind, never trust the users input. Even if you trust the users, or if the website is limited to a very small known to you audience.
So always keep server side validation.
Client side validation is for usability, so I would recommend you keep that too.
The purpose quite simply is the safety.
Javascript validation is happening on the client side - in the users browser. There are no problems to disable or edit the validation to my liking by using a tool like firebug, for example, or to disable it at all by disabling javascript in my browser.
PHP validation, on the other hand, is done on the server side and the user can't interfere with that.
To sum it up, and how I like to think about it - Javascript validation is for the ease of use for the client, PHP is for actual safety.
You can never trust user input. JavaScript is a utility for improving user experience, not your first line of defense against malicious user behavior. JavaScript itself can be used to bypass all JavaScript validations; all someone has to do is type this command in console:
document.forms[0].submit();
Now I am not sure what is with the idea of using flags. But it just as easy for someone to "set" the flag manually if he/she can JavaScript validation.
And if you think server side validation causes burden on the server, you're being ignorant (or lazy, perhaps).
Client side validation is primarily for user-experience and basic-validation.
While writing server side code, you should write validation to ensure security and to make sure the requests are not tampered in between.
As you might know, browsers allow the user to disable javascript. In such a case, client side validation code will not be executed. If there is no server side validation, this will create inconsistency in your application.
For example, if there is an input text field for which you application is expecting an integer value and the user inputs a non-integer value, your application is bound to misbehave and if you are using a database, it will throw some error
To strengthen a point the other answers may have implicated: Not only is it possible to bypass JavaScript in a browser, but it is possible to send data to your server without even visiting your website, if an attacker analyses the requests send to and from your website.
This can be done either by a tool that manipulates the GET / POST requests (thus even using a valid session) or a tool that builds its own requests.
JavaScript validation is to help your regular users to enter well formed data, server-side validation protects your server / your data integrity
When is comes to form validation, which is the best method to proceed with? With HTML5, you can validate the e-mail address and telephone number but usually I would do this with PHP, so which method is better? Or should I validate the input in HTML5 and PHP?
Both.
Rule of thumb:
Validate client-side to provide users with a better experience.
Validate server-side to ensure 100% the data you receive is what you expect.
Always validate with a server side programming language, additionally you could use a client side validation. The reason for this is that everything can be modified client side and thus bypass any client side validation. It's not even hard and there are a lot of tools available for people to modify the html and/or Javascript to submit whatever they want.
The golden rule is, never trust the user. Expect the worst and prepare for that. You can and should use tools such as firebug or other web developer tools to try things out.
You should do both. HTML5 and/or JavaScript validation on the client-side to save the user a page load, and PHP validation because you can never, ever fully trust the client-side.
I prefer both. It is nice when filling out a form to be notified if something doesn't match. However you can't rely on JS validation as it is easily bypassed so server side is required.
The answer both is correct. Not a preference (as some have stated) but a requirement. All HTML (including HTML5) can be edited directly on your page via the browser. Just like using Firebug to edit this page's title, you can edit the HTML input validators and if they don't have server-side validation, it will accept anything you put in there. Handling validation with HTML5 only is like inviting hackers to corrupt all of your db tables. Do you want that?
I found this last comment on this stupid guy's site as a clear example: http://demosthenes.info/blog/462/Goodbye-JQuery-Validation-HTML5-Form-Errors-With-CSS3
Most of the professional programmers have the approach of validating input fields with server side scripting language. Server side form validation using PHP is better than HTML5 and client side form validations in a number of ways:
HTML5 contains few attributes which automatically validates input fields for example:email,telephone,etc. These attribtues are limited. whereas in real world, there are many forms which have some fields which cant be directly validated through HTML5.
If you are thinking about clients side valdiation using javscript as the second option then keep in mind that javascript can be turned off in browser. so it will ultimately affect the user experience.so its better to valdiate your forms through server side scripting lanugae like PHP.
You should adopt the above approach for websites containing sensitive data. but
I really like the idea of validating forms client-side before doing so server-side. If the client's validation passes, I can use Javascript to submit the form.
However, I have heard that some specialized browser, like browsers for the visually impaired, don't support Javascript. Therefore, those users won't be able to submit my forms. Should I therefore avoid what I just thought of doing, or is it alright?
EDIT: (In response to answers): I guess I didn't explain that, but I was planning on doing server-side validation in addition to client-side. Sorry!
Thanks
Javascript is a nice touch to validation. It lets the user know right away that something is wrong, plus it minimises potential calls to the database.
If there are browsers out there that disable javascript for accessibility reasons, you shouldn't worry to much. That's what the server-side checking helps with.
So you should use both, and test with javascript turned on or off. NEVER use javascript as a sole validator - you could just turn javascript off in your browser and the POST data would go through!
You should do both client-side validation and server-side validation. Everything you catch with client-side validation is an opportunity to improve the user experience for your users and tell them exactly what is missing or wrong before they submit the form. If, for any reason, javascript is not enabled, you will still validate on the server (as you always should) and can return errors through the form response from the server if you have to.
So, it's always a good idea to use client-side validation if available.
Is client-side validation smart? Yes, clean input is better for performance than input that will error out.
Great UX? Yes, it's important for a user to get quick, relevant feedback.
Safe? No. Not at all. Hackers don't use your interface to hack your site.
More and more browsers can be site-selective about running JS.
Lastly, if you are concerned about equal access, your best bet is to build accessible versions of the site.
Client side validation often improves user experience, as the user can immediately see whether his data is valid or not.
If it is some simple validation, like pattern matching or length checking for passwords, definitely do it. But of course it is not a substitution for server side validation, it is not a security means in any way. Never trust user input.
Integrate the client side validation in an unobtrusive way, so that form submission still works if JS is turned off.
"Both And" is the answer. Validate client side as a convenience and as a way to better the user experience, but you should always validate server side.
Browsers without JavaScript won't execute the JavaScript at all, so they will still be able to submit your form. Don't worry.
Client side validation is done by interceptin the normal submit event and return true or false based on whether the form is valid. In this way, when javascript is not enabled, the submission is not intercepted and proceeds as normal.
It is one of the easiest things to degrade gracefully, fortunately :)
Not sure we can say it's smart to handle form "control" before submitting : this is "only" client comfort, as these controls... are just not valid from the security standpoint. So this is adding coding efforts for no added value from the security prospective. But this is adding effort for client comfort. And THIS is smart.
The simple way :
No client-side control at all, only server side. No need that js is enabled on the client-side.
This is the point that shall be always enabled and full security valid.
The intermediate way:
Implementing the simple way and adding some javascript "controls" on top, "hand coded" or using js librairies. This is the fastidious way as this is adding a layer on top of the existing server core code, and generally means some server-side code changes or refactoring. So this is the worst way according to me. But this is a good way to learn and understand the client-server exchanges. Painful but useful.
The best way:
Base all your efforts on server-side validation but make sure, from the coding starting point, to be able to embed also the "nice to have", eg. the client-side nice "controls". Which means you have to think of your code architecture before starting writing any line. How to do that ? use Ajax coded forms on the server side. Which suggests the way of coding ideally with specific php form classes. For example, ZendFramework is providing such kind of possibilities using either dojo or jQuery.
Its always better to have "Cleaner" data passed into the server.
Prevents errors and malicous data.
I am done with validation using javascript for a form in PHP.
When is there any need for PHP validation?
javascript validation in itself ensures that all the fields are filled up. Is there a possibility to check the valid format of the inputs using javascript?
Yes
Client Side (Javascript) validation is only to help innocent users find out any errors in their forms without the need for a trip to the server and page reload.
Server side (PHP) validation is needed to prevent malicious users from submitting malformed queries to your server and gain access to your data.
Please note that client side validation only works on the forms you make. A malicious user can make her own form and submit to your server quite easily - thus completely bypassing your client side validation.
Conclusion: You need both forms of data validation.
Validation with javascript is great for useability, but without server side validation you leave yourself open to malicious input and bad data.
Javascript ensure the validation client-side but:
could be disabled
form can be submitted to your server by a "bad guy" from a custom page
so both are required IMHO
In general, a user has control over what data is submitted to a form handler, so you need to validate and sanitize it before it's safe. She might not even use a browser.
Yes, if JavaScript is disabled in client broser then server side validation is necessary.
telnet yoursite.com 80
GET /yourapp.php?name=');drop%20table%20users;-- HTTP/1.1
Host: yoursite.com
Bad things happen when you don't do server side sanitation.
Slightly less important than preventing your site from getting owned by anyone with a little bit of knowledge, not everyone will have javascript turned on, so you want to provide worthwhile error messages for them as well (not to mention, avoiding running with bad data, creating users with empty email addresses or names, as a non-malicious example).
But what is the purpose of using the both validations at the same time? Because it's extra burden for the server for validating the form inputs in php if javascript validation is successful. Can not we use a flag and set or unset it's value depending upon whether javascript validation is successful or not? And if the flag value set we will skip the php validation. Is not it possible? If it's not possible can you explain with a valid real life example? Or can a user modify the value of the flag even if we pass it in header? Waiting for some logical answers. Thank you.