阿西河

所有教程

公众号
🌙
阿西河前端的公众号

我的收藏

    最近访问  (文章)

      教程列表

      抓包专区
      测试专区

      区块链网页钱包为什么不安全

      研究场景

      因项目需要,研究在线网页钱包不安全的因素,然后根据这些因素,找到合适的方案;

      经常说网页钱包不安全,但是为什么不安全,具体有哪些不安全的地方?如果用别的途径实现,又为什么是安全;他们解决了哪些问题,用什么方式解决的?是不是保证绝对没问题。

      这些方面的东西,我属于懵懵懂懂的,需要仔细研究研究;

      敏感的信息

      网页钱包中,密码是非常敏感信息,绝对不能被拿到,

      公钥(比如keystore文件)也属于敏感信息,和密码一起被拿到的话,账户就属于被盗了;

      网页中的安全挑战是:保证用户输入的密码不被拿到;

      研究思路

      这个属于WEB安全方面的研究,WEB安全涉及到方方面面的很多因素,盲目查找没有啥头绪;

      因为在线网页钱包,基本是通过域名访问的,

      所以我打算 分解 用户输入域名开始到网页加载完成 的这段过程

      逐步研究分解后的每一步,来查找可能存在的安全问题,这是我能想到的最稳妥的研究方案了;

      解剖网页钱包的访问原理

      访问过程具体如下,假设用户访问的是 axihe.com 或者 https://www.axihe.com/

      URL 解析

      这一步的风险在于:浏览器作恶

      地址解析与补全

      • 首先判断你输入的是一个合法的 URL,还是一个待搜索的关键词
        • 搜索关键词的情况这里不考虑,与主题无关
      • 根据输入的内容进行自动补全协议、字符编码等等操作。
        • axihe.com 补全为 http://axihe.com/

      分析协议

      • 常见的网络传输协议:http、https、ftp 、file、 mailto 、git 等。
        • 还有自定义的协议(私有协议),例如tencent。不同协议有不同的通讯内容格式。

      浏览器的额外骚操作

      检查缓存

      这一步的风险:Host 被修改,容易被本地代理篡改;

      如果本地有类似代理服务一样的进程,客户端发送的请求,是先经过代理服务的,代理服务可以直接把某个域名指向用于作恶的IP;

      导致的结果是绕过DNS查询,直接获取作恶IP上的资源

      浏览器缓存

      • 浏览器会先检查DNS信息是否在缓存中,没有则调用系统库函数进行查询。

      操作系统的hosts文件中查找

      • 操作系统也有自己的 DNS缓存,但在这之前,会向检查域名是否存在本地的 Hosts 文件里。
      • 有对应的域名IP地址的话直接返回
      • 没有的话,进入下一步

      ISP DNS 缓存

      • ISP DNS 就是在客户端电脑上设置的首选 DNS 服务器,它们在大多数情况下都会有缓存。

      如果本地缓存生效

      • 会继续使用本地,直接进入加载成功阶段,不再继续往下进行了
      • 没有生效的缓存,进入下一步

      DNS 查询

      这个阶段存在 DNS 劫持的可能

      该阶段属于 递归查询 + 迭代查询 的方式,中间不返回结果,一直到最终返回才算拿到DNS信息;

      路由器缓存

      • 网络经路由器对外,路由器也有自己的缓存。

      根域名服务器查询

      在前面所有步骤没有缓存的情况下,本地 DNS 服务器会将请求转发到互联网上的根域:

      根 DNS服务器

      http://axihe.com/.com域名,根DNS服务器会将其转到.com的DNS服务器

      .com的DNS服务器

      转到用户在域名服务商后台设置的域名的DNS,这里可以拿到最终的IP

      把 最终ip地址 返回给浏览器

      扩展:dns-prefetch

      TCP 连接

      注意:这一步发出去的信息,容易被抓包工具篡改,

      如本地有类似 Fildder 、 charles 、 wireshark 的抓包工具,经过网络协议发出去的数据,可能是经过修改后的数据;

      同理:接收到的服务器返回数据,也可能是经过修改后的数据,如果有这类软件,不能保证数据的真实性

      TCP/IP 分为四层,在发送数据时,每层都要对数据进行封装:

      1. 应用层:发送 HTTP 请求
      2. 传输层:TCP 传输报文
      3. 网络层:IP协议查询Mac地址
      4. 链路层:以太网协议
        • 以太网协议
        • Mac 地址
        • 广播

      服务器接受请求是把上面步骤逆转

      服务器处理请求

      这一步的风险是:服务器可能会被黑掉;

      • HTTPD
      • 处理请求
      • 重定向
      • URL 重写

      浏览器接受响应

      注意:这一步容易被抓包工具篡改信息

      如果本地有类似抓包工具的服务,客户端接收到的信息,先经过抓包工具,然后再转给浏览器;

      浏览器接收到来自服务器的响应资源后,会对资源进行分析。

      首先查看 Response header,根据不同状态码做不同的事(比如上面提到的重定向)。

      如果响应资源进行了压缩(比如 gzip),还需要进行解压。然后,对响应资源做缓存。

      接下来,根据响应资源里的 MIME 类型去解析响应内容(比如 HTML、Image各有不同的解析方式)。

      渲染页面

      注意:这一步容易被注入脚本,比如Chrome扩展,油猴脚本这些的

      1. HTML 解析
      2. CSS 解析
      3. 渲染树
      4. 布局与绘制
      5. 合并渲染层
      6. 回流与重绘
      7. JavaScript 编译执行

      不安全因素的总结

      • 浏览器/应用作恶
      • 域名DNS被劫持
      • 网页资源被修改
      • 网页被注入脚本
      • 网页被APP截图

      浏览器应用的底层作恶

      今年闹的比较凶的996 ICU

      国产浏览器对 996.icu 项目进行限制,就属于浏览器作恶:多家国产浏览器限制访问996.ICU的GitHub项目

      浏览器/应用在使用过程作恶

      网页是需要浏览器来访问的,浏览器访问的时候,是可以截取信息的(虽然可能性比较低),

      应用层作恶的案例有

      UC浏览器对获取隐私的说明

      1、在您使用浏览器时候会弹出是否同意浏览器的隐私协议,同意了才能使用UC,不同意无法使用,浏览器读取到手机中的有关内容,是经过您点击同意的,您在使用过程中也可以选择在系统中关闭相关权限的读取;
      2、相关权限开通主要目的是为了给您提供更创新的服务和个性化产品,比如调用摄像头权限是支持供二维码扫描功能,调用录音权限是为了给您提供语音搜索等服务;
      3、UC浏览器对于使用权限的优化仍在持续进行,也提醒广大用户及时升级UC浏览器的最新版本;
      UC一直致力于给用户提供良好的内容服务及互动体验, 我们会进一步加强排查敏感权限风险、完善产品流程, 在权限选择界面更加明示获取权限的目的,对用户个人信息提供较全面的隐私保护和安全保障。
      
      PS:获取权限只是为了确保浏览器使用运行正常,并不会泄露您的个人信息,请您放心使用!
      

      浏览器或者应用是可以做到获取用户的输入密码等信息,具体隐私是否保护好,有没有被泄露的风险,看不同厂商,但它们是有这个权限的;

      注:Chrome是提示是否记住密码,国产浏览器很多是”为了用户体验”,说是为用户好,直接默认记录;

      域名DNS被劫持

      网站被访问,肯定需要提供一个IP或者域名,方便用户使用;一般都是使用域名进行访问;

      域名访问的过程是:用户浏览器输入域名后,进行DNS解析,然后匹配到对应的IP/服务器上;

      这时候,作恶者可以将网站托管的服务器重定向到恶意的钓鱼站点;

      作恶者拦截对 xxx.com 的DNS请求,使自己的服务器看起来是该地址的合法所有者。

      在作恶服务器上,重定向到他们自己的克隆站点(xxxx.com的克隆站点),然后抓取用户信息,或者问用户要敏感信息;

      因为用户认为他们在真正的网站上,没有什么戒备心,容易被坑。

      具体案例:MyEtherWallet 的 Google DNS 被劫持,损失超过 30 万美元的数字资产

      这次事件以后,导致大家对在线网页钱包的态度是永远不应该被信任。

      事件还原

      事件发生在2018年4月24日。

      黑客针对四段分配给AWS,本应作为AWS route53 DNS服务器服务地址的IP空间

      (205.251.192.0/23, 205.251.194.0/23, 205.251.196.0/23, 205.251.198.0/23)

      发布了虚假的BGP路由,导致在BGP泄漏的两个小时期间,本应该AWS route53 DNS服务器的DNS查询都被重定向到了黑客的恶意DNS服务器。

      且黑客DNS劫持的目标十分明确,恶意DNS服务器只响应对myetherwallet.com的查询,其他域名的查询均返回SERVFAIL。

      一旦用户没有注意“网站不安全”的提示而访问myetherwallet.com登录自己的以太坊钱包,黑客就可以轻易获取用户的私钥进而窃取用户的数字货币资产。

      正常情况的DNS,和劫持后的DNS的情况,攻击示意图参考:

      https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/?spm=a2c4e.10696291.0.0.489519a4oLw96R

      关于 BGP劫持详解

      DNS劫持类型

      总结几种DNS劫持方法

      1.本机DNS劫持

      攻击者通过某些手段使用户的计算机感染上木马病毒,或者恶意软件之后,恶意修改本地DNS配置,比如修改本地hosts文件,缓存等

      2. 路由DNS劫持

      很多用户默认路由器的默认密码,攻击者可以侵入到路由管理员账号中,修改路由器的默认配置

      3.攻击DNS服务器

      直接攻击DNS服务器,例如对DNS服务器进行DDOS攻击,可以是DNS服务器宕机,出现异常请求;

      还可以利用某些手段感染dns服务器的缓存,使给用户返回来的是恶意的ip地址;

      网页资源被修改

      导致这种结果的情况有:

      Host 被修改、DNS被劫持、抓包/代理类软件的修改

      网页的引用资源,被修改,本应该从 a.xxx.com/a.js 拿的资源,可以被改成从 b.ssss.com/modi.js 拿资源,或者改为请求本地资源;

      甚至网页HTML本身也有被修改的可能;

      即使有 CSPSRI的方案:subresource-integrity / SRI保护静态资源不被恶意修改,但是在源头HTML就被劫持的情况下,还是无计可施;

      即使使用HTTPS也不是绝对的保证安全,参考:为什么说HTTPS加密链接不是绝对安全的?

      网页被注入脚本

      比如常用的 Chrome扩展 对网页注入脚本

      在平时项目开发的过程中,有时候想要从外部注入脚本,实现自动填写表单、自动点击的效果;有时候也在普通页面中注入一些代码,达到一些“特殊目的”。

      chrome 扩展插件是运行在 chrome 浏览器中,用于扩展 chrome 功能的工具,主要功能是对浏览器或者页面进行一些操作、注入。

      Chrome插件中向页面注入脚本的一种形式(虽然名为script,其实还可以包括css的),借助content-scripts我们可以实现通过配置的方式轻松向指定页面注入JS和CSS(也可以动态注入),最常见的比如:广告屏蔽、页面CSS定制,等等。

      如果有Chrome恶意扩展,是可以拿到网页的敏感信息的,参考:在Chrome插件中访问原始网页中的变量

      网页钱包虽然不经过网络传输密码等信息,但是需要用户输入密码信息;注入的脚本不需要关心密码怎么传输怎么生成密钥的;只要关注密码来源以及生成的公钥文件;

      比如:用户输入的密码,原始JS必定是需要能获取到的,只要原始JS能获取到的信息,注入的脚本也是有办法拿到的;

      虽然有HTML防JS注入的办法,防止JS更改HTML里面的内容;

      参考 html防止JS注入,但是JS获取HTML的内容,是防不了的;

      卖前端学习教程

      只需几十元,就能买到培训班的内部教程!开启高薪之路!

      零基础小白阿里P7的教程都有!

      同时长期收购所有培训班的前端教程

      目录
      目录