区块链网页钱包为什么不安全
研究场景
因项目需要，研究在线网页钱包不安全的因素，然后根据这些因素，找到合适的方案；
经常说网页钱包不安全，但是为什么不安全，具体有哪些不安全的地方？如果用别的途径实现，又为什么是安全；他们解决了哪些问题，用什么方式解决的？是不是保证绝对没问题。
这些方面的东西，我属于懵懵懂懂的，需要仔细研究研究；
敏感的信息
网页钱包中，密码是非常敏感信息，绝对不能被拿到，
公钥(比如keystore文件)也属于敏感信息，和密码一起被拿到的话，账户就属于被盗了；
网页中的安全挑战是：保证用户输入的密码不被拿到；
研究思路
这个属于WEB安全方面的研究，WEB安全涉及到方方面面的很多因素，盲目查找没有啥头绪；
因为在线网页钱包，基本是通过域名访问的，
所以我打算 分解 用户输入域名开始到网页加载完成 的这段过程
逐步研究分解后的每一步，来查找可能存在的安全问题，这是我能想到的最稳妥的研究方案了；
解剖网页钱包的访问原理
访问过程具体如下，假设用户访问的是 axihe.com 或者 https://www.axihe.com/：
URL 解析
这一步的风险在于：浏览器作恶
地址解析与补全
- 首先判断你输入的是一个合法的 URL，还是一个待搜索的关键词
- 搜索关键词的情况这里不考虑，与主题无关
- 根据输入的内容进行自动补全协议、字符编码等等操作。
axihe.com补全为http://axihe.com/
分析协议
- 常见的网络传输协议:http、https、ftp 、file、 mailto 、git 等。
- 还有自定义的协议（私有协议），例如tencent。不同协议有不同的通讯内容格式。
浏览器的额外骚操作
- 浏览器还会进行一些额外的操作，比如安全检查、访问限制
- 今年闹的比较凶的996-ICU，国产浏览器对 996.icu 进行限制就是在这一层直接做掉的
- 多家国产浏览器限制访问996.ICU的GitHub项目
检查缓存
这一步的风险：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 分为四层，在发送数据时，每层都要对数据进行封装：
- 应用层：发送 HTTP 请求
- 传输层：TCP 传输报文
- 网络层：IP协议查询Mac地址
- 链路层：以太网协议
- 以太网协议
- Mac 地址
- 广播
服务器接受请求是把上面步骤逆转
服务器处理请求
这一步的风险是：服务器可能会被黑掉；
- HTTPD
- 处理请求
- 重定向
- URL 重写
浏览器接受响应
注意：这一步容易被抓包工具篡改信息
如果本地有类似抓包工具的服务，客户端接收到的信息，先经过抓包工具，然后再转给浏览器；
浏览器接收到来自服务器的响应资源后，会对资源进行分析。
首先查看 Response header，根据不同状态码做不同的事（比如上面提到的重定向）。
如果响应资源进行了压缩（比如 gzip），还需要进行解压。然后，对响应资源做缓存。
接下来，根据响应资源里的 MIME 类型去解析响应内容（比如 HTML、Image各有不同的解析方式）。
渲染页面
注意：这一步容易被注入脚本，比如Chrome扩展，油猴脚本这些的
- HTML 解析
- CSS 解析
- 渲染树
- 布局与绘制
- 合并渲染层
- 回流与重绘
- 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本身也有被修改的可能；
即使有 CSP及SRI的方案：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的内容，是防不了的；
