如果沒有驗證碼會怎樣？

05-14

正如前面的相關文章提到，驗證碼是網路系統的防火牆，但是平常大家感覺，只有困擾，沒有收益，那麼如果網路系統沒有驗證，會怎樣呢？

1 寫作目的

本文講述一個簡單的利用WebAPI來進行一次基本沒有破壞力的「黑客」行為。

主要目的如下：

了解什麼叫安全漏洞
知道什麼是api
了解一些獲取api的工具

免責聲明：

本文主要是以學習交流為目的，而且實驗的對象也是通過搜索引擎隨機選擇的。不以搞破壞為目的，純粹是以教學為目的，同時也警醒大夥重視基本的互聯網安全。當然，本文會對關鍵字打個馬賽克，防止有興趣的同學也把網站主當了靶子了。

2 背景介紹

先說一個在互聯網上常見，但是普通人又不太理解的東西--「驗證碼」。

下面是來自 百度百科 的一段解釋：

驗證碼（CAPTCHA）是「Completely Automated Public Turing test to tell Computers and Humans Apart」（全自動區分計算機和人類的圖靈測試）的縮寫，是一種區分用戶是計算機還是人的公共全自動程序。可以防止：惡意破解密碼、刷票、論壇灌水，有效防止某個黑客對某一個特定註冊用戶用特定程序暴力破解方式進行不斷的登陸嘗試，實際上用驗證碼是現在很多網站通行的方式，我們利用比較簡易的方式實現了這個功能。這個問題可以由計算機生成並評判，但是必須只有人類才能解答。由於計算機無法解答CAPTCHA的問題，所以回答出問題的用戶就可以被認為是人類。

一般對於開放式的互聯網應用，在有需要「上行」數據介面的地方都需要加上一道驗證碼（也可以是驗證簡訊，但是考慮到成本問題，驗證碼還是更普遍一些），以防止機器程序使用其遠高於人的計算能力進行一些惡意破壞行為。

所謂的惡意行為從技術本質上講就是利用web應用已經提供的一些介面，來對網站主的後台資料庫進行 增/刪/改/查 的操作，而且由於這種操作是由計算機來完成，計算機巨大的計算能力常常伴產生極恐怖的破壞力。

查詢數據

耗盡網路式攻擊。攻擊者網路帶寬資源超級豐富的，可以OS佔滿被攻擊對象的入口和出口帶寬，無法對外正常提供服務。
耗盡伺服器負載攻擊。大量高並發的資料庫請求，超過資料庫的最大連接數，導致web應用無法完成資料庫的正常查詢。
耗盡伺服器CPU攻擊。對於有複雜計算的應用，每次調用一次服務會造成大量的CPU消耗，導致服務異常。
耗盡伺服器內存攻擊。通過查詢產生大量的session，耗盡伺服器內存。

增加數據在web應用裡面惡意註冊幾十萬級別的殭屍用戶。然後通過程序來操控這些用戶來投票，轉發，刷帖等等。比如，微博，廣告行業
刪除/修改數據造成數據的不正常，這樣的後果也是不可估量的。比如金融行業，比如電子交易行業。

通過「圖靈測試」可以達到對自然人和機器的良好區分，以達到將機器程序抵擋在外面的目的，阻止其利用其強大的計算能力和自動化信息處理能力來實施破壞。這就是「驗證碼」的最基本作用。

那麼回歸到今天的正題，既然是「黑客技術入門」和「介面自動化測試」的入門篇，本文就先挑一些難度低的開始，專門找「軟柿子」來捏一下。

3 主要工具

Google搜索引擎搜索資料和尋找「獵物」
Chrome查看web應用提供的介面的最簡單的方式
Wireshark一種高級的查找介面的工具，可在某些不適合Chrome的場合進行使用
Python編碼破解代碼的腳本

4 尋找實驗對象

通過搜索引擎，找關鍵字：「意見反饋」、「用戶反饋」，得到如下的搜索結果：

「用戶反饋」模塊有如下特點：

有數據上行。因為有向伺服器提交數據，會通過相應的介面往網站主伺服器上寫相應的數據。
在Web應用裡面重要性很低。很多是象徵的擺設，所以安全防範極低。
不涉及具體的重要業務。可以在練手的同時，也不會產生多少破壞。

只需要找出裡面沒有驗證碼的頁面就可以了，主要的搜索結果如下：

