javascript client side security [closed]

I'm concerned about javascript security as client can view and edit code, I know to overcome this we can use ajax calls to run critical process on server. But recently I was going through parse cloud code, a part of it runs on server. I would like to know if that's the answer to javascript security concerns and is it safe?

回答1:

Is Parse.com server-side Javascript safe?

Server side Javascript is relatively safe. In the case of Parse.com (I am not very familar with their systems) it appears to accept client-side data. Client side data is always unsafe. That being said, you can make it safe by parsing it (pun not intended) to ensure anything potentially dangerous is stripped out before running it.

The safety in this system then, is dependent on how well you write your code.

Is server-side Javascript safe?

Related to the above, server side Javascript CAN be safe, provided it is written in a secure manner. IE, only data is passed and any data that needs to be secure remains on the server and is only updated by the server.

For example if you are updating game score (taken from some parse.com examples) instead of sending the server the score to update, send it the action that triggers the score update and let the server resolve the action and add to the score. This is safe. Sending the score itself is not, as the score can be manipulated by the client.

Is Parse.com client-side Javascript safe?

Absolutely not. The client is in the hands of the enemy - you can never ever ever trust the client not to manipulate their data and/or the code that generates it.

The onus is on you, the developer, to make sure that your data is being handled and processed only by a system that cannot in anyway be manipulated by the client.

So, is parse.com safe?

Echoing everything that I have already said, parse.com is as safe as you make it. It simply depends on how well you engineer your application.

Is server-side Javascript the answer to security concerns?

Server-side anything is inherently more secure then client side. Is it a one stop fix for all security concerns? No. There are still plenty of dangers in bad coding (IE: SQL Injection) or even open ports (IE: Email forwarding through a web server). Thus there are two aspects to this sort of approach, securing the server and securing the code. These are usually divided up to people of an appropriate skill (developers should not be asked to close ports on the servers, for example, unless there is no one else to do it and you have run out of bananas for the trained monkey).

However, not everything can be run on the server. For example, capturing client input and drawing elements to the screen are two things that the client side will just have to accept. This is where it is on you to decide the needs of your system.

Take our example above about posting score to the server via action instead of score number, it is inherently more secure then sending the score, but it is still not totally secure when sending an action because the player could easily spoof the system to send repeated actions.

You COULD develop some logic to see if the action is allowable, or some even crazier logic to decide if the action rate of a player is Human, but then you could just never let anyone report their score to the server and THAT would be the most safe and also result in a not-very-fun-game.

It's always a calculated risk to decide what areas of anything you can and can't secure and what aspect it will have on the application (or Game - I use game because parse.com examples used game) in question.

Further StackOverFlow Related Reading

There are some good notes here about the particular vulnerabilities of Javascript Injection: Javascript security risks?

This one speaks directly to client-side/server-side validation: JavaScript: client-side vs. server-side validation

There are some notes here about 'how-to' minify and obfuscate code: How can I obfuscate (protect) JavaScript?

Regarding obfuscation in Javascript, see here for lots of notes about how unsafe it is (especially in the comments): Hardest-To-Reverse JavaScript obfuscator

回答2:

If you are really concerned about your javascript, then you can

1) collect your JS routines in a single JS file and minify it using js compress which will make it hard to read and understand.

2) scramble/obfuscate your JS code using JS scrambler which will make it a little more difficult for the cracker to crack your JS

However, considering the vast array of tools available on the web, in my opinion, JS can be compromised any time by the cracker who has a malicious intent. This can be compensated by imposing strict security protocols on the server side.

Hope it helps!