I have built a small app using javascript. I am using javascript for form validation and i am wondering if by using the "no script" tag if this will protect me against people passing non-clean data into my mysql db? I will deny access to the application to anyone who has it turned off. Is this a secure method or do i have to also do php form validation on top of the js validation?
If not, can someone advise me on what is the best way to ensure that the data submitted to my db is not harmful and clean. Id like to do this using javascipt if possible and not layer it with php but if i have to i will as long as my app is secure.
I know i must do some php cleaning such as htmlentities but want to avoid doing form validation with php.
Thanks.
No, you can never trust the client-side to validate. You must always validate server-side. Client-side validation can improve the user experience, but it gives no security benefit.
As a general rule, you never want to rely on client-side code (javascript in this case) to validate data. The client has full control over anything you would put in javascript, and so it would be pretty easy to bypass. Always validate on the server where you have full control of what is happening.
No, you always need to do serverside validation. You can alter JS even when it's turned on (in Chrome for example, you can just pause script loading, edit the JS then run it), therefore it wouldn't even matter if it's on or not.
This is a good starting point: http://net.tutsplus.com/tutorials/html-css-techniques/build-a-neat-html5-powered-contact-form/ (towards the bottom is the validation examples)
Javascript protection is just "visual". Anyone can bypass it and insert any data he/she wants.
You should always validate user-submitted data server-side.
Basically you can start with mysql_real_escape_string() for preventing mysql injection, and do some tag stripping if you are going to display the inputted data back.
Related
This question already has an answer here:
Is my JavaScript validating enough?
(1 answer)
Closed 9 years ago.
So up to now i got my client side validation ready, But what if javascript disabled?...
I was thinking what can be the best method to make sure the data i get is valid:
For start i can also test the data on the server side but than what is the point with all the javascript validation.
HTML 5 got some validation features but limited browser support.
I was thinking about something with Ajax but can't put my finger for ajax solution yet.
So i will be very thankful to get some suggestions for solution when javascript off.
Never trust user input.
Never trust user input.
Never trust user input.
Never trust javascript validation, which can be tampered with very easily since it executes on the browser. Consider it is part of the user input.
Never trust user input.
Server-side validation is always mandatory, whether there is javascript validation or not. Other than that, Ajax is just a funky name for dynamic javascript calls to URL's. No Javascript, no Ajax.
There is nothing else I can think of, besides HTML5 validation (which must not be relied upon either, as it can be circumvented as easily as Javascript validation).
Even if JavaScript is turned on, it's still perfectly possible to manipulate a form to post information that you might not be expecting on the server-side. Server-side validation is always needed for data storage and manipulation.
Yes, you should always have BOTH validation client side (javascript) and server side (business object in your language of choice).
You absolutely cannot trust all users to use/leave client side alone.
Client side validation is to help the user stay sane so they are not posting-erring, try again, post-erring, try again. And you cut traffic to your server/objects as well. Everyone likes that.
But you NEED to have your server side do a final validation if you are serious about validation. If you ever can only pick one or the other (and if a client has js disabled...) you pick server side.
If you want a slight lessening of what seems like redundant validation, have your form ajax post/call to a validator that calls your BUSINESS LOGIC rules on the server but then when the final post occurs, it needs to run through the BUSINESS LOGIC rules again before you commit.
Please remember this mantra:
JavaScript validation is good for the user, but Server validation is good for security.
And this one too:
User data is always evil.
In other words, always perform server validation, because at the end of the day you are dealing with user data that may have been tampered with.
I want to validate the data that the user enters in a form. I have only a username and two fields for the password. My first question is that I check the data with javascript and it works fine, but i want to check the data with php too incase javascript is not working. In case the javascript is not working the data will be checked from the php code, but my problem is that if javascript is working then the data will be checked from javascript and php too. Is this fine? Is there any way to avoid checking with php when the input data are checked by javascript? Also I am checking the inputs(username and password) for the number of characters, for characters(i don't permit special characters, only "_", "." numbers and letters in order to avoid sql injection) - how does it sound to you? Do you have any other suggestion for better validation?
Thank you in advance.
You should always do a serverside(php) validation of userinput. a clientside(javascript) validation is only good for a better user-experience. Also you should not restrict the input to some characters for mysql injection prevention, there are other reliable methods for this.
Yes, you should validate both client-side (JS) and server-side (PHP).
Do so on the client for convenience for your user and for a better user experience.
Do so on the server to prevent a malicious attack, or, as you stated, in case your user has JS disabled.
You should always perform server side validation. There is no guarantee that client-side validation (such as javascript validation) cannot be defeated. It's a simple exercise to grab a debugging tool (any many are built into browser nowadays) and circumvent javascript validation.
Typically there is nothing wrong and is even recommended to do validation in both places in Javascript and PHP.
Checking both ways is fine and definitely recommended. If you wanted to avoid checking with PHP if Javascript is enabled, you could append a hidden field to the form and check for this with PHP.
E.G.
if(!isset($_POST['js_hidden_field'])) {
// Run Validation
}
So you check for the hidden field, if it's not set then run the PHP Validation
This is actually good, you can never do too much validation in my opinion. Client side scripting can be manipulated by anyone with web development experience but server side scripting cannot.
client side scripting validation pros:
Alerts the user before submitting data allowing them to correct themselves
Makes your site look a little more sophisticated
server side validation pros:
no one can change any validation rules you have
they cannot turn off server side validation.
In short, doing both is good, it's actually better than just doing one or the other.
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
I have a question about security. I have a website programmed with HTML, CSS, PHP, Javascript(jQuery)...
Throughout the website, there are several forms (particularly with radio buttons).
Once a user selects and fills out the form, it takes the value from the selected radio button and sends that to the server for processing. The server also takes the values and plugs them into a database.
My concern is this:
How can I prevent someone from using a developer tool/source editor (such as Google Chrome's Debugging/Developer Tool module) and changing the value of the radio button manually, prior to hitting the submit button? I'm afraid people will be able to manually change the value of a radio button input prior to submitting the form. If they can indeed do that, it will entirely defeat the purpose of the script I am building.
I hope this makes sense.
Thank you!
John
How can I prevent someone from using a developer tool/source editor (such as Google Chrome's Debugging/Developer Tool module) and changing the value of the radio button manually, prior to hitting the submit button?
You can't. You have no control over what gets sent to the server.
Test that the data meets whatever requirements you set for it before inserting it into the database. If it isn't OK, reject it and explain the problem in the HTTP response.
Any data sent from the browser to the server can be manipulated outside of your control, including form data, url parameters and cookies. Your PHP code must know what sets of values are valid and reject the request if it doesn't look sensible.
When sending user input to the database you will want to ensure that a malicious user-entered string can't modify the meaning of the SQL query. See SQL Injection. And when you display the user-entered data (either directly in the following response, or later when you read it back out of the database) ensure that you encode it properly to avoid a malicious user-entered string executing as unwanted javascript in the user's browser. See Cross-site scripting and the prevention cheat sheet
I'll go along with Quentin answer on this.
Client-side validation should never stand alone, you'll need to have some sort of server-side validation of the input as well.
For most users, the client-side validation will save a round trip to the server, but at as you both mention, there is no guarentee that "someone" wouldn't send wrong data.
Therefore the mantra should be: Always have server-side validation
I would say that client-side validation should be used solely for the user's convenience (e.g., to alert them that they have forgotten to fill in a required field) before they have submitted the form and have to wait for it to go to the server, be validated, and then have it sent back to them for fixing. What a pain. Better to have javascript tell you right there on the spot that you've messed something up.
Server-side validation is for security.
The others said it already, you can't prevent users from tampering with data being sent to your server (Firebug, TamperData plugins, self-made tampering proxies...).
So on the server side, you must treat your input as if there were no client validation at all.
Never trust user input that enters your application from an external source. Always validate it, sanitize it, escape it.
OWASP even started a stub page for the vulnerability Client-side validation - which is funny - client-side validation seems to have confused so many people and been the cause of so many security holes that they now consider it a vulnerability instead of something good.
We don't need to be that radical - client-side validation is still useful, but regard it simply as an aid to prevent the user from having to do a server roundtrip first before being told that the data is wrong. That's right, client-side validation is merely a convenience for the user, nothing more, let alone an asset to the security of your server.
OWASP is a great resource for web security. Have a look at their section on data validation.
Some advice worth quoting:
Where to include validation
Validation must be performed on every tier. However, validation should be performed as per the function of the server executing the code. For example, the web / presentation tier should validate for web related issues, persistence layers should validate for persistence issues such as SQL / HQL injection, directory lookups should check for LDAP injection, and so on.
Follow this rule without exception.
In this scenario, I'd recommend that you use values as keys, and look those up on the server side.
Also, consider issuing a nonce in a hidden field every time someone loads a form - this will make it a bit more difficult for someone to submit data without going through your form.
If you have a lot of javascript, it's probably worth running it through an obfuscator - this not only makes it harder for hackers to follow your logic, it also makes scripts smaller and faster to load.
As always, there is no magic bullet to stop hacking, but you can try raising the bar enough to deter casual hackers, then worry about the ones who enjoy a challenge.
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.