一、前言

本文旨在告訴讀者如何去發(fā)現和利用潛藏在WEB應用程序中的安全漏洞。懂得這些安全漏洞是如何產生的，才能讓我們在防護的過程中得心應手。這當中，我會試著把一些背景知識，理論，小工具等等東西都介紹給大家。安全意識從來都是一把雙刃劍—-針對應用程序的開發(fā)者和黑客們!開發(fā)者從中知道黑客是如何黑進他們的系統(tǒng)的，而黑客也緊跟開發(fā)者的腳本學習到了開發(fā)上的知識，促使一系列的技術更新和完善?？偠灾?，黑客和開發(fā)者之間的戰(zhàn)斗永不停歇，這場戰(zhàn)斗至少促成一種東西叫：進步!

回頭看看早期的WEB站點，可能沒幾個人真正了解過，除了放幾個靜態(tài)的html頁面。再看看今天流行的WEB頁面，或者我稱呼它為WEB應用程序比較貼切。它具備多功能，動態(tài)交互，注冊和登陸的高級使用功能，配合服務器端的WEB有類似專門的瀏覽器。您可曾想過，這當中的大部分交互和保留的信息中，大部分都是私有和敏感的信息呢。所以安全的確是一個大問題啊。

尋找WEB應用程序，我覺得首先應該看看是誰開發(fā)了這套程序。舉例來說：如果您已找到我網站上面有XSS的漏洞，那么您幾乎可以在我的寫的其他WEB代碼上找到類似的漏洞(想看看我的站嗎?后面有留我的網址)。 換句話說：如果我在WEB程序上犯了一個開發(fā)錯誤(卻一直沒有去糾正過它)，那說明我沒有足夠的能力去修復和意識到這個問題。這極有可能導致我還會在其他WEB開發(fā)中犯下同樣的錯誤。

二、常見的WEB應用場景

(1) 購物 (京東網)

(2) 社交網絡(人人網)

(3) 銀行(招商銀行)

(4) 搜索 (百度)

(5) 拍賣 (淘寶)

(6) 博客 (百度博客)

(7) 電子郵件 (網易EMAIL)

(8) 交互信息 (互動百科)

這些場景，只是舉例。隨著時代的進步，玩轉這些服務需要一個過程!但在這個過程中，人們逐漸把自己需要使用的服務遷移到這些WEB應用程序上面。比如，把微軟的office辦公遷移到google的在線辦公上面去;把outlook的email發(fā)信收信功能遷移到hotmail上面去了。換句話說，WEB應用程序必定會帶來一系列的安全問題。如今的WEB安全早已經成為了焦點。當然，也成了開發(fā)者和黑客們之間戰(zhàn)場!根據OWASP統(tǒng)計，大部分WEB應用程序都是不安全的，有些甚至都沒有接觸過SSL這個東西。去年OWASP發(fā)布了一個跟web有關的漏洞分布圖，見下：

自己去琢磨參透一下上圖的含義吧。

三、 核心防御機制

核心的防御元素概況起來有這么幾點：(1)處理用戶的每個訪問點，確保用戶不會獲得沒有授權的存取這是每個WEB應用都應該做到的安全點位，目的是控制和處理用戶的每個授權點。不同的用戶都有自己不同的訪問區(qū)域，比如匿名用戶，普通用戶，管理員，他們都能訪問到屬于各自不同權限范圍內的內容。如果要細分一下，不如看看之前有牛人提到的縱橫的權限授權注意事項。這里提出3個重要的，影響防御機制的要素：::1 認證環(huán)節(jié)，WEB訪問用戶是誰?匿名用戶還是普通用戶，還是管理員?::2 會話管理，每個會話ID都精確對應到訪問的每個訪問用戶，如何控制和處理好它們?::3 訪問控制，對每個單獨的請求都要做出正確的存取判斷，到的是允許還是拒絕?

