接口自動化測試的"開胃小菜"---簡單黑客攻擊手段

Web應用系統的小安全漏洞及相應的攻擊方式

接口自動化測試的"開胃小菜"

1   寫做目的

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

主要目的以下：

• 瞭解什麼叫安全漏洞
• 知道什麼是api
• 瞭解一些獲取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好搜
• 鳳凰網
• 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   編寫crack腳本

因爲本人python比較熟悉，因此就使用python來進行相應的操做演示。

def test_crack_feedback(self):
    """
    反饋頁面刷的測試
    :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)
    glog.debug(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應用系統的人員兩個警鐘：

• 全部涉及到數據交互的地方，最好加上驗證碼。
• 數據儘可能要按照重要等級分開部署。

8   免責聲明

• 本文只是以學習交流爲目的
• 本文沒有產生破壞行爲
• 本文所獲取的信息都是經過正常的暴露在外部的信息獲得的
• 本文隱藏了具體的URL目標的信息
• 若是實在是有人有要求認爲本文形成了事實傷害，做者會按照要求刪除此文
• 最後但願此文可以給有志作接口自動化測試的朋友提供了一個好的「開胃菜」

---

做者:	Harmo哈莫
做者介紹:	https://zhengwh.github.io
QQ:	1295351490
時間:	2015-08-24
版權說明:	未經許可，嚴禁用於商業目的的非法傳播
聯繫或打賞:	http://zhengwh.github.io/contact-donate.html