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
Related
I'm new to web development and I don't know whether it's better to check that user filled out all the fields in a form by using "required" or to check it later using php with empty() and then return user to the front page. What are the upsides and downsides of each method?
I tried both of them and the only difference I could think of is the "Please fill out this field" box when using the html way.
Setting required in html tells users that a field is required and prevents someone from accidentally submitting a form with an empty field. However, people can still send the form with a missing field manually, by creating a request outside of a browser. The PHP should be able to handle that, though it can be as simple as returning an error.
In general, you should use client-side validation like required to tell users what to do, and server-side validation to prevent unintended behavior by bypassing the client.
The bottom line here is that your server-side code cannot cannot trust anything it receives from the client-side.
A web application receiving a HTTP request has no way of knowing whether that request came through a user-interface where some validation was applied to the data before sending, or if someone modified that user interface to remove some checks (which is easy in a browser if you have a little knowledge of the Developer Tools), or if (for example) it came from some sort of bot firing requests directly at your server, or if someone simply opened up PostMan and made the HTTP request by hand.
Therefore, in terms of security and validation, you must implement server-side validation and security procedures if you want to ensure the security and validity of your application and its data.
Client-side validation is great for improving the user experience and performance of your application (so that the user doesn't have to wait for a round-trip to the server before they get feedback on the validity of data they are trying to submit), but since it easily can be bypassed or disabled you cannot rely on that alone to protect your application.
Those are both necessary for making a secure and robust app. That is front-end and back-end validation.
The front-end validation makes it so the user cannot accidentally fill unwanted data into the fields shown. That ensures that users are using the app as intended.
The back-end validation makes sure that the values that are coming in are always values that are expected. What makes this different is that people can bypass front-end validation quite easily, and thus they will abuse this by inserting bad data in your app which can break your whole app completely.
It is necessary to check the validity of the data received from the user on the server, so you must set conditions for it on the server so that invalid data does not enter the database.
Also, to improve the user experience, it is better to have controls in html in addition to the server, this will even make the server not always check and reject the wrong request, so use both of them together.
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 am using JQuery and Javascript extensively in my new project including form validation because I don't want to burden server using PHP validation. So I am restricting my site from the people who disabled Javascript on their browsers. I am trying to redirect them using meta tag:
<meta http-equiv="refresh" content="2; URL=../../enablejs.html">
I assume that this is safe because if javascript is not enabled they will not be able to access my site.
But still I have a doubt over this and need your advice. Is it completely safe? If not what are the area I need to concetrate?
This is a terrible, terrible idea.
because I don't want to burden server using PHP validation
You mean, you don't want to burden yourself with implementing it :)
I can relate. Everyone hates doing stuff twice. But server side validation is not a negotiable extra; client side validation can be easily circumvented and is for user convenience only. Server side validation is always needed for safety and security.
Apart from it being a bad idea, there is no way of reliably excluding users who have JavaScript turned off. JavaScript runs on client side, and its presence or non-presence can be easily faked to the server.
Client-side anything is never ever safe. You always need server-side validation. It's not a "burden", it's a necessity. I don't even need your website to submit (unvalidated) data to your server, in the end it all just boils down to HTTP requests. If you do not validate everything the user does on the server, you have no security.
I am using Jquery and Javascript extensively in my new project including form validation because I don't want to burden server using PHP validation.
That shouldn't save a significant burden. It should give faster feedback to users though, which is good.
So I am restricting my site from the people who disabled Javascript on their browsers.
That is a waste of time. The proportion of submissions in that which will be from users with JS disabled will be tiny.
I am trying to redirect them using meta tag
That's a very user hostile thing to do.
I assume that this is safe because if javascript is not enabled they will not be able to access my site.
If you mean that it avoids the need to write server side validation routines, then you are wrong. If someone wants to attack the site (rather then submit bad data by accident) then they can construct HTTP requests manually.
No that's not safe. Client side validations are nowhere safe. With javascript enabled anyone can bypass your validations. Using chrome console I can probably alter any text on your input boxes or any other input method without you validation noticing it.
Use server side validation or you're screwed.
No, this is not safe. Never rely on the browser for form validation. Form validation in the browser should only be to improve user experience, not to protect your data. You need to add some PHP validation.
Also, are people who have JavaScript disabled not supposed to use your site? You should make JavaScript degrade gracefully so that your site is still usable without it.
Using client side validation is a recipe for disaster "never ever trust clients input" clients inputs are GET (URL included), POST, FLash ...
All inputs should be validated by server side scripting language like PHP, ASP.net, java ...
If you use PHP then check http://www.phpclasses.org/ and look for form validation scripts and Cross-site scripting (XSS). Or use validation classes offered in frameworks like zend, codeigniter
http://en.wikipedia.org/wiki/Cross-site_scripting
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.