有驗證碼的網站：

360好搜
鳳凰網
http://56.com

無驗證碼的網站：

新浪微博
搜狗網址導航
百度音樂
百度百科
網易163
有道詞典
易車
114la
中科大教務處

這只是Google的前兩頁的搜索結果，發現已經有一大半在這一塊是沒有進行任何防守的。既然已經找到了這麼一個簡單的安全「漏洞」，下面就開始實施無關痛癢的「攻擊」行為。

由於本文主要是出於學習和交流目的，為了保護實驗對象的一些隱私，所以下面的圖片和相應的URL都會進行一些簡單的馬塞克。

5 收集api信息

由於Web應用系統本身是不對外開放api的，但是互聯網公司的產品為了追求高擴展性和前後端完全分離獨立，通常使用如下技術架構：

互聯網應用的架構，客戶端和伺服器一般都是基於Http API來進行通訊，所以對於B/S的程序來說，可以很容易通過一些輔助工具來找到通訊的介面。

某個網站「有幸」被選中了：

http://x.xxx.xx/ugc/out/feedback/

使用Chrome瀏覽器打開頁面

然後填寫好表單之後，點擊提交按鈕。當然，因為提交按鈕之後，會跳轉到另外一個頁面，不便於我們查看提交的數據值，所以要做一些簡單的修改，就是表單提交的伺服器API簡單修改成一個不存在的即可：

然後在Chrome的Network裡面可以看到介面信息：

然後將右側的介面詳細數據信息展開，就可以查看到表單值：

這個表單就告訴了我們此網站應用的伺服器端API所接收的合法的數據的格式，這樣就相當於知道了調用的方式了。

知道了介面，知道了調用方式，那麼接下來就可以通過寫程序來實施「黑客」行為了。

6 編寫腳本

由於本人python比較熟悉，所以就使用python來進行相應的操作演示。

def test_crack_feedback(): """ 反饋頁面刷的測試 :return: """ url_para = { proType: 5, platType: 1, referer: https://www.google.com/, content: 看你們是否存在此漏洞, tel: 123144, email: adsf@11, qq: 123544, location: 北京市, ip-location: 北京市, ip-service: 聯通, } post_url = http://x.xxx.xx/ugc/out/feedback/?act=add res = requests.post(post_url, data=url_para) print(res.text)

返回值

[2015-05-27 10:58:51,166] connectionpool.py:_new_conn-(259)INFO: Starting new HTTP connection (1): x.xxx.xx[2015-05-27 10:58:51,764] connectionpool.py:_make_request-(390)DEBUG: Setting read timeout to None[2015-05-27 10:58:52,175] connectionpool.py:_make_request-(430)DEBUG: "POST /ugc/out/feedback/?act=add HTTP/1.1" 200 None[2015-05-27 10:58:52,245] singlefun.py:run_xxx-(29)DEBUG: {"retcode":200,"message":null}

根據200的狀態碼，明顯是成功了。因為有經驗的Web開發人員都清楚，Http的200狀態碼就表示成功調用的返回值了。

如果我使用個for循環，將此程序運行100萬次，那麼這個網站主的這個地方的資料庫估計就要抓狂了。如果使用多個機器連續瘋狂的刷，而且恰好這個數據表和他們的核心業務資料庫放在一起，那麼這將會導致資料庫連接數量超過極限，導致正常的服務無法被提供了。

7 總結和展望

本文只是演示了如何利用Chrome去尋找Web應用的介面及調用。而對於看不到前端代碼的App應用，則可以通過抓包工具Wireshark來輕鬆獲得相應的介面及調用。

網站主避免此漏洞的方法：給相應的位置加上可靠的「驗證碼」即可。 PS：傳統的字元型驗證碼，稍微會一些圖片識別技術，或者機器學習技術，也是相當好破解的。目前的OCR技術已經相當發達了，想想註冊Gmail的時候，那一串人都不認識的字元，結果程序可以進行90%的成功破解率，可想而之機器遠比人類想像得要厲害。

當然，如何做好「圖靈測試」對「自然人」和「機器人」進行區分，已經成為安全領域的一個重要的課題，也非本文重點討論的問題了，有興趣的同學可以在相關領域繼續研究吧。

這個事情給做Web應用系統的人員兩個警鐘：

所有涉及到數據交互的地方，最好加上驗證碼。
數據盡量要按照重要等級分開部署。