I am using jQuery to disable some form buttons. Simple stuff. But how can I prevent users from editing the DOM and enabling the button themselves so they can work around the restrictions I put in place?
You can't. The client is completely under the control of the user.
You can only handle what data you accept when it is submitted to the server.
Use client side code to make things convenient for users. Use server side code to enforce security and other restrictions.
You can't. The DOM is entirely handled by the browser. Once you've sent off the page to the client, it's out of your hands. All you can do is keep track of whether an action is allowed on the server, and allow or disallow it when they try.
You can't force the user to do anything, neither can you prevent them from doing anything. If you could, spammers would have a field day.
This is why EVERYTHING MUST be validated on the server-side.
You can't!!! Once the DOM is at the client side you don't have control over it the best way to ensure security is to handle it also via server side.
Related
Which is better to do client side or server side validation?
In our situation we are using
jQuery and MVC.
JSON data to pass between our View and Controller.
A lot of the validation I do is validating data as users enter it.
For example I use the the keypress event to prevent letters in a text box, set a max number of characters and that a number is with in a range.
I guess the better question would be, Are there any benefits to doing server side validation over client side?
Awesome answers everyone. The website that we have is password protected and for a small user base(<50). If they are not running JavaScript we will send ninjas. But if we were designing a site for everyone one I'd agree to do validation on both sides.
As others have said, you should do both. Here's why:
Client Side
You want to validate input on the client side first because you can give better feedback to the average user. For example, if they enter an invalid email address and move to the next field, you can show an error message immediately. That way the user can correct every field before they submit the form.
If you only validate on the server, they have to submit the form, get an error message, and try to hunt down the problem.
(This pain can be eased by having the server re-render the form with the user's original input filled in, but client-side validation is still faster.)
Server Side
You want to validate on the server side because you can protect against the malicious user, who can easily bypass your JavaScript and submit dangerous input to the server.
It is very dangerous to trust your UI. Not only can they abuse your UI, but they may not be using your UI at all, or even a browser. What if the user manually edits the URL, or runs their own Javascript, or tweaks their HTTP requests with another tool? What if they send custom HTTP requests from curl or from a script, for example?
(This is not theoretical; eg, I worked on a travel search engine that re-submitted the user's search to many partner airlines, bus companies, etc, by sending POST requests as if the user had filled each company's search form, then gathered and sorted all the results. Those companies' form JS was never executed, and it was crucial for us that they provide error messages in the returned HTML. Of course, an API would have been nice, but this was what we had to do.)
Not allowing for that is not only naive from a security standpoint, but also non-standard: a client should be allowed to send HTTP by whatever means they wish, and you should respond correctly. That includes validation.
Server side validation is also important for compatibility - not all users, even if they're using a browser, will have JavaScript enabled.
Addendum - December 2016
There are some validations that can't even be properly done in server-side application code, and are utterly impossible in client-side code, because they depend on the current state of the database. For example, "nobody else has registered that username", or "the blog post you're commenting on still exists", or "no existing reservation overlaps the dates you requested", or "your account balance still has enough to cover that purchase." Only the database can reliably validate data which depends on related data. Developers regularly screw this up, but PostgreSQL provides some good solutions.
Yes, client side validation can be totally bypassed, always. You need to do both, client side to provide a better user experience, and server side to be sure that the input you get is actually validated and not just supposedly validated by the client.
I am just going to repeat it, because it is quite important:
Always validate on the server
and add JavaScript for user-responsiveness.
The benefit of doing server side validation over client side validation is that client side validation can be bypassed/manipulated:
The end user could have javascript switched off
The data could be sent directly to your server by someone who's not even using your site, with a custom app designed to do so
A Javascript error on your page (caused by any number of things) could result in some, but not all, of your validation running
In short - always, always validate server-side and then consider client-side validation as an added "extra" to enhance the end user experience.
You must always validate on the server.
Also having validation on the client is nice for users, but is utterly insecure.
Well, I still find some room to answer.
In addition to answers from Rob and Nathan, I would add that having client-side validations matters. When you are applying validations on your webforms you must follow these guidelines:
Client-Side
Must use client-side validations in order to filter genuine requests coming from genuine users at your website.
The client-side validation should be used to reduce the errors that might occure during server side processing.
Client-side validation should be used to minimize the server-side round-trips so that you save bandwidth and the requests per user.
Server-Side
You SHOULD NOT assume the validation successfully done at client side is 100% perfect. No matter even if it serves less than 50 users. You never know which of your user/emplyee turn into an "evil" and do some harmful activity knowing you dont have proper validations in place.
Even if its perfect in terms of validating email address, phone numbers or checking some valid inputs it might contain very harmful data. Which needs to be filtered at server-side no matter if its correct or incorrect.
If client-side validation is bypassed, your server-side validations comes to rescue you from any potential damage to your server-side processing. In recent times, we have already heard lot of stories of SQL Injections and other sort of techniques that might be applied in order to gain some evil benefits.
Both types of validations play important roles in their respective scope but the most strongest is the server-side. If you receive 10k users at a single point of time then you would definitely end up filtering the number of requests coming to your webserver. If you find there was a single mistake like invalid email address then they post back the form again and ask your user to correct it which will definitely eat your server resources and bandwidth. So better you apply javascript validation. If javascript is disabled then your server side validation will come to rescue and i bet only a few users might have accidentlly disable it since 99.99% of websites use javascript and its already enabled by default in all modern browsers.
You can do Server side validation and send back a JSON object with the validation results for each field, keeping client Javascript to a minimum (just displaying results) and still having a user friendly experience without having to repeat yourself on both client and server.
Client side should use a basic validation via HTML5 input types and pattern attributes and as these are only used for progressive enhancements for better user experience (Even if they are not supported on < IE9 and safari, but we don't rely on them). But the main validation should happen on the server side..
I will suggest to implement both client and server validation it keeps project more secure......if i have to choose one i will go with server side validation.
You can find some relevant information here
https://web.archive.org/web/20131210085944/http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/
I came across an interesting link that makes a distinction between gross, systematic, random errors.
Client-Side validation suits perfectly for preventing gross and random errors. Typically a max length for any input. Do not mimic the server-side validation rule; provide your own gross, rule of thumb validation rule (ex. 200 characters on client-side; a specific n chars less than 200 on server-side dictated by a strong business rule).
Server-side validation suits perfectly for preventing systematic errors; it will enforce business rules.
In a project I'm involved in, the validation is done on the server through ajax requests. On the client I display error messages accordingly.
Further reading: gross, systematic, random errors:
https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO
JavaScript can be modified at runtime.
I suggest a pattern of creating a validation structure on the server, and sharing this with the client.
You'll need separate validation logic on both ends, ex:
"required" attributes on inputs client-side
field.length > 0 server-side.
But using the same validation specification will eliminate some redundancy (and mistakes) of mirroring validation on both ends.
Client side data validation can be useful for a better user experience: for example, I a user who types wrongly his email address, should not wait til his request is processed by a remote server to learn about the typo he did.
Nevertheless, as an attacker can bypass client side validation (and may even not use the browser at all), server side validation is required, and must be the real gate to protect your backend from nefarious users.
If you are doing light validation, it is best to do it on the client. It will save the network traffic which will help your server perform better. If if it complicated validation that involves pulling data from a database or something, like passwords, then it best to do it on the server where the data can be securely checked.
i got a simple project but is giving me headaches because Client-Side programming is not my thing. Basically i got a login page and the client wants that i prevent XSS attacks not allowing users not submit malicious code on username/password fields. I would do it on server side easily, but they do not want give to us access.
Any chance to someone give me hints how can i do this? Even tough i know the basics of javascript/HTML, my experience ir nearly null.
I know that are several questions about this topic, but sincerely, i got lost with all information
Best Regards
Actually you simply cannot make any reliable XSS prevention on the client side. The attacker simply disables JavaScript, and all your complicated code is non-existent. Any client-side validation is only for the convenience of the users, nothing more.
Update: The above I wrote, is true about second order (a.k.a. stored) XSS. First order XSS attacks (when the attacker creates a forged URL) can be mitigated using JavaScript.
You prevent XSS on the client in the same way that you prevent it on the server. (Note this only protects against input that is directly processed on the client, and not against code that gets submitted to the server and then passed back to a client).
Make sure you know what data format any given variable holds
Treat any user input including data from forms, data from URLs, etc) as plain text
Encode it appropriately for where ever you put it, using native methods for handling the data where possible
For example, if you wanted to display the fragment id in a div you would:
div.appendChild(document.createTextNode(location.hash));
Do not just allow raw input to be parsed as HTML:
// DANGER
div.innerHTML = location.hash;
This, of course, only protects the page from data submitted to the client side code.
There is no way to use client side code to prevent malicious data from being submitted to the server side code. The client has total control over the client side code, so it can be bypassed very easily.
If you read input from outside the server and then output it to a webpage then you must have server side protection from XSS.
I've been attempting to do some research on this topic for a while, and even cite the following Stack Overflow threads :
Javascript Hijacking - When and How Much Should I Worry
JSON Security Best Practices
But my basic problem is this.
When I am building my web applications, I use tools like Fiddler, Chrome Developer Tools, Firebug, etc. I change things on the fly to test things. I can even seem to use fiddler to change the data that gets sent to the server.
What stops someone else from just opening up my webpage and doing this too? All of the jQuery validation in the world is useless if a user can just hit F12 and open up Chrome Developer tools, and change the data being sent over the wire, right?
I'm still relatively new in this field and this just has me very concerned as I see "Open" Protocols become more and more ubiquitous. I don't understand SSL yet (which is on my list of things to begin researching), so perhaps that is the answer and I just haven't dug deep enough. But the level of flexibility I have over manipulating my pages seems very extreme - which has me very concerned about what someone malicious could do.
Your concerns are indeed justified. This is why you should always validate everything on the server. Client-side validation should only be used for UX.
JavaScript's security is, in a nutshell, based around a trusted server. If you always trust what code the server sends you, it should be safe. It's impossible for a third party (like an ad supplier) to fetch data from the domain it's included on.
If the server also sends you user generated content, and in particular user generated code, then you have a potential security problem. This is what XSS attacks focus on (running a malicious script in a trusted environment).
Client side validation should focus on easy of use, make it easy to correct mistakes or guide the user so no mistakes are made. The server should always do validation, but validation of a more strict nature.
Validation should always happen Server Side, Client Side Validation is only valuable to make for a more convenient experience for the user. You can never trust a user to not manipulate the data on their end. (Javascript is ClientSide)
Next if you are wanting to secure your service so that only user1 can edit user1's profile you'll need to sign you JSON request with OAuth (or similar protocol).
yeah nothing can stop anybody from interfering the data that is being sent from the browser to your server and that's the reason you shouldn't trust it
always check the data from the user for authenticity and validity
also with it you can check and interfere with the data that big sites like google and microsoft send back and you might get an idea.
You have to assume that the client is malicious-- using SSL does not prevent this at all. All data validation and authorization checking needs to be done server side.
Javascript isn't going to be you only line of defense against hackers, in fact it shouldn't be used for security at all. Client side code can be used to verify form input so that users trying to use the page can have faster response times, and the page runs nice. Anyone who is trying to hack your page isn't going to care if your page works or not. No matter what, everything coming into your server should be verified and never assumed as safe.
Supose I have some form with javascript client side validation and no server side validation.
If user disable javascript in his browser there will no be submit button so he can not send me any data without js enabled.
But I do not know is there any way to change my validation instructions from client browser so he could send me untrusted data and make some damage to my database.
Thanks in advance and sorry for my (possibly) obvious question!!!
No. it is not safe. Use server side validation.
For example, even without the browser, I can read your source code. Then simply use CURL to send a post request with malicious data.
Never, ever trust the client.
No, it's not safe. For example, I could just open up the JavaScript debugger in my browser and override your validation.
Anyone who is capable of disabling javascript on their own is probably also capable of making arbitrary POST requests on their own as well. Ok I might be exaggerating but it's still not safe as someone can do the POST requests without using browser, let alone your form, at all.
I would suggest use both client side and server side validation.
Benifit of client side validation is it's fast, we never hit server until user enter correct input. This saves time and avoid user flustration. This is really helpful in large forms.
However demerit is a bad guy can override the client side validation, Hence to avoid such case we should validate in serverside also before processing data.
Since you can modify the Javascript file when you are in Chrome and press F12, the developer tab, will anyone be able to modify the Javascript there and change the behavior of my site and therefore how it interacts with the server?
Reason I am asking is I want to decide whether to put a piece of code for validation (eg. check email) on the server side or the client side.
Yes, anyone can change the Javascript and HTML of your site to submit anything to your server. You can even change POST/GET requests as well (for example, this plugin is available to Firefox users: https://addons.mozilla.org/en-us/firefox/addon/tamper-data/).
Always have server side validation for any input.
You can never depend on client-side processing being secure. There are many ways to alter or bypass client-side javascript. Client-side validation is nice to be able to give the user a quick response if validation fails, but it should always be backed up by server-side validation.
You should use a double validation:
On the server side to prevent data corruption etc.
On the client side to help the user to fill quickly his form without the need to submit (using a check or cross sign when the user exits a given field
For the business sake, you should only rely on the server side to determine if an given input is valid.
a savvy individual can modify the javascript in their browser, but that only affects their browser.
So yes, someone could disable a validate mechanism implemented in JS, which is why you need to validate on the server.
Anyone can modify the code in client-side but only users with FTP or other thing permissions can modify them server-side.
You should always do validation in server side. If you want (for example make server load smaller) you can make client side validation but it is not enough, since user can easily disable JavaScript.