发现微博 mobile web 版的登陆接口完全不设防

[fytriht]

地址： https://m.weibo.cn 登陆接口： https://passport.weibo.cn/sso/login

不用抓包工具，直接用 chrome dev tools 就可以找到接口，没有验证码（试了几十次没有遇到过）， Post 的账号密码数据也没有加密.... 是因为是测试版的缘故吗？

分享一下我模拟登陆的代码：

const superagent = require('superagent')

const weiboLogin = (username, password) => {
  const loginApi = 'https://passport.weibo.cn/sso/login'
  const formData = { username, password }
  const headers = {
    'Referer': 'https://passport.weibo.cn/signin/login',
    'Content-Type': 'application/x-www-form-urlencoded'
  }
  return new Promise((resolve, reject) =>
    superagent.post(loginApi)
      .set(headers)
      .send(formData)
      .end((err, res) => {
        if (err) reject('something went wrong.')
        try {
          const { rawHeaders, text } = res.res
          const cookie = rawHeaders.filter(item => item.startsWith('SUB='))
                           .map(item => item.split(';')[0])
                           .join()
          const uid = JSON.parse(text).data.uid
          if (uid === undefined) reject('wrong password or username')
          resolve({ cookie, uid })  // uid: user ID
        } catch (err) {
          reject('something went wrong.')
        }
      })
  )
}

weiboLogin('username', 'password')
  .then(res => console.log(res.cookie))
  .catch(console.error)

项目地址是 https://github.com/fytriht/weibo-cleaner

[stabc]

@laoyur 连最基本的加密知识都不懂，你还是虚心一点吧。

[laoyur]

@billlee #20 是的

[laoyur]

@stabc #21 ……

[murmur]

这得花多少时间才能给明白解释清楚，为啥 https 也能在调试器里抓到东西，甚至 flidder 你配了也能抓。。

[fytriht]

@murmur 可能是我没表达明白，我的意思是微博的登陆接口也太好找了，用 dev tools 也能很方便地抓到。有些网站的登陆接口要用抓包工具才抓到。 另外，加密的知识我确实不是很懂

[treo]

都 ssl 了还要加密什么？在客户端加密明文密码都属于自欺欺人，顶多就是糊弄一下产品经理
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

[bao3]

不能把密码加个盐吗？

[iptux]

既然是移动端就要考虑浏览器未启用 js 的可能，又有 HTTPS ，直接 POST 并没有什么问题

[Shura]

中间人攻击不是那么容易的

[acmetal]

@laoyur 其实按你说的在客户端加密了再发，就算加密十次，跟没加密有什么区别。。。密码被截获了发往同一个接口照样能登录成功

[vimffs]

@acmetal 赞！#30 这个思路解答得好。明文也好，加密文本也好，只要能截获、登录就不是问题了。但是，如果换个进程（不是你打开的那个 chrome ，或用 Wireshark ）， @laoyur 你会发现截获 HTTPS 真的不是那么轻而易举。

[exoticknight]

post 是明文，但是传输不是啊……

[imn1]

看这个帖子后怀疑人生了……
难道客户端要用 js 加密？

[dallaslu]

使用了 HTTPS ，那么被第三方攻击者嗅探到密码的风险，先不用过于费神考虑了， SSL 的中间人攻击稍后再说。值得关心的事情是「明文」提交给网站是否不妥。

1. 网站若被拖库，会暴露密码明文吗？

如果网站将密码明文入库，的确如此。

事实上，网站开发人员普遍有了不存储明文密码的意识。我们可以在安全链接的基础上明文传输密码，在服务端计算出 hash 后，与数据库中存储的 hash 值对比来验证密码是否一致。强制客户使用复杂密码，即使 hash 泄漏，也能对付得了暴力破解。

如果密码不够复杂，还是有可能被破解。预先准备一个庞大的密码字典，按指定算法获得的 hash ，做成一个映射表，使用 hash 反查即可立刻获得明文。所以有安全意识的开发人员会使用一段足够复杂的随机字符串，做为「盐」与密码明文连接后成一个新字符串，将计算出的 hash 值存储入库；同时盐也是明文存储的。 这样就能规避查表破解了。更严谨的做法是为每一个用户的密码都生成一个独一无二的「盐」。

除了用盐来得到口味不同的 hash 之外，还可以在「烹饪手法」上做文章，比如不断对 hash 加盐再算 hash 值，重复 N 次。

2. 传输加盐后的 hash ，会更安全吗？

比如我们在客户端实现 MD5 或 SHA256 这样的加密算法，如有必要还会重复 N 次；将处理后的内容发送给服务器，服务器拿去存储和验证。这样，网站可以明确的表示对客户的密码明文没有兴趣。有这种态度的网站值得赞赏，但如果仅仅如此的话，还是不够的。

如果省略了服务器方面的计算，攻击者只要从数据库中拿到客户端计算出的 sha256(password+salt) 的结果，原封不动的传给服务器，仍然可以模拟登录。所以无论客户端提交的是原始密码，还是加工后的密码，服务器都应该继续加盐「烹饪」后再使用。

3. 客户端和服务端都对密码进行加工，还有泄漏原始密码的风险吗？

