网站js文件被加密了?
反对认为 JS 加密没有意义的答案。似乎在这些答案里面,安全程度只有「安全」和「不安全」两种等级,是么。先简单说下常用的 JS 加密(RSA)步骤:
服务端生成公钥私钥,下发公钥给客户端客户端使用公钥(还有盐)对密码加密把加密后的密码发送到服务端,服务端使用私钥解密拿到密码对于攻击者来说,只要能够拿到 HTTP 明文,就可以在公钥下发时进行公钥或者加密方式的替换,拿到密码后解密,再使用服务器公钥加密密码明文,返回给服务端。简单几步就可以拿到密码明文了。从根本上说,就是说只要中间人能够拿到 HTTP 明文,任何加密都是能够破解的。然而客户端 JS 加密的意义在于它提高了拿到密码的成本。对于黑客来说,只要能监听到网络的 HTTP,把所有的 HTTP 请求直接保存到数据库,然后定期进行数据清洗,就能直接拿到一大批没有加密的密码,用这种方式采集密码,简直就是用大网捞鱼。如果客户端采取了加密,「大网捞鱼」的办法就不奏效了。如果黑客需要拿到某个网站的用户密码,需要先分析加密方式,再针对性地代理和篡改 HTTP 内容,才能拿到密码。加密之后,安全性提升了一个层次,可以把很多只会用工具的「黑客」拦在门外,当然是有意义的。至于安全控件,因为它的加密算法是写在 native 里面的,而且公钥也可以直接内置到客户端,中间人无法篡改公钥,也就没办法拿到密码明文。而且它除了加密,还起到了一些其他的作用。自然有理由认为它比 js 加密更安全。类似地,还有些网站全站 HTTP,只有登录部分用了 HTTPS,黑客完全可以在跳转登录页前进行劫持,把登录页的 HTTPS 入口链接替换成 HTTP 并进行 HTTP 劫持。所以说这种安全防范就是掩耳盗铃?在无法全站覆盖 HTTPS 的情况下,登录页能用 HTTPS 自然比不用好。再举个相关的例子:HTTP 的网页经常会被运营商篡改,插入一些广告脚本。在没有能力进行 HTTPS 改造的情况下,有些网站会通过在响应头中添加 CSP (Content-Security-Policy)来防范。从理论上说,这种防范方式是没有作用的,因为运营商可以直接篡改你的 JS,更暴力的方式是删掉 CSP 头。但实际上,就目前来看 CSP 对于防运营商劫持还是有一定效果的。终极方案还是全站 HTTPS,然而它也不是绝对的安全,如果下面任一环节出问题的话:服务器安全没做好加密算法和实现有漏洞,如 Heartbleed客户端不安全,被安装了木马或者恶意插件CA 不干净,或被安装了私有 CA网页存在 XSS 等问题Copyright © 广州京杭网络科技有限公司 2005-2024 版权所有 粤ICP备16019765号
广州京杭网络科技有限公司 版权所有