javascript客户端安全 [英] javascript client side security
问题描述
我担心javascript的安全性，因为客户端可以查看和编辑代码，我知道要克服这一点，我们可以使用ajax调用在服务器上运行关键进程.但是最近我正在解析云代码，其中一部分在服务器上运行.我想知道这是否是javascript安全问题的答案，并且安全吗?
Parse.com服务器端Javascript安全吗?
服务器端Javascript 相对是安全的.对于Parse.com(我不太熟悉他们的系统)，它似乎接受客户端数据. 客户端数据始终是不安全的.话虽如此，您可以通过解析数据(无意使用)来使安全，以确保在运行之前清除掉任何潜在危险.
那么，该系统的安全性取决于您编写代码的程度.
服务器端Javascript安全吗?
与上述内容有关，只要以安全的方式编写，服务器端Javascript就可以是安全的. IE，仅传递数据，任何需要保护的数据都保留在服务器上，并且仅由服务器更新.
例如，如果您要更新游戏分数(摘自parse.com的一些示例)，而不是将要更新的分数发送给服务器，则将触发分数更新的操作发送给服务器，然后让服务器解析该操作并将其添加到分数.这很安全.本身不发送分数，因为分数可以由客户端操纵.
Parse.com客户端Javascript安全吗?
绝对不是.客户端在敌人的手中-您永远不会永远信任客户端不要操纵其数据和/或生成的代码它.
开发人员必须承担责任，以确保您的数据仅由客户端无法操纵的系统处理和处理.
那么parse.com安全吗?
与我已经说过的所有内容一样， parse.com与您所做的一样安全.这完全取决于您对应用程序的设计程度.
服务器端Javascript是否可以解决安全问题?
与客户端相比，服务器端的所有内容本来就更安全. 这是一站式解决所有安全问题的方法吗?否.错误的编码(IE:SQL注入)甚至开放的端口(IE:通过Web服务器转发电子邮件)仍然存在很多危险.因此，这种方法有两个方面，即保护服务器和保护代码.通常将这些内容分配给具有适当技能的人员(例如，不应要求开发人员关闭服务器上的端口，除非没有其他人可以这样做，并且您已经用尽了香蕉来训练猴子). /p>
但是，并非所有内容都可以在服务器上运行.例如，捕获客户端输入和在屏幕上绘制元素是客户端必须接受的两件事. 这是您决定系统需求的地方.
以上面的示例为例，通过操作而不是分数号将分数通过服务器发布到服务器，从本质上说比发送分数更安全，但是仍然不是完全发送动作时安全，因为玩家可以轻易地欺骗系统以发送重复的动作.
您可以开发一些逻辑来查看该动作是否允许，或者甚至可以使用更疯狂的逻辑来确定玩家的动作速率是否为人类"，但是您永远都不能让任何人向服务器报告其得分，这样就可以了是最安全的，并且还会导致游戏非常不有趣.
决定有什么地方可以保护和不能保护的东西以及它在应用程序(或游戏-我使用游戏，因为parse.com示例中使用的游戏)的哪个方面，始终是一种计算出来的风险.
与StackOverFlow相关的其他阅读内容
关于Javascript注入的特定漏洞，这里有一些很好的注释: JavaScript安全风险?
这直接说明了客户端/服务器端的验证: JavaScript:客户端与服务器端验证
这里有一些关于如何"最小化和混淆代码的注释: 如何混淆(保护)JavaScript?
关于JavaScript的混淆，请参见此处，以获取有关其不安全性的大量注释(尤其是在注释中): Hardest-To-Reverse JavaScript混淆器
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?
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
这篇关于javascript客户端安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
