雲服務商的技術問題和商業道德問題

前兩天烏雲報了乙個漏洞：《如家/漢庭等酒店客戶開房記錄被第三方儲存並因漏洞導致洩露》。

就個人來說，這種問題可能沒啥影響，因為你可能不住這幾家酒店，而且在兲朝，***，真要查這些資訊，一般都會通過某些官方渠道，根本不需要這種手段。

但是……且不說其它酒店也可能有類似問題，更可怕的是除了酒店以外，其它地方也有可能有類似的問題——只要它們用了某些無良國內廠商的服務……

這才是本文要討論的問題所在。

烏雲的原文裡已經基本解析了這個漏洞的技術問題。整個系統的工作原理大致是這樣：

酒店把入住人的資訊上傳到第三方認證伺服器，然後住客要上網時就會被重定向到認證伺服器，輸入認證資訊後通過認證，然後才可以上網。

所以並不是只有在酒店上網才會洩露，而是從入住開始，這些資訊就已經被傳到認證伺服器了。

從表面上看這個系統結構沒有什麼大問題，是一種典型的雲端認證系統——各酒店不需要自己建設認證系統，只需要統一把資料給雲端，所有使用者認證過程也在雲端。

但從安全性上考慮，薄弱環節就很多——

其次是傳輸過程的安全性。http是明文傳輸的這點基本常識他們都沒有？不客氣地說，這個產品經理或架構師是吃翔的麼？而且看上去他們是用basic http auth認證，這種弱爆的認證在明文傳輸中形同虛設。

最可恥的是據說漏洞還包括一些sql語句……客戶端居然可以執行sql語句，難道不怕有客戶執行drop database麼？這再次證明他們的產品經理和架構師是吃翔的。

關於雲端認證的問題，烏雲原文裡說「他們這麼做，我覺得動機有問題。。」，這裡先不談動機問題，假設雲端認證是有好處的，那麼技術上應該如何實現？

首先，就服務端的資訊儲存來說，認證本身並不需要實際的資訊，完全可以對原資訊作加密甚至摘要校驗即可。比如說只在伺服器上儲存使用者名稱等資訊的md5值，認證時客戶端也只需要上傳md5進行比對即可。確保服務端不儲存使用者的敏感資訊。

其次，作為認證服務，https是基本配置，甚至還要在此基礎上配置自定義的協議，或者更安全一些的公開認證協議，比如oauth之類。

最後，認證api應該在更高的層面進行設計，並且加以詳盡的引數檢查，而不應該提供sql語句這樣的底層介面。

如烏雲原文所說，我也覺得這個服務商這麼做動機有問題。

最明顯的問題就在於他們似乎是有意在收集住客資訊——如果不是因為他們技術太爛，沒有考慮到客戶資料安全性的話。

其次，對於這種應用來說，雲端認證並不是必須的，或者說用雲端認證並沒有明顯的好處。

一般來說，像這樣把認證放在雲端，無非是為了節約本地做認證的軟硬體成本。但就具體到這個應用上來說，酒店本地應該本來就有伺服器用於管理住客資訊，加個認證軟體應該不會對伺服器增加多少額外的負載，放到雲端反而降低了效率。

如果一定要說有什麼好處的，那也是對第三方認證服務端來說，他們多了乙個收費的理由而已。

從這兩點上來看，這個服務商真是相當的可恥。

但遺憾的是，似乎國內的服務商基本都是這樣的德性。

這大概也是為什麼國內的環境總讓人覺得很惡劣的原因之一吧。