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

地址： 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

340244120

2017-02-19 09:27:57 +08:00

最大的可能还是早期的设计没考虑过前端加密。后面再补的话，老用户就登不上了。 [当然原理上是可以实现的，但太麻烦了，登陆的时候判断下是不是老用户，是的话前端就不加密，转到后台，用前端算法加密一次，再用后端算法加密一次，移除老用户标记。

quxiangxuanqxx

2017-02-19 12:03:27 +08:00

@340244120

@laoyur

这样做没有任何意义，你看的明文和原始口令是在你自己的电脑上，应用层在你自己的电脑上，但是数据在网络传输中，已经 SSL 加密了，黑客截获是拿不到原始口令的

如果黑客已经黑掉了你的电脑，为什么还要去抓包，直接键盘钩子勾出来不就行了

如果说黑客只是拿到了部分权限，只能抓包？能抓包已经可以下钩子了

综上所诉，没有意义，徒增笑而

mornlight

2017-02-19 15:54:55 +08:00

前端对密码做处理可以增加中间人攻击时获取明文密码的难度，只能说意义不大，也不是完全没有意义。淘宝的登录 POST 请求就是没有明文密码的。
不管谁知道的多谁知道的少，技术问题可以大家一起讨论，讨论的过程会沉淀下来给后面的人看。遇到自己不屑的观点就用「多读书」这样的话来嘲讽，是智力上的自我矮化。

laoyur

2017-02-19 17:53:55 +08:00

@mornlight #53 是诶，虽然我说“明文密码”用语不精准，但从我再增加的回复中也不难理解我在说的到底是啥。
退一万步说即使我话题跑偏，但我说的问题真的一点讨论意义都没有吗？不见得吧。
我承认自己不是牛人，但好歹我认认真真在讨论问题，人啥都不说直接来一句“年轻人多读书”、“最基础的加密都不懂，要谦虚”……我一个话题跑偏不要紧，但所谓的国内第一的个人技术社区的价值也要往这个方面跑偏吗？

imn1

2017-02-19 18:18:05 +08:00

@laoyur
如果你把“明文”“加密”这些说法，换成“唯一化处理”（注意不仅是 hash ），就是把即将发送出去的密码串转换成跟其他网站不相容的另一个串，或者我能理解，两个意义——
1.唯一化处理后让客户端盗得的不再是原始密码，不能用于其他站点
2.即使原始密码和其他站点相同，通过唯一化处理，变成不能用其他站点密码（也就是原始密码）碰撞本站密码

gy911201

2017-02-19 18:24:57 +08:00

@laoyur 我明白你的意思，我是这样想的，如果是客户端被黑客入侵，那么可以直接用键盘钩子拿到原始密码，前端加密没有起到作用，如果是服务端被黑客入侵，那么如果程序没有安全问题（明文入库，日志包含敏感信息）的话，那么黑客要拿到 https 里的明文密码也需要很高的权限，有此权限的时候一般都可以直接对网站进行挂码，那么这个前端加密依然不起作用……
当然了，我的论据的前提是黑客要拿到 https 里的明文密码需要的权限至少与可以对网站挂马需要的权限一致，不知道这个前提有没有问题……

laoyur

2017-02-19 18:25:55 +08:00

@imn1 #56 我在楼上的回复中承认过了，我“明文密码”的说法是不精准，我之所以说明文，是自己默认了在 https 语境下的明文（原文），给他人理解带来了偏差，抱歉。但“加密”的锅我不背，我所提到的加密字眼，只是引述楼主以及楼上各位的话题，我始终要表达的是对原始密码的摘要，或者你所说的“唯一化处理”，而不是可逆的“加密”。

4641585

2017-02-19 19:56:34 +08:00

我来总结一下

1 、可以用 chrome dev 因为是同一个进程，与启用了 HTTPS 无关。

2 、有一种观点是如果已经启用了 HTTPS ，前端处理相对没有意义。对于 HTTP 来说，前端处理是有意义的，可参阅 https://github.com/EtherDream/WebScrypt 。对于使用了可靠证书的，启用 HTTPS 的网站来说，前端处理是否有意义，这个问题约等于 HTTPS 是否足够完美。认为其完美的人以数学、密码学为主要论据，认为其可能不够完美的人会以历史上曾被猿们认为可靠的而后来被证明不够可靠的事例为论据。讨论这个问题，这不是第一个帖子也不会是最后一个。

3 、无论怎样，数据库直接存放明文密码是不可取的。

340244120

2017-02-19 23:29:25 +08:00

@gy911201 安全性要求很高的，前端处理还是有必要，键盘钩子的问题可以用虚拟键盘等方式来应对。然后假设客户端及传输过程中安全性为 100,但不排除后端程序员中有内鬼的可能，把接收到的口令单独储存下来，或者用户担心自己的密码隐私，不愿意让自己的密码被后端直接获取。这时候前端处理的必要性就体现出来了。总之，前端处理可以说没有必要，但不能说毫无意义。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/341416