以上3個核心環(huán)節(jié)，缺一不可，就好比一個連鎖酒店一樣，任何一個環(huán)節(jié)出了問題都可能導致黑客可以繞過其安全機制獲得非法訪問的權限。(2)處理用戶每次輸入，阻止不希望看到的輸入形式出現眾所周知，黑客每次都輸入各種稀奇古怪的字符來攻擊WEB應用。對此，采取對輸入的數據進行校驗是WEB安全防御中最大的一個安全防護環(huán)節(jié)。不可輕視。 (3) 應對攻擊者，采取適當的防御性甚至主動防御性的措施來挫敗攻擊者這關鍵還是看WEB應用程序的安全防御機制。上面提到防御性措施和主動性防御旨在阻撓黑客進一步滲透和攻擊系統(tǒng)。這期間，如果能將被攻擊的消息和數據發(fā)送給網站管理員的話，將有助于及時封堵網站的安全漏洞。我來舉個例吧，比如有個黑客通過一句話木馬老去鏈接一個網站的一個文件。1個小時下來，這個文件的訪問頻率肯定是非常高了。剩下的，你懂的。類似的，針對攻擊者的安全防御機制還有： 錯誤信息處理，日志審核，重復攻擊，管理員監(jiān)控警報等等。(4) 應用程序管理，類似自檢功能。管理員需要將程序的功能都監(jiān)控起來(比如日志記錄)，聽起來有點像QA做的事情。目的是要確保這個功能接口的配置正確。(不正確的WEB應用程序配置，常常是開發(fā)者帶給黑客的“禮物”，這不是運維的問題，不要混淆，這里沒有在搭建配置NGINX)。縱觀一下，大部分WEB應用程序都有一個類似管理后臺，而大部分管理后臺中卻有安全機制不太明確的地方。我注意到有這么幾個內部安全弱點: ::1 在認證環(huán)節(jié)，如何判斷對方是否是真正的管理員。一個攻擊者通過類似萬能密碼就進入了管理后臺，這很有可能危及整個WEB主機安全。 ::2 有的管理面板在后臺可以創(chuàng)建一個跟管理員權限一樣大的用戶出來，這種高級權限的分發(fā)機制有時候很難把控。 ::3 跨站攻擊能夠讓一個具有管理員權限的session會話暴露給其他非法的使用者，還記得打后臺的那些xss腳本嗎?在應用功能模塊里對邊界層數據進行校驗是不可缺少的：

四、攻擊應用

第一步得做的，自然是盡可能多的收集需要攻擊站點的信息。下面列出的步驟可以方便您在“攻擊”之旅上更順暢：

(1) 像蜘蛛一樣收集對方站點信息當然目標是全面的收集有用的站點內容信息。想要最快的熟悉查看對方的網站布局，可以看看robot.txt 和 對方的網站地圖。有時候在這些文件里常常隱含著一些敏感的信息，您一定會對其感興趣的。而這樣的信息收集工具都有哪些呢，舉例如下：- Paros 這是一個java程序，基于http和https的方式來評估web的安全風險，可以在線編輯提交給服務器端的http消息體(有點像burp和zap)。其他特性包括蜘蛛功能，客戶端證書，代理鏈，集成的xss和sql注入掃描功能。- Burp Spider 這個不多說了，玩過burp都知道，更的介紹來這里看看。- Web Scarab 這個工具是一個可以分析http/https協議的框架工具，也是java寫的，跨多平臺。有多種工作模式，含有大量插件，用法都較為常見，易學上手。當用蜘蛛收集這些站點的信息的時候，我們總是希望可以得到一些隱藏的內容比如備份文件和一些有用的文檔。比如，我們如果可以通過蜘蛛爬行獲得一些對方網站新開發(fā)的功能模塊(這些模塊頁面由于沒有測試而匆忙上線的)，或者得到一些沒有下線的有漏洞的老網頁模塊，一些有價值的配置文件等等(包含文件，源文件和日志文件等等)。

(2)投射攻擊面把您采集得到的信息投射到不同的攻擊層面上來和攻擊渠道結合起來看的話，我們大致列出下面的幾個方面供大家參考：

- 客戶端校驗 有些WEB代碼在客戶端校驗用戶的數據，嘗試檢查一下這些數據是否在服務器端有無做過校驗?

- 數據庫交互 注意檢查是否有sql注入攻擊

- 文件的上傳和下載 注意檢查是否有LFI漏洞和#0覆蓋漏洞

- 用戶輸入數據展現 是否可以考慮可以丟個跨站腳本上去

