I'm about to start creating a website that takes values of form inputs(dropdowns, radial boxes, etc.) from the client(no user accounts involved) and performs calculations besed off of these values. These calculations are rather sensitive and I know client side javascript can't be made secure.
Is it possible to pull these client side values and run the calculations server side with node.js? If so, how secure is that? What other precautions can be taken?
If that's not possible or secure, what are some alternative solutions?
You have a couple options for sending the data to your server and then performing the calculations there.
You can put the data into a form and you can submit the form to your server. The server will then receive all the data from the form and it can do whatever it wants with the data. The server can then return a new page with whatever results you want to show and the browser will show the results page.
You can collect the data from your web page and send it to your server with an Ajax call made via Javascript. The server will receive the data from the Ajax call and can do whatever calculations it wants with the data. It can then return whatever data is appropriate from the Ajax call and the client will receive that data in Javascript and can then display it in the new page (or do whatever else is appropriate).
Code to make calculations on your server will be as safe as the security is on your own server (which can be made plenty secure). Server-based code is not normally available to the outside world.
If you are concerned about security of the data or result in transit, then you can use https between your webpage and your server.
When you ask about "security", folks can provide better answers/info if you say more about what you're trying to protect, why you're trying to protect it and what types of threats you're trying to protect it from. Security is best designed and implemented for very specific reasons and you haven't provided any of those type of specifics.
Related
We have an application which is destined for https so the data being transmitted is protected (or should I say as protected as need be) I would like to know about protecting/hiding (or similar) queryString values. Its a jQuery/Javascript front end which communicates using a mixture of GET and POST with the database via classic ASP web services. The web services sends JSON back to the client.
I realize the front end code could be changed so everything is passed using POST however the application is finished and tested ready to deploy. There are some key values that are being passed in the querystring which should not have been. Is it possible to make it so the querystring values can not be inspected or sniffed. The URL and querystring together will provide a direct link to the raw JSON. We would like to prevent this. Perhaps there is some jQuery/AJAX feature which can be explored. Perhaps some server IIS level tactic? I guess the sniffing occur before the request gets the the server where the webservice sites therefore some server/IIS level tactic is not an option.
Any ideas/advice would be great, thank you.
You can use HTTP headers to send data to the server that is slightly less visible, but can still be detected using more advanced developer tools and loggers. For example, this answer descibes using jQuery/Javascript (as you've asked) to send data without using QueryString.
You can't really prevent the client from being able to trace these details though.
The solution I personally suggest to you is to look into session state. By scoping a valid data response to a certain session state, and returning null when the state is invalid or expired, you can limit access to the data. This could be after just 1 time its been retrieved. This strategy would involve a generation of a token or code that is passed out from your server at an earlier stage, and used when asking for the data in question.
Another alternative is to either use SSL or encrypt your data and drop it into a posted control such as a text input box. Microsoft adopted a similar process for their VIEWSTATE within ASP.NET.
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.
This quite tricky. I would prefer having serverside key authorization, but we are limited to a JavaScript only implementation. Customers will use a JavaScript library, that will request certain pieces of data - but this customer has to be authorized to use this data. That's where the authorization part comes in, that does not involve any serverside (At the customers side) implementation.
The JavaScript library is requesting data at my server, but not all customers are allowed to see every piece of data. Thats why I need to authorize the customer.
Currently I simply place a customer-ID in the JavaScript library which is being sent to the server to authorize. This is not very safe though, you could simply copy this ID over to your own library to get data from the server you can normally not retrieve.
I don't need a 100% waterproof solution, but my current implementation is just pure garbage. As the solution needs to be pure JavaScript, I understand there will be many ways to spoof the authorization. I just need something some authorization that's the safest as it will get with JavaScript only. Any idea?
I have an interactive html5 app that let's people customize products on the client-side. As a user is customizing, the price updates based on individual component prices.
Once this is done, the person hits checkout, I send the customization to the server, and the server takes over the checkout process.
Obviously sending price data to the server is pointless, since anyone could spoof the POST data. So, I tried writing a server side script that will regenerate the price according to the components selected (sent to the server with the customization data), and show that on checkout instead. However, the server side calculation is proving very difficult, due to complex customizations offered; and it seems like I have to rewrite the entire client-side customization logic on the server-side (which is a lot of work).
Before I continue writing the server-side script I wanted to know if it is at all possible to send the price data to the server in a way (asymmetric key auth perhaps) that cannot be spoofed?
Never trust the information clients send you.
To answer your question, it is possible to use encryption to send data from the client to the server. However, the problem here is the data being encrypted can be modified even before the encryption. So, encryption is not really the solution. The client might modify the data before encryption and the server will not know this if there are no server-side checking.
Even with public-private key encryption, this will still be unsafe. There will only be an assurance that your data will not be tampered from the user to the server. It cannot be spoofed by third parties but your user can spoof it, thereby making the encryption pointless. So, do not trust the user to send you valid legitimate information.
You should really double check everything in the server. And you will not need encryption unless privacy is an issue (which probably is based on your description). This can easily be solved by using https.
The client-side javascript you created can serve as immediate feedback to the users, they see prices as they make changes to the forms. This is good because they do not need to wait for the server to process the information, which the server should upon submission of the form.
You should never never never trust client-side code. If you want to spare yourself the headache of rewriting your client-side code, you could just put the relevant JavaScript on the server and call it from your server code (Not that I'm suggesting you should do that). Another thing I would recommend doing is recalculating the price based on the contents of a full postback once the user is done with their customization, and then displaying the recalculated price to the user in order to allow them to confirm it. That way if any client-side shenanigans have occurred, the user will get the real price anyway, and I'm sure that if it differs even slightly from the previous price, your support people will hear all about it.
I have an ASP.net webpage, that periodically (once in a minute) makes a call to my WCF REST service. My REST service responses some XML data. After getting it I make some further operations on that on server side in my ASP page.Note, this post data process in ASP is required, I can't avoid it. I know my life would be easier without this step, but I must do it.
After I'd like to pass this data in XML format to a client side javascript, that can parse it and show infos to the user based on this data. How can make this call from server side? What is the best pattern/practice to do it?
.net4/VS2010
if you want to call a function that already exists, that will load your data to the screen, you can tell the server to return your data and then ajax will grab that data and call a callback function.
if you are not using ajax, you can reload the whole page with the new data.
HTTP is not designed to push data from the server to the client. I'm not really familiar with ASP but usually you have the following possibilities to "push" data to a client javascript application via HTTP:
page reload via meta refresh (which doesn't actually push data;) )
periodically polling an "job queue" URL using javascript
comet (see http://en.wikipedia.org/wiki/Comet_(programming)) for an overview)
Web Sockets (which actually pushes data to the client but is only supported by newer browsers)
I've been using atmosphere (http://atmosphere.java.net/) which works pretty well in java application containers, which provides an abstraction layer over the underlying technology. I don't know if there is something similar out there in the ASP-world.
cheers
Martin
Tom, in that case just do the following