还是有的。毕竟入侵网站拿到服务器数据是困难的，而广撒渔网入侵普通用户的电脑可能会容易一些。木马程序记录用户的键盘输入，原始密码仍然会被窃取。常见而有效的办法是，网站记录用户的登录地点、时间、频率等特征，一旦发现异常登录即刻限制账户的操作，可以很大程度上避免用户的损失。

这一切的源头在于用户输入了原始密码。如果网站事先与用户协商，使用随机的一次性密码，就规避了这种风险。比如短信密码， Google 二次验证，以及其他的内置密钥的临时口令生成设备。即便网站不支持这些功能，也可以使用密码管理器来为不同的网站生成不同的密码，避免战线全面沦陷。

还有一种可能，攻击者使用你的帐号和密码字典，加工后不断向服务器尝试登录，或者提交随机密码来碰运气；不过只要网站采取了限制密码尝试次数的措施，就轻松搞定了。如果攻击者在极有限的次数内猜到了原文密码，或者另外一个内容不同、但「烹饪」后的 hash 完全一致的密码，你一定要想办法联系到他，让他写一个彩票号码给你。

4. 使用随机密码就万无一失了吗？

尽管攻击者并不知道你的原始密码，但是他们有可能远程控制你的访问终端。比如使用后门程序操作你的浏览器发送一些敏感的操作请求，入侵你的手机来读取短信内容，甚至直接偷走你的动态令牌设备……

5. 我已经足够小心地管理自己的设备和密码，可以高枕无忧了吗？

少年，不得不提一下中间人攻击了。攻击者污染你的 DNS ，把你的请求劫持到了他们的服务器上，伪装成目标网站。尽管浏览器提示了网站的证书可能有问题，你点击了忽略，继续操作。你要申请短信密码了是么？攻击者会帮你向真正的网站请求短信密码，然后你把短信密码发到了假网站，攻击者就能成功登录了。所以，你需要换一个足够智能和安全的浏览器，并重视浏览器的安全提示。

6. 我终于明白浏览器证书提示的重要性了，还会有其他问题吗？

更厉害的中间人攻击，可能浏览器都发觉不了。比如攻击者设法搞到了一个有效的证书。当然，如果你访问过真的网站，浏览器会察觉到这两个网站的证书稍有不同（ HSTS ）。最倒霉的情况是第一次访问，你和浏览器一起掉进了坑里；很快这将成为一个大新闻的，网站丢了证书声明作废，或者某某证书机构闹了乌龙将证书发给了坏人。你有机会在事后意识自己受到了欺骗。你应该提前关注新闻，学习自己管理设备上的证书，随时告诉设备某某机构是否值得信任。

7. 我搞懂了证书和证书机构，可以无所畏惧了吗？

你访问了网站首页，没有发现问题；在表单上填上了随机密码，页面跳转到加密页面，证书也没有问题，只不过页面提示说密码不正确。注意！你有可能被猪队友坑了。在启用加密链接之前，你的密码在网络上裸奔了一次！你的程序员队友犯了一个错误，将表单提交到了非加密地址，尽管后来跳转到安全链接上了。要是网站使用了 HSTS ，就不会发生这样的情况了。 HSTS 需要访问一次网站才能生效，如果网站加入到了浏览器的内置 HSTS 名单中就最好不过了。

8. 我很靠谱，网站也很靠谱，我的原始密码已经像在核避难场所里一样不怕攻击了吗？

理论上接近了，除非网站使用证书私钥不够长，被越来越厉害的计算机破解，像 HTTP 一样容易监听。你终于安心了，直到有一天，你小手一滑在输入网址的时候敲错了一个字母，或者点击了一个链接，进入了一个域名相似的假网站……

9. 我已练成了金刚指和火眼金睛，试问谁敢与我争峰？

手机来了新消息，老板说把情报系统的密码发给我……你马上回复了短信密码和二次验证码，得，社会工程学，还是防不胜防！

----
以上内容随手一写，有错误请各位指正。

[davidyin]

@dallaslu 够全面

[laoyur]

@acmetal
@vimffs
你们还是没明白我关注的点
怪我一开始把原始口令传输说成了明文密码传输哦，我的错。
我从来没说不要 https ，相反， https 是必须的，用了 https 后没必要再吹毛求疵那么怕中间人，这个也是显然的。
我纠结的是，现在的大部分方案都是自恃有了 https 后，就直接原始口令传输给服务端，这真的好么？各种社工层出不穷，如能保护原始口令不沦陷，这样的工作能做为何不去做？如果在源头上就能给用户的原始口令做保护，也就是前端先把用户原始口令加盐后摘要，再传给服务端，它再爱咋处理咋处理。

@dallaslu 写得很好，赞一个

[weakiwi]

@shiji 可以看看 qq 安全的登录页面，那个是有加密的

[loading]

只要服务器处理好，就能解决你的顾虑，所以就没必要在前端做了。

那些出事的库都是要么明文，要么只是 md5 一次。
没加盐，没用慢算法等。

楼主还是多了解一下吧。

[old9]

因为前端处理是毫无意义的自欺欺人。

[340244120]

主要还是怕麻烦和节省开销吧。因为前段加密的话，点登陆的时候得先去数据库拿到盐，客户端收到后才能加密，然后开始常规登陆。