- 動態(tài)的網站重定向 是否可以注入惡意的http header進去

- 用戶登錄 此處可以枚舉用戶，弱口令用戶和暴力破解用戶密碼?

- 多級登錄 對方的登錄邏輯是否完善可靠,比如oauth 1.0

- Session數據 考慮對方是否正確的處理了Session數據,其數據令牌是否可以被猜解?

- 權限控制 對方是否對垂直和水平權限深刻領悟?有些開發(fā)者者真的就是只懂編碼，真正的碼農，可悲。

- 用戶模擬 嘗試修改URL參數來提升登陸用戶的訪問級別，特權訪問- 明文通訊 session劫持，捕獲用戶登陸憑證和敏感數據

- 離線的站點鏈接 有些高端網站用了url重寫隱藏了真實地址上面的參數，離線站點鏈接可能暴露了這些參數的真實排布

- 系統(tǒng)對外的開放的接口 這些接口往往泄露了一些特別的存取權限和特定session的處理接口- 錯誤消息 一些敏感信息泄露(類似http 500 錯誤泄露的mssql信息)

- 電子郵件交互 是否可以郵件掛馬發(fā)給對方使其中招?

- 本地代碼組件下載 此類組件往往跟服務器有通訊接口，該接口是否可以溢出?

- 第三方組件 眾所周知的漏洞利用，比如大牛最愛的fckeditor…- web標頭信息的泄露 該信息可以明確對方的web服務器版本，跑的什么服務，這些版本和服務都有什么眾所周知的漏洞可以加以利用。

(3)關于繞過客戶端機制的舉例- 表單里面的隱藏域看看下面這段代碼：

Product: Sony VAIO A217S

Quantity:

很明顯，price就是一個隱藏域，它會被POST提交：POST /order.asp HTTP/1.1

Host: wahh-app.com

Content-Length: 23

Quantity=1&price=1224.95

我們可以采用2種方式來修改隱藏域，1、將它們保存到本地,然后用html代碼填寫好相應的價格，提交到服務器。2、用上面我們提到的交互式工具webscrab或者burp來實時修改提交的參數。這樣就能隨意的修改這個價格參數了(如果服務器端不做校驗的話)。http cookies如何修改cookies呢?作為提交數據的一部分，我們可以用交互式的webscrab或者burp來實現。當然了，現在也有人玩fiddler，工具是死的，人是活的。繞過客戶端數據檢查的相關的方式還有很多，比如url參數變化，referer的改寫等等。結論WEB服務器端接受客戶端提交的數據最終不像預期那樣可信。在客戶端對數據進行的校驗，最終都可能在提交的過程中被修改。具備簡單的工具和很少的技術含量就可以實施客戶端的攻擊。我們應該規(guī)避這些攻擊，而且也是可以做到規(guī)避的。就看你做沒做。

五、攻擊認證機制

這個比較好玩，認證最好的體現就在登陸用戶上面。首先我們要做的就是看看這個網站是否有對注冊密碼的嚴格要求。如果一個網站沒有對密碼的嚴格規(guī)定，那么必定存在弱口令密碼之類的東西。如果對方沒有對密碼認證制定嚴格的策略的話，那就可以使用暴力破解的工具來對弱口令賬號進行攻擊。其他攻擊認證機制的環(huán)節(jié)有：1. 攔截數據包，并且修改數據包 如果對方在處理認證憑證上面不是太下功夫的話2. 密碼更改功能 是否可以改到其他賬號的密碼3. 密碼找回功能 還記得用burp找回賬號丟失的密碼嗎?4. “記住我”這個按鈕的功能使session持久，以至于可以持久到被人xss后還可以用。5. 后臺可以預見的初始化密碼， 比如 admin888 地球人都知道的6. 不安全的證書分布 遺失的SSL證書驗證機制可能讓后臺形同虛設7. 不安全的存儲憑證 有些安全憑證被存放到了可以被非法獲取的地方最重要的實踐還是要從不同的角度去嘗試。特別留意主窗口的登陸窗體，那里常常有注冊賬號，找回密碼，記住密碼等諸多功能。這些地方都富含了潛在的漏洞和缺陷?；〞r間到攻擊映射層面的每個地方，也許真的會換來意想不到到的“回報”。