javascript客户端安全性

javascript client side security

本文关键字:安全性 客户端 javascript      更新时间:2023-09-26

我担心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服务器转发电子邮件)仍然有很多危险。因此,这种方法有两个方面,即保护服务器和保护<strong]代码>。这些通常由具有适当技能的人组成(例如,不应要求开发人员关闭服务器上的端口,除非没有其他人可以这样做,而且你已经没有足够的时间来训练猴子了)。

但是,并不是所有的东西都可以在服务器上运行。例如,捕获客户端输入和在屏幕上绘制元素是客户端必须接受的两件事这是您决定系统需求的地方

以我们上面关于通过动作而不是分数编号将分数发布到服务器的例子为例,本质上比发送分数更安全,但在发送动作时仍然不完全安全,因为玩家很容易欺骗系统发送重复的动作。

你可以开发一些逻辑来判断动作是否允许,或者开发一些更疯狂的逻辑来决定玩家的动作率是否为人类,但你永远不能让任何人向服务器报告他们的分数,这将是最安全的,也会导致一个不太有趣的游戏。

决定你可以保护和不能保护的任何东西的哪些区域,以及它对有问题的应用程序(或游戏——我使用游戏,因为parse.com的例子使用了游戏)的影响,总是一个经过计算的风险。

进一步叠加溢流相关读数

关于Javascript注入的特定漏洞,这里有一些很好的说明:Javascript安全风险?

这一条直接涉及客户端/服务器端验证:JavaScript:客户端与服务器端验证

这里有一些关于"如何"缩小和模糊代码的注意事项:如何混淆(保护)JavaScript?

关于Javascript中的模糊处理,请参阅此处,了解它有多不安全(尤其是在评论中):最难反转JavaScript模糊处理程序

如果你真的关心你的javascript,那么你可以

1) 将你的JS例程收集在一个单独的JS文件中,并使用JS压缩对其进行缩小,这将使其难以阅读和理解。

2) 使用JS加扰器对你的JS代码进行加扰/模糊处理,这将使破解者破解你的JS 变得更加困难

然而,考虑到网络上可用的大量工具,在我看来,JS随时都可能被有恶意的黑客破坏。这可以通过在服务器端强加严格的安全协议来补偿。

希望它能有所帮助!