在之前的一个问题中，我问到了我自己的安全层概念中的弱点......它依赖于JavaScript加密函数，并且感谢现在的答案，引人注目的一点是，明确表示所有在JavaScript中完成的操作都可以被操纵，并且不能被信任...有什么方法可以验证客户端代码是否是服务器提供的代码？
现在的问题是 - 我仍然需要使用这些，即使我依靠SSL传输......
所以我要问 - 有没有办法使服务器可以检查该网站是使用来自服务器的“正确”的JavaScript？
我想到的任何东西（如散列等）都可能是明显伪造的......并且服务器似乎没有任何可能知道客户端发送了一些数据后发生了什么，通过HTTP标头（ - > cookie交换和东西）
服务器完全不可能验证这一点。
Javascript和服务器之间的所有交互都直接来自Javascript。
因此，恶意的Javascript可以做任何你的良性Javascript可以做的事情。
通过使用SSL，您可以使恶意JavaScript首先进入您的页面变得困难或不可能（只要您信任浏览器及其插件），但是一旦它在您的页面中立足，您'被洗了。
基本上，如果攻击者对浏览器有物理（或文字）访问权限，那么您不能再信任任何东西。
这个问题并没有真正与JavaScript有关。任何服务器应用程序（web或其他）都无法确保客户端计算机上的处理由已知/可信的代码执行。在Web应用程序中使用JavaScript会使篡改相对简单，但如果您分发编译后的代码，则会遇到完全相同的问题。
服务器从客户端接收的所有内容都是数据，并且无法确保它是您希望发送该数据的客户端代码。您可能用于识别预期客户端的任何数据部分都可以由替代客户端轻松创建。
如果您担心的是通过中间人攻击代替客户端代码，那么通过https加载javascript几乎是您最好的选择。但是，没有什么能够保护您免受客户端机器本身上的客户端代码的直接替换。
呃......游戏行业确实依赖于作弊者，并且至少有一点成功，但当然这些东西是非常侵入性的（操作系统驱动程序，类似rootkit等）......令人失望的是，并不是一个简单的方法，也没有任何网络开发的方法...... – apirogov 2010-09-01 15:02:52
这实际上都不允许服务器确保预期的客户端代码正在运行。由于有更多的验证点需要模拟，因此它很难替代备用客户端。 – 2010-09-01 15:16:29
永远不要假设客户端正在使用您编写的客户端软件。这是一个不可能的问题，你设计的任何解决方案只会减缓并且不会阻止攻击。
您可能能够对用户进行身份验证，但您将永远无法可靠地验证他们正在使用的软件。对此的必然结果是永远不会信任客户提供的数据。一些攻击，例如跨站点请求伪造（CSRF），要求我们甚至不相信认证用户甚至意图提供数据。
+1重要点 – SLaks 2010-09-01 14:49:23
绝不隐式信任来自客户端的任何内容。始终在服务器上进行验证。 – David 2010-09-01 14:53:58