帐前卒专栏

Without software, we are nothing.

微信公众平台开发中的安全问题

0. 我在开发中

    近期一直在利用有道云笔记API在微信上开发一款应用。因为是服务器端与服务器端的交互。所以有很多安全问题值得考虑。

1. 微信的认证

    微信的认证很简单,标准的认证是这样子的:
token 授权
    微信这种授权模式相当的山寨,如果只是单纯的靠这种token授权,服务器很容易被攻破。这里需要填写的url必须是使用80端口,而且url中也不能有很特殊的字符。不过token中可以有特殊字符。所以开发者需要尽量将自己的token设的复杂。微信首先认证连接时会将signature,echostr,nonce,timestamp这四个URL参数以GET请求的方式发送过来。数据则以POST请求的方式发送到同样的URL上,并且URL参数变为signature,echostr,nonce。nonce是和请求中的timestamp成对的。也就是说timestamp+nonce是唯一的。所以这里可以防止重放攻击。另外server与server通信之间,timestamp的单位是秒,一般误差也就是分钟级别的。这样可以从另外一个角度防止重放攻击。所以开发者应该在GET,POST请求中都加入这些参数的校验。

2. Token安全

    上面的认证建立在Token的安全基础上。另外因为微信公众平台中URL不能有特殊字符,所以这个URL很容易被破掉。而Token这个也可有通过暴力尝试来破解。大概也没有帐号设很长的密码。所以你要做的就是将Token设的超长,另外加入些特殊字符。

3. TO 收信者ID

    微信发来的是一个发信者的ID和一个收信者的ID。收信者ID一直是不变的。如果Token被破解了,那么下面一个安全的措施是收信者的ID,因为收信者ID这个对于伪造者来说,这个是不可见的。但是对于能截获微信服务器和应用服务器之间的中间者来说。这个就是可以轻易获取的。

4. From 发信者ID

    下面就不算是微信的安全了。应该是我做的应用本身的安全问题。首先我需要使用有道云笔记的授权。需要发给用户一个链接。用户点击该链接完成授权。第一版应用中,该链接值是不变化的,或者说某一部分例如from参数是不变化。这就意味着,如果用户不小心将该链接暴露出去。那么其他用户完全可以将此用户发来的消息存入到自己的笔记中。这个是个很严重的安全问题。而且对外也不应该在链接中暴露from 发信者ID。所以需要使用其他的参数来隐藏from ID,另外授权链接只能成功授权使用一次。

5. 内容的XSS风险

    这个问题,其实只要是存储内容,就一定隐含着XSS问题。所以这个微信内容需要经过XSS过滤。

6. 跳转链接隐含的XSS风险

    授权的过程中有大量的跳转操作,特别是callback参数,需要对该参数做特殊的\r\n过滤。另外如果该参数会写入到页面中,那么也应该对整个页面的内容做XSS过滤。特别要防止拼接而形成的XSS问题。

7. 隐式登录问题

    之前的有道云笔记Oauth1.0版本,一直有隐式登录授权问题。就是一旦成功授权后,就难以改用第二个帐号了。现在这这一版顺便解决了这个问题。

8. 微信 Android bug

    顺便说说Android的微信的bug。有一个很奇葩的bug是这样的。如果服务器返回<a href="chillyc.info">帐前卒</a>。如果你在微信界面中点击了“帐前卒”,那么就理所当然的跳转到了chillyc.info.然后如果服务器下次返回<a href="blog.csdn.net/cctt_1">帐前卒</a>。那么点击该链接,仍然会打开chillyc.info! F**K.

总结

    开发完在微信平台的这个功能。让我感觉到微信私有接口太多,太过诡异的技巧。视频、音频这些都是通过大客户合作的方式获取的。另外有时候微信自身的bug占用了自己太多的时间。还有一个感觉,就是有道云笔记授权,特别是1.0,真的不是很好用,存在很多未解决的问题。不过2.0也上线了。大家会更加轻松的使用。嗯嗯……自己这边开发的还能改,别人开发的…都不知道该去哪里问……另外微信部门明显不是合作态度。可能和它们合作的公司太多的缘故。好了,最后一点:安全基本是靠自己…公众平台的用户名密码也不要设置的太简单…

Comments