I have several forms which contains data fetched from Google Directions Service (JS API), distance for example is especially important to me.
Sure, I know that I cant really prevent user from messing with the data in input fields, what I am asking is if there is some technique to make submitting manipulated form painful enough to stop people trying.
My hopes arent too high on this but I want to make sure before I get into some server-side solution.
Thanks in advance.
Since you are just getting data via the JS API and do not need any changes to those from user, how about sending the data to Server over AJAX calls as and when it is received perhaps with some your own simple encryption. This would certainly increase the number of requests but depending on the amount of data, it can work out for your usecase. Even if you would want to post some form data from the same page, it could be attached to a user's session on the server.
Please note that this is not fool-proof with firebug and the likes but gets more difficult for someone to play with the values.
try using hidden input fields:
<input type="hidden">
These get submitted to the server but are not visible to the user.
Related
I'm working on a React app and am thinking about implementing a CSRF mitigation technique. I decided to go with Same-Site cookies but before that, I was looking into using CSRF tokens and read numerous posts saying they should be stored in a hidden form field. What I'd like to know is if there is a difference between storing it in a hidden field and storing it in something like a class variable? If the point of it is to keep somewhere for when you a ready to send a request to the server, does it matter how it's stored on the client-side?
The reason a CSRF token is stored in a hidden input is so that it gets sent to the server automatically when the form is submitted. If you are manually sending a request to the server and grabbing the data yourself, you could store the CSRF anywhere. It would be best to be consistent and just store it in a hidden input.
If you put it in a form field then everything typically just works, but if you put the value anywhere else then you have to write logic to extract that value and insert it back into the form data that is being sent to the server.
Using the form field also works for both ajax and standard form submission, so most tutorials are going to promote it over methods that only work for one or the other.
The other answers are correct in that for a tutorial that you find somewhere (or a generic one on csrf) it's easier to demonstrate it with the token being written in form fields, also a traditional web application will just work that way.
What others did not mention is modern single-page applications like one with React do not work like that, often you don't even have forms, and writing the token to form fields makes no sense. So these applications typically do not do that.
There is also a practical aspect to this. You mentioned storing it in a class variable. That's fine, but how will it get there? The token is usually (not necessarily, but that's a sidetrack for now) generated by the server-side web app. How will the javascript SPA get it? You need to write it somewhere in the page, spending a separate request to get it would be a waste of resources. One thing that usually happens is writing it in a meta header (eg. <meta name="csrf" content="...">) at the top of the page so your SPA can read it from there and store it wherever it wants.
Another thing that often happens is csrf protection is not even needed, because api authentication is based on something like request headers (instead of something in a cookie), which would not be sent automatically by the browser, so classic csrf is not feasible.
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'm new to web development and I'm trying to make small projects to better understand how javascript works and how interactive websites are made. So I wanted to make a simple website that would save links that you would enter using input/form submission. but what are the ways which I can use to store it on the server so when I open the page next time the website retrieves the saved information and displays it?
I know this question is pretty open, but I'm really lost in this part of web development because I'm seeing too many completely different things on the internet like PHP, ASP.net and what not. Can someone help me out?
It would be very thankful if someone can send me a link to a related tutorial or some similar resource, as well.
If you to do that, you will need a server side program with a Database.
Here is a tutorial for PHP, a popular language to do web pages http://www.w3schools.com/php/
When you submit your data in the form, That data will be sent to the file mentioned in the action attribute of the form. Now, each input element of your form will have a name attribute which you can use to refer as a key in your GET or POST super global array depending on the method attribute of your form tag.
I know it may sound confusing without example. But, This is explained at many links on the web. Try searching for form submission with post.
Decide on which technologies that you want to work with. I prefer you to use ajax with instead of just using javascript.
Link for flask tutorial http://www.fullstackpython.com/flask.html
Store the data in the client side is much simple I think. While storage in client, you can use localStorage sessionStorage and cookie.
localStorage you can storage whatever you want and it has no expiration time
sessionStorage the difference between localStorage is that it has a expiration time, A page session lasts for as long as the browser is open and survives over page reloads and restores
Cookie is much simple and can store limited value in string format
I need to fill up form in another website which is not in my control. I have some datas filled in my website, I need to pass those data and fill the existing form in another website. Is it possible to fill the form using php, jquery?
For simplicity,
I want to redirect user after filling up form in my site abc.com save it in my database and redirect to external website xyz.com and fill the existing form there.
Your best bet would probably be to replicate their form 1:1 on your site and submit it using <form action="their_form_url">. This would work, however, only if they don't have XSRF countermeasures in place (most sites don't, some do).
You will not be able to manipulate the form with JavaScript in pretty much any way unless the iframe target (i.e., their site) is in your domain.
If you only want to fill the data in without submitting, you are out of luck. Both JS and cookies follow the same-origin policy, which explicitly dictates defenses against this kind of behavior.
It all depends on the target website. If they pre-fill their form with $_GET data or $_POST data, you can just pass on that data. A good shot may be to try to post wrong data (like a wrong captcha value) manually and see how they fill their form again. Maybe you could use that in your favor.
Although, another possibility is to load their site in an iframe, and put the data with Javascript, by accessing the iframe code. I'm not sure about this, though. I just think it can be done. (Please correct me, if I'm wrong)
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