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 ing 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 ments, but this may be prone to the same vulnerabilities as @dotnetom replied. (See ments)

Thanks again to everyone who contributed.

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 ing 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 ments, but this may be prone to the same vulnerabilities as @dotnetom replied. (See ments)

Thanks again to everyone who contributed.

• javascript
• jquery
• html
• ruby-on-rails

• I don't think your proposed solution would stop anyone if they really wanted to change the values, even if it did, a user could theoretically just open fiddler and edit the request, or create a custom request in something like postman. You should implement some server side validation if these field are extremely important. – Robin Commented Mar 11, 2016 at 8:35
• Yes any proposed method would easily be beatable. You simply cannot trust that client side values have not been manipulated. – Dave Pile Commented Mar 11, 2016 at 8:35
• 2 There is no way to make this secure. The third party service needs to have some signature field that depends on all submitted values, and only process the request if the signature and values are valid – krivtom Commented Mar 11, 2016 at 8:36
• use Escape ex. javascript escape() or encrpty your information – Visarut Sae-Pueng Commented Mar 11, 2016 at 8:37
• Client side validation is just to make it pretty for a user, stops the AJAX or postback being required for them to see if its valid or not. Server side validation should be used also to prevent any nasty people messing around with stuff. Nothing is secure on the client and everything ca be manipulated in some form. – ste2425 Commented Mar 11, 2016 at 8:38

4 Answers 4

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./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 overe 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;

1. Store the vals on the originating server with a unique ID
2. Send the confirmation back to the originating server for validation
3. 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 promised.

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.