有没有办法验证客户端的javascript文件的完整性?

时间:2009-12-22 11:14:21

标签: php javascript security ssl

我正致力于使用php和javascript而不是ssl / tls进行用户注册和身份验证的安全方法。

我意识到这可能被认为是一项不可能完成的任务,之前曾尝试过1000次,但无论如何我都会试一试。我在网上看到的所有声称做这件事的例子似乎都有一些巨大的致命缺陷!

无论如何,我目前的问题是在客户端验证javascript。问题在于,如果我在javascript中的sha1实现被一些中间人修改了,那根本就不安全。如果我可以验证收到的javascript没有被篡改,那么我想我可以解决这个问题。

真正的问题是,在客户端做事的唯一方法是javascript。简单:编写一个javascript来验证其他javascript文件的完整性。不!中间人也可以修改这个文件。

有解决方法吗?

8 个答案:

答案 0 :(得分:2)

要保护您的JavaScript,您必须在有保障的无保护环境中对其进行检查。由于您无法在浏览器中创建此类环境,因此无法实现。您最好的选择是通过HTTPS下载JavaScript。这不安全但更好。可能存在的攻击媒介:

  • 病毒可以修改浏览器以为每个页面加载一些恶意JavaScript
  • 键盘记录程序可以监控用户正在键入的内容
  • 代理可以充当HTTPS连接的中间人。代理实际上会解码您通过HTTPS发送的内容,并再次对其进行编码(使用不同的证书)。
  • 代理可以向您发送的网页添加iframe

答案 1 :(得分:2)

马特 我相信(尽管是反对者)你所要求的并非不可能,只是非常困难。您要问的是,滥用完全可访问的代码允许用户向服务器标识自己,反之亦然。一种可能的方法是使用零知识证明,它不会向窃听者(Eve)泄露任何信息。例如,服务器可能提供javascript,该javascript绘制图形的表示,该图形将用户提供的无值信息与Eve本身组合,服务器提供的信息也没有任何价值。 javascript可能已被修改,但要么无法提供正确的图形(此时用户WALKS AWAY)或成功。在后一种情况下,用户同样提供“零知识”证据,证明他们具有图的同态表示;再次,这要么成功要么失败。另外看一下SRP协议,但问题在于它是一个专利雷区。参见Ferguson和Schneier的Practical Cryptography。乔

答案 2 :(得分:1)

没有办法绕过它。正如您所说:如果您无法验证源,则中间人攻击者可以替换客户端收到的任何内容,即客户端解释和执行的任何内容。

答案 3 :(得分:1)

你说你唯一的问题是中间人修改你用来执行SHA1的javascript。因此,我猜您使用密码的用户名+ SHA1进行登录....

即使没有Javascript篡改,这也是完全不安全的。即使javascript没有被修改,中间的人可能也不知道普通密码,他就会知道哈希,并且他可以完全使用该哈希来自己重新登录。

即使您包含salt / nonce,中间人仍然可以使用这些令牌,甚至可以通过执行密码/电子邮件更改来窃取帐户。

即使忽略了这一点,并假设你可以实际解决所有这些+实际上获得一个javascript来测试第二个javascript的完整性,你会如何防止“验证脚本”被篡改?你依赖于通过不安全通道发送的脚本来确保这些数据的安全性(并且可以递归地继续使用一个脚本来检查检查脚本完整性的脚本的完整性......)所有这些都被完全篡改因为它们是通过不安全的渠道发送的。

这样做的唯一方法是能够在http之上构建自己的安全通道,这需要一些客户端附加功能(Firefox插件/ ActiveX扩展),但是对https的原生支持是只是荒谬。

答案 4 :(得分:0)

因为他们在客户端,你无法访问它们。

这是网页的性质......

尝试在服务器端使用重要的东西...

答案 5 :(得分:0)

如果您的安全架构以某种方式需要在Javascript中运行函数,那么您的安全性就存在缺陷。

答案 6 :(得分:0)

使用JavaScript可以保护您免受被动网络攻击(例如窃听WiFi流量),但是您无法保护自己免受入侵者能够控制HTTP响应标头和正文数据的主动网络攻击。

如果您不想支付SSL证书,可以改为创建自签名证书。但是,这只会阻止被动网络攻击,但比你创建的一些hacky JavaScript实现容易得多。

基本上,您需要CA签名的SSL证书来防止主动网络攻击(中间人)。

答案 7 :(得分:0)

只有当服务器和客户端以前共享密钥时,才能验证客户端上Javascript文件的完整性。互联网上通常不是这种情况。如果没有这样的秘密,那么任何验证传输的Javascript的尝试都可能被破坏。这是一个陷阱22的情况。

大多数情况下,人们希望确保JS的完整性,因为这会让他们觉得可以在客户端委派安全检查。在密码学中,有一个不应该被破坏的基本规则:永远不要信任远程用户输入。总是仔细检查。

SSL / TLS可以让中间人攻击更难实现,但它不是水密的。