云服务商的技术问题和商业道德问题

就个人来说，这种问题可能没啥影响，因为你可能不住这几家酒店，而且在兲朝，你懂的，真要查这些信息，一般都会通过某些官方渠道，根本不需要这种手段。

但是……且不说其它酒店也可能有类似问题，更可怕的是除了酒店以外，其它地方也有可能有类似的问题——只要它们用了某些无良国内厂商的服务……

这才是本文要讨论的问题所在。

技术上的问题

乌云的原文里已经基本解析了这个漏洞的技术问题。整个系统的工作原理大致是这样：

酒店把入住人的信息上传到第三方认证服务器，然后住客要上网时就会被重定向到认证服务器，输入认证信息后通过认证，然后才可以上网。

所以并不是只有在酒店上网才会泄露，而是从入住开始，这些信息就已经被传到认证服务器了。

从表面上看这个系统结构没有什么大问题，是一种典型的云端认证系统——各酒店不需要自己建设认证系统，只需要统一把数据给云端，所有用户认证过程也在云端。

但从安全性上考虑，薄弱环节就很多——

首先就是云端如何保证客户的数据安全性？在这个例子里，显然没有，因为DAT文件是可以直接下载的（虽然需要用户名密码，但是没有加密），也就意味着云端可以完全看到所有的客户数据，这对于云服务来说是不可接受的。

其次是传输过程的安全性。HTTP是明文传输的这点基本常识他们都没有？不客气地说，这个产品经理或架构师是吃翔的么？而且看上去他们是用Basic HTTP Auth认证，这种弱爆的认证在明文传输中形同虚设。

最可耻的是据说漏洞还包括一些SQL语句……客户端居然可以执行SQL语句，难道不怕有客户执行drop database么？这再次证明他们的产品经理和架构师是吃翔的。

关于云端认证的问题，乌云原文里说“他们这么做，我觉得动机有问题。。”，这里先不谈动机问题，假设云端认证是有好处的，那么技术上应该如何实现？

首先，就服务端的信息存储来说，认证本身并不需要实际的信息，完全可以对原信息作加密甚至摘要校验即可。比如说只在服务器上存储用户名等信息的MD5值，认证时客户端也只需要上传MD5进行比对即可。确保服务端不保存用户的敏感信息。

其次，作为认证服务，HTTPS是基本配置，甚至还要在此基础上配置自定义的协议，或者更安全一些的公开认证协议，比如OAuth之类。

最后，认证API应该在更高的层面进行设计，并且加以详尽的参数检查，而不应该提供SQL语句这样的底层接口。

如乌云原文所说，我也觉得这个服务商这么做动机有问题。

最明显的问题就在于他们似乎是有意在收集住客信息——如果不是因为他们技术太烂，没有考虑到客户数据安全性的话。

其次，对于这种应用来说，云端认证并不是必须的，或者说用云端认证并没有明显的好处。

一般来说，像这样把认证放在云端，无非是为了节约本地做认证的软硬件成本。但就具体到这个应用上来说，酒店本地应该本来就有服务器用于管理住客信息，加个认证软件应该不会对服务器增加多少额外的负载，放到云端反而降低了效率。

如果一定要说有什么好处的，那也是对第三方认证服务端来说，他们多了一个收费的理由而已。

从这两点上来看，这个服务商真是相当的可耻。

但遗憾的是，似乎国内的服务商基本都是这样的德性。

这大概也是为什么国内的环境总让人觉得很恶劣的原因之一吧。