i'm wondering why i have to validate forms on client side while they anyway need a server side (ajax) validation for not being hacked?
IS there any benefit on having both client side and server side (ajax) form validations?
I mean they do the same thing but ajax takes 300ms and client takes 0ms probably, is this a really good reason why to make a duplicated validation? :P
Plus, using a single server side validation you remove not needed js from client side, i see only benefits in having only ajax validation, what about you?
If i'll go for a client side validation, is there some way/practice/logic to follow to not duplicate validation on server side ? Like ONLY if client side validation is ok server performs the action/request ?
Actually my logic is :
Server + Client side validation
less requests -> more code (duplicated) -> more troubles -> better UX
Server side validation (only ajax)
more requests -> less code -> less troubles -> probably same UX !?
Sorry for maccheronic english asd :D
You should be thinking of client-side and server-side validation a separate tools to accomplish separate goals.
The reason that you absolutely should be doing validation on the server side is because there is absolutely nothing preventing me from manually editing the Javascript files to remove any client-side validation. You simply can not prevent that, even if your code is minified and obfuscated (both of which can be un-done).
The reason that client-side validation is nice (but not as necessary as server-side validation) is because it actually assists the user in creating a form that will proceed to pass server-side validation. AngularJS can easily validate a form after every keypress. That is awesome from a user perspective. Think of all of those forms where there is a "Password Strength" meter next to the password field, saying that the strength needs to be "good" or better in order to pass validation. If you were to do an ajax validation call after every keypress, you would increase your server load by orders of magnitude.
The idea is that server-side validation is only going to happen after the user hits the "Submit" button. By the time the user even thinks about hitting the "Submit" button, they should already know that their form is going to pass validation.
However, lets get down to your real problem: You want to enter your validation rules only once. That is awesome! Now you are thinking DRY! The only problem is that this would require using something in the back-end to automatically generate your client-side validation, which can be difficult. The alternative could be to have your front end make a call to the server, asking for the rules, and teach your front-end how to interpret the response. This would be an additional call, but it should be a relatively cheap one. Unfortunately, this is quite a bit of extra work. It may be worth it if you expect your form to change frequently in the near future. Being able to change it in one place instead of two would be a huge boon in that situation, and may be worth the additional time spent up-front.
So, is Client side validation absolutely needed? Well, that depends. Customers can be very finicky, so if this is a form that actually generates revenue for you (bank account application form), then you need to realize that some customers might close out of your web-page if they click "submit" and see their form fill up with red all over the place. It is a much better experience if they are told the problems as they happen, rather than all at once.
If, however, you are creating an intranet application on a deadline, then you may need to look at priorities and make a judgment call ;)
Assuming you validate all potentially threatening inputs (such as fields that proceed to make SQL queries) on form submission, all form validation should be performed on the client-side, as it makes for a significantly nicer user experience.
I'll reiterate. This assumes you validate all potentially threatening inputs on form submission! It's extremely easy to make a request that completely bypasses your validation and if you blindly put your faith on client-side validations, you may be in for a serious headache in the future.
To answer more specifically, the only time you'd really want to make an AJAX validation is when you need server-side data for the check that can't or shouldn't be sent before validation (such as unique username, email, etc.)
Related
I have an array of hidden input boxes that carry especially sensitive data, and the form is submitted to a third party application on click of a button.
The values of these inputs are set server-side. The page that has these inputs is a confirmation page, and the user clicks the button to confirm the transaction and the data in the hidden input boxes is posted.
This is inherently very insecure, as anyone with half decent knowledge of javascript could load devtools and use javascript to change the values of the hidden inputs before submitting the data. The page even conveniently has jQuery loaded! Ha! (I tested this myself).
This is running on a private application with a limited user set and hasn't been a problem so far, but the same architecture is now required on a more public space, and the security implications of shipping this would be a little scary.
The solution would be to post the data server-side, but server-side posting does not work (at least not in a straightforward way) because of how the third party application is set up. The alternative would be to somehow prevent javascript (and of course by extension jQuery) from changing the values in the input boxes.
I was thinking of implementing (using setInterval) a loop that basically checked if the input values were the same as the original, and if not, changed it back, effectively preventing the values from being changed.
Would my proposed method be easily beatable? Perhaps there is a more elegant and simple way to stop javascript from editing those specific input values?
** EDITS
For anyone coming here along this path:
After multiple considerations, and an inability to sign my data with keys from the third party application, I resorted to manually posting the data server-side from my application (a ruby on rails app).
It may take some fiddling to get the right payment page to display after the posting happens, and I haven't tested it yet, but in theory this will be the way to make sure everything is submitted server side and the user never gets a chance to tamper with it.
For Ruby on Rails apps, there are some good insights at this question.
This answer also shows how to use the hacky autosubmitting form that I mentioned in the comments, but this may be prone to the same vulnerabilities as #dotnetom replied. (See comments)
Thanks again to everyone who contributed.
You solution based on the setInterval and other javascript functions will not work. Person with a dev tools can easily disable it from the console. If there is no way to send these parameters from the server, the only option I see is to generate signature with some public key from all the parameters need to be sent. The third party application can validate this signature and check that parameters are genuine.
But again, it is not possible if you have no control over third party application..
See an example from twitter: https://dev.twitter.com/oauth/overview/creating-signatures
If someone wanted to change the value of those input fields, they could just disable JS (and in this way get around your checking algorithm) and update the input values inside the HTML.
This can quite easily be done with FireBug, for example. No JS needed.
If sensitive data is involved, there will probably be no way to get around server-side posting or at least server-side validation.
I was thinking of implementing (using setInterval) a loop that
basically checked if the input values were the same as the original,
and if not, changed it back, effectively preventing the values from
being changed.
Attacker can easily overcome this by
overriding the method which is doing this periodic checking. Check this solution
Setting up a browser extension which can change values after setInterval() has changed it
Disable JS.
Basically client-side validation is just to ensure that server-side call can be avoided to reduce network trips, it cannot be a final frontier to protect the integrity of your data. It can only be done on server-side, which is an environment user cannot manipulate.
I know this is an older post, but it piqued my interest because of related (but not the same) issues with javascript security.
Just thinking about the logic of a solution for the OP, and assuming I understood correctly...
The server sets the vals, the user confirms, and the confirm goes to a 3rd party. The problem is that the vals could be edited before post to the 3rd party.
In which case, a possible workable solution would be;
Store the vals on the originating server with a unique ID
Send the confirmation back to the originating server for validation
Originating server forwards to the 3rd party if validation = true
In the event the 3rd party needs to send data back to the user, and it is not possible to let the server act as a go between, (which really it should) then you are a bit compromised.
You can still send data back to originating server with an AJAX type true fale response to the user.
Obviously, a malicious user could intercept the AJAX response using javascript edits but, (assuming the 3rd party app is looking for some kind of user ID), you would flag that ID as invalid and alert the 3rd party app before the AJAX response is delivered to the user.
otoh, hidden input boxes asside, the bigger consideration should be manipulation of the client side javascript itself.
One should have a validation wrapper for any sensitive functions or variables, to ensure those have not been modified.
I am building a school project which is a website and I have a form and I'm using javascript as my validation. Is there any chance that if the user turned off their javascript, they can submit their form empty? or I better use php as my validation?
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 making "sticky" forms where the server remembers what was entered in each field and fills it back 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, for example?
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.
FOR MORE REFERENCE
Any frontend validation is just for better User Experience, and you can only trust the backend with sensitive logic.
Basically any data can arrive from the frontend, and you should always assume that your users are malicious ("all input is evil"), and validate on the backend.
Javascript validation is not secure at all, people can either turn off their Javascript or edit your code. Anyone who is set on getting around your validation will have an easy time doing so. PhP validation is the better option. since a user can't just turn off your PhP or change it.
What you could do if you want to make the validation look fancy, is have front and back end validation in place.
You can use html5 tags, they are pretty easy to use. Like you can use :
PATTERN attribute to define the regular expressions,
required for required fields and many others.
All of the html based validations, I must say all of them, can be fixed via tools like firebug. You might need to apply the validation on server side as well if you want to make it really really robust. I would recommend you to go for some MVC frameworks like
YII or may be code igniter
They are pretty easy to use and very powerful specially scaffolding features.
Before asking the question, I admit that this method is uberly discouraged and not secure. I am aware that to achieve this is through SSL.
However, I am developing an HTML5 apps (and it seems that implementing the SSL approach would take a lot of time) and I would like to know the best way to POST a form content.
i.e I have the following form
<form id="someform" name="someform" method="POST" action="some/server/url">
The way this form is submitted (currently) is using ajax $("#someform).serialize() and so on..
Using this implementation I am facing with (at least) these 2 immediate problems:
User could use tools (i.e TamperData | a firefox addons) to modify the posted content (Interception-and-modify).
User could forge the data by sending 'fake'submission (Forging)
I am wondering if there is somehow I could at least (obfuscate the POST-ed) value.
I came across with this great http://www.jcryption.org/ tools, but not sure how should I implement it to workaround the problem I am facing.
ps: again I am aware that relying on client-side script is way less secure compared with handling all execution from within the server-side.
framework + language I am using is: CodeIgniter + PHP + JavaScript (jquery)
1st Amendment:
I am sure there is at least a work around using this theory
First, I am not too worried about the confidentiality part of my data, that is the POST-ed value will not give any valuable information even if someone else knows what it is.
What concerns me though is the integrity and the authenticity of the POST-ed value. This is simply means that no one else should tamper the information once its being transmitted (once the submit button is clicked), nor anyone could forge or create a fake value (spoofing the server).
This theory leads to digital signature, where (again in theory) I should somehow sign the POST-ed value using server PUB-key, then hash the POST-ed value using the server PUB-key and finally send both the original POST-ed value along with the hashed value.
Prior sending the POST-ed value, the client MUST request for the server PUB-key, so the client can hash the POST-ed value. The server could probably store the PUB-key information along with SESSION information.
Then the server will have to (again) hash (this time with the server PRI-key) the original POST-ed value (sent by client) and compare the two hashed value. If those value is the same, it simply means it is authentic.
Now the part which I am yet to understand is the HOW.....
is there any tools/frameworks/plugins/tutorial/example on how to do this? since it would be too much for me (not to mention the limited amount of time I have) for developing the whole Public-Key-Infrastructure from scratch
Take one step further and realize that a user can encrypt faked data as well.
And SSL won't help against such a tampering.
That's a web-development axiom: everything can be faked on the client side. Period.
So, instead of encrypting anything, just verify your input on the server side, like every other site does.
Use sessions to store the data that a user should have no access to.
User
Spoofed Form Submissions
You will get full info here
I want to validate user input on a Web Form, like valid numbers, date etc. Which one is the better way to validate, using Javascript functions or using Constraints in SQL Server?
I want to reduce the code as much as possible and want to use most of the power of SQL Server itself.
You must do both. Client-side validation to prevent all but sensible input, and server side (including in code prior to hitting the database), to prevent more malicious attempts at doing things.
So, in ASP.NET, at the very least, use the built-in validator controls, which emit JavaScript if you want them to. Then, in server-side events that occur when, say, a submit button is clicked, check Page.IsValid to ensure the JavaScript was not bypassed. Next, ensure you are using parameterized queries to prevent SQL injection. And, lastly, always use constraints to ensure data correctness if all else fails.
I would suggest both on the client side and on the server side, as potentially someone could have Javascript disabled and still be able to submit invalid content.
I would suggest either writing constraints on your server side (in your actions) and then in your client side JS; alternatively you could look into ASP.Net MVC which allows you to write the validation in your model class (.cs) and then via an AJAX form the client side validations will be performed automatically.
Both because :
1) if you allow the web form to pass invalid input, you are wasting bandwidth. Plus you have to prepare another page which says "oh you input something wrong please try again haha"
2) if you allow the DB to accept invalid input, its outright wrong because you risk corrupting the data (e.g. when javascript validation fails or missed something)
Really this depends on what you are looking for. If you want something that is quick and very load load then using Javascript is the best way to go since there is no round trip to the server and wait times for the client. Downside is that Javascript can be disabled. This means you also have to have validation in your ASP. I wouldn't go with using constraints in the DB other than what is required for a relational database because that just makes your site break.
The general rule when submitting data via web forms is that you must validate on the server side, and you may also validate client side.
If by "SQL vs. JavaScript" you mean server vs. client, the SQL is imperative; the JavaScript is optional but in modern apps you validate to avoid roundtrips to the server. Note that you may perform server side validation outside the database but in many cases, as in your words, "leverag[ing] the power of SQL Server" is appropriate.
I guess that it depends on whether or not you will be writing into the database from a different application. I am a big proponent of enforcing data restrictions at the database level, as well as the client application level, because you never know when you are going to need to write a random script to batch import data from a different source etc.
I'm still debating whether I want to do this or not but what I'm considering is preventing users from entering hyperlinks into a HTML form in my app. This is to avoid spammy links from showing up for other uses of the app since the app is based on user generated content.
This is a Rails app, so I could do some backend validations on the model after the form is submitted by the user.
But I was wondering whether it might be preferable to perform the check in jQuery/JavaScript before any submission takes place. This way the user could be notified immediately without any backend processing.
Which would be preferable here - client-side or server-side validation?
You only have control over data when it arrives at your server. If you use JavaScript to try to strip out spam, then spammers are just going to turn JavaScript off.
Build a server side solution.
Once you have that, think about duplicating the work client side to make things nicer for users.
Use both.
Client side validation lowers stress on the server when the client has the JavaScript turned on.
Server-side is your last line of defense which should be there for the case the user has JavaScript turned off.
You say :
so I could do some backend validations
on the model after the form is
submitted by the user.
No ! You must do validations on the backend !
Javascript can be disabled, forms posting can be forged ; so you always need to develop validations / filtering / whatever security measure you want on the backend/server.
Only then, you can eventually add some JS thing, so your application is more user-friendly.
Both............
You should use both, use jQuery validation plugin on the client, and whatever method is appropriate on the back-end (I don't know ROR).
An ajaxy validation solution could perform server-side validation while the client is inputting information, and provide feedback/prevent submission accordingly.
Hope that helps.
Spammers often uses some kind of script that analyses the form and builds form data and posts on it's own, so client script is totally useless against most spamming.
JavaScript validation is great as a way to hold the hands of non-malicious users. "The passwords you entered don't match", "looks like an invalid e-mail address, please double-check", etc.
The downside of JavaScript is that there is no way to verify that it ran, nor that it ran as intended. A malicious user, or one with a glitchy browser plugin, or one with an overzealous firewall/content blocker, a spambot without JavaScript, a user with NoScript enabled, or any number of other situations can result in your validation never beeing triggered.
As such, your server should always validate data if validation is necessary. JavaScript can be a first line of defence, but it can never be the final one.