Develop Reference

How to prevent javascript from changing input value

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.

Angular js - form and inputs - ajax vs client side validation

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.)

Which is the better way of validating user input, DB Constraints or Javascript?

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.

What is a good way to get feedback from a user on a website?

I'm working on a website for my county's fair. I want to allow my visitors to be able to ask me questions by inputing their name, email, and comment in a form like this one:
http://lincolnfair.net/images/feedback.JPG
So I guess my real question is how can I send an email (using JavaScript/JQuery) to myself with all these fields as the main body of the email.

You should use a server-side script (e.g. PHP, Python, Perl, etc.). With pure HTML and JavaScript, you can use a mailto form, but this will be very unreliable.

I will suggest uservoice.com , it can integrate with your site nicely, a much more powerful user feedback system, without spending time to code the feedback system yourself

As others have indicated, this is a typical task that can be solved easily using a server-side language. Javascript and jQuery aren't the right tool for this particular problem. To point you in the right direction, use method="post" for your form, and you can access users' submission in a PHP file by examining the $_POST variable. If a <input> element in your form has name="email" in your email, you can access that variable in PHP as $_POST['email']. If you're interested in a PHP solution, look at the documentation for the mail() function.

Jukka has a good guide on How to write HTML forms. It should give you everything you need to produce something functional.
You need a server side component, nothing client side will be a reasonable substitute for that. JavaScript won't help for a form as simple as the one you describe.

The most reliable way will be to use a server side script in your preferred language. The specifics of how to do this are probably outside the scope of this question and would depend upon your language of choice.
Your other option is to set the action of the form as a mailto: which will use the visitors preferred email client to send the email. This will work but is really bad and relies on the viewer having an email client installed and configured.
you can find out more information about the mailto option at http://www.chami.com/tips/internet/010597I.html
Another good option would be a third party site such as www.wufoo.com which handle all of the email business server side for you on their own servers. I believe Wufoo even allow you to embed their forms within your own site.

If you want it to be available on every page, you might want to consider using jQuery and the UI Dialog plugin. You could set it up so that the default feedback is a mailto which gets replaced using javascript with a link that brings up a jQuery Dialog containing the fields you want to collect. This could be submitted back to your server via AJAX and delivered to you via email from the server.
EDIT: Since you've edited your question to indicate a server-side only solution, the above seems somewhat out of context. With others, I would agree that using some client-side code to actually send the email is the way to go (as alluded to above). I think it's preferable to use your own server for this, but I'm sure that you can find many "form to email" services. I would avoid these, unless you want your email addresses harvested for use in SPAM. You might also be able to use a signed applet or ActiveX control for this, again I would not go down that route. As indicated above, I would let the browser handle the interface, but my server handle the sending of the email.

I am not sure i understand your question completely, but if all you want to do is conduct a survey over email, i don't think you need to use jQuery or HTML.
A very simple way to do it is to use the 'Forms' feature in Google Docs.

Prevent hyperlinks from being entered into a html form: client-side or server-side validation?

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.