9月杂记 | k-on

9 月份的技术成长记录

H5 与 app 交互

首先，移动端网页运行在手机应用内嵌的浏览器引擎中，这个没有 UI 的内核容器统称 WebView

H5 与原生应用的交互都是通过原生应用中的 WebView 实现的。通过这个环境，H5 可以调用原生应用注入其中的原生对象的方法，原生应用也可以调用 H5 暴露在这个环境中的 JavaScript 对象的方法，从而实现指令与数据的传输。

这里有 2 个名词

顾名思义，js 调用 app 方法，或者 app 调用 js 方法

双向调用是，比如 js 先调用 app，app 在调用 js,反过来一样。

前端 rsa 加密可以防止抓包，但没法防止中间人攻击

登录的安全主要就是中间人攻击，而中间人攻击的实现方法包括就是重放攻击。也就是把截获的数据重发一遍或者重新组装后发送，所以防范的办法就是让重放失效。
根据以上分析，唯一的办法就是引入一次性密钥，并且不直接传递任何形式的密码。只要做到这两点，中间人就无处下手进行攻击了。

你用什么保持登录状态？ cookie 什么的直接抓包一清二楚，根本不需要研究你是怎么处理登陆的，直接把 cookie 全部拷贝就有了同样的身份

SSL/TLS 的存在就是用来解决问题的，严格来说你离开了它们就无法保证安全

注册和登录可以通过手机短信动态一次性密码，但是登录成功后就无法抵御中间人了。但是，6 位数验证码，穷举也是分分钟的事情

如果前端有对称加密的秘钥，那我会如何伪造别人的身份呢？

首先，我会自己注册一个账号，然后从某些地方，找到 userId 之类的东西，比如 cookie, 接口返回的参数，代码的断点调试。

找到自己的 userId 之后，开始暴力枚举，用秘钥加密后进行爆破。

只要中间人往返回内容插 JS，记录用户操作，用户的账号密码就泄露了。

有人发现自己的网站用某些网访问的时候，登录会同时以明文 query 带账号密码请求一张图片，但远端没有收到这个请求 —— 很显然是 ISP 方面干的。
如果只是靠加密一层防监听数据，防的叫旁听人攻击，而不是中间人攻击。

握手时要求双端生成随机数，重放攻击会使得服务端随机数对不上，重放攻击失败。

输入框 change 的时候去后端查询数据，输入 123，如何保障，最后显示的一定是 123 对应的数据呢？

即使 debounce 也不能完全避免这种情况的发生，比如弱网环境下，缓慢的输入 1 、23。那么 1 有可能在 123 后面返回。

应对措施：每次发请求的时候，闭包标识一个 key，当 key 有更新的时候，即 key 和最新的 key 不匹配的话，就当做是废弃的数据

比如全局有个对象

let map = {
  请求A: 次数（number）,
  请求B: 次数（number）
}

每次发送请求 A 之前，map.请求 A + 1，然后闭包存下当前请求对应的数值，返回数据的时候，如果数值跟 map.请求 A 不同，就当做废弃的数据