以黑客的眼光來審視網路安全性，往往可以發現很多潛在的安全漏洞。這樣做不僅提供了審視你網路系統的不同視角，而且讓你能夠從你的敵人，即黑客的角度來指導你採取最有效的網路安全措施。下面，我們來看一下網路系統分析的過程。這個過程要用到開源工具和相關技術。 用開源工具收集信息 首先，登錄Whois.com網站查找你企業的域名，檢索結果將會顯示出你的網路系統所使用的DNS伺服器。然後再使用一些軟體工具，如:nslookup，來進一步挖掘DNS伺服器的詳細信息。 此外，在你的上述搜索操作中，一定要特別注意這些網站上已顯示的和沒有顯示的信息。最好，把這些網頁存入你的電腦中，然後用記事本程序打開，查看網頁的源代碼。一般而言，查看網頁的源代碼可以大量的信息，這也就是某些站點有意對瀏覽者屏蔽源代碼的原因。在源代碼文件中，你也許能夠了解到網站開發者建站的方式:他們所使用的軟 件類型及軟體版本、網站以及網頁的架構，有時候甚至能夠發現一些網站管理員的個人資料。 業務合作夥伴的站點或一些新的並購企業的站點往往是黑客入侵的關鍵點。這些站點是間接入侵目標站點的最佳突破口，容易被網站管理員所忽視，給黑客攻擊者製造了大量的機會。如果你在這方面沒有足夠的警惕性，疏忽大意，很草率地新某個新的業務合作者的網站和你自己的站點聯接起來，往往會造成很嚴重的後果，給你的站點帶來極大的安全威脅。在這樣的情況下，安全問題比經營問題更加重要，一定要確保安全操作。 從外部審視網路 有了上述信息收集，你可以開始審視你的網路了。你可以運用路徑追蹤命令來查看你的網路拓撲結構圖和訪問控制的相關設置。你會獲得大量交換機的特徵信息，用來旁路訪問控制設備。 注意，命令的反饋結果會因為所使用操作系統的不同而有所差別。UNIX操作系統使用UDP，也可以選擇使用ICMP;而Windows操作系統默認用ICMP來響應請求（Ping）。 你也可以用開源工具管理大量ping sweep、執行TCP/UDP協議掃描、操作系統探測。這樣做的目的就是要了解，在那些外部訪問者的眼中，你的網路系統的運行狀況和一些基本的面 貌、特徵。因此，你需要檢驗你的網路系統，哪些埠和服務對外部訪問者是開放的或可用的，外部訪問者是否可以了解到你所使用的操作系統和一些程序，極其版本信息。簡言 之，就是要了解到你的網路系統究竟對那些外部訪問者開放了哪些埠或服務，泄露了哪些站點的基本信息。 在你開始上述工作之前，你必須要先獲得足夠的授權，才能進入整個網路系統並對其進行考察、分析。千萬不要將你了解到信息告知那些不懷好意的人。記住:安全防護是一個實 施過程，而不僅僅是一種技術。
2. 如何測試一個網站是否有安全漏洞
掃描網站漏洞是要用專業的掃描工具，下面就是介紹幾種工具
1. Nikto
這是一個開源的Web伺服器掃描程序，它可以對Web伺服器的多種項目進行全面的測試。其掃描項目和插件經常更新並且可以自動更新。Nikto可以在盡可能短的周期內測試你的Web伺服器，這在其日誌文件中相當明顯。不過，如果你想試驗一下，它也可以支持 LibWhisker的反IDS方法。不過，並非每一次檢查都可以找出一個安全問題，雖然多數情況下是這樣的。有一些項目是僅提供信息類型的檢查，這種檢查可以查找一些並不存在安全漏洞的項目，不過Web管理員或安全工程師們並不知道。
2. Paros proxy
這是一個對Web應用程序的漏洞進行評估的代理程序，即一個基於Java的web代理程序，可以評估Web應用程序的漏洞。它支持動態地編輯/查看 HTTP/HTTPS,從而改變cookies和表單欄位等項目。它包括一個Web通信記錄程序，Web圈套程序，hash 計算器，還有一個可以測試常見的Web應用程序攻擊的掃描器。
3. WebScarab:
它可以分析使用HTTP和HTTPS協議進行通信的應用程序，WebScarab可以用最簡單地形式記錄它觀察的會話，並允許操作人員以各種方式觀查會話。如果你需要觀察一個基於HTTP(S)應用程序的運行狀態，那麼WebScarabi就可以滿足你這種需要。不管是幫助開發人員調試其它方面的難題，還是允許安全專業人員識別漏洞，它都是一款不錯的工具。
4. WebInspect：
這是一款強大的Web應用程序掃描程序。SPI Dynamics的這款應用程序安全評估工具有助於確認Web應用中已知的和未知的漏洞。它還可以檢查一個Web伺服器是否正確配置，並會嘗試一些常見的 Web攻擊，如參數注入、跨站腳本、目錄遍歷攻擊等等。
5. Whisker/libwhisker :
Libwhisker是一個Perla模塊，適合於HTTP測試。它可以針對許多已知的安全漏洞，測試HTTP伺服器，特別是檢測危險CGI的存在。 Whisker是一個使用libwhisker的掃描程序。
6. Burpsuite：
這是一個可以用於攻擊Web應用程序的集成平台。Burp套件允許一個攻擊者將人工的和自動的技術結合起來，以列舉、分析、攻擊Web應用程序，或利用這些程序的漏洞。各種各樣的burp工具協同工作，共享信息，並允許將一種工具發現的漏洞形成另外一種工具的基礎。
7. Wikto:
可以說這是一個Web伺服器評估工具，它可以檢查Web伺服器中的漏洞，並提供與Nikto一樣的很多功能，但增加了許多有趣的功能部分，如後端 miner和緊密的Google集成。它為MS.NET環境編寫，但用戶需要注冊才能下載其二進制文件和源代碼。
8. Acunetix Web Vulnerability Scanner :
這是一款商業級的Web漏洞掃描程序，它可以檢查Web應用程序中的漏洞，如SQL注入、跨站腳本攻擊、身份驗證頁上的弱口令長度等。它擁有一個操作方便的圖形用戶界面，並且能夠創建專業級的Web站點安全審核報告。
9. Watchfire AppScan：
這也是一款商業類的Web漏洞掃描程序。AppScan在應用程序的整個開發周期都提供安全測試，從而測試簡化了部件測試和開發早期的安全保證。它可以掃描許多常見的漏洞，如跨站腳本攻擊、HTTP響應拆分漏洞、參數篡改、隱式欄位處理、後門/調試選項、緩沖區溢出等等。
10. N-Stealth：
N-Stealth是一款商業級的Web伺服器安全掃描程序。它比一些免費的Web掃描程序，如Whisker/libwhisker、 Nikto等的升級頻率更高。還要注意，實際上所有通用的VA工具，如Nessus, ISS Internet Scanner, Retina, SAINT, Sara等都包含Web 掃描部件。N-Stealth主要為Windows平台提供掃描，但並不提供源代碼。
3. 注入漏洞的檢測方法
目前比較准確的檢測注入漏洞的方法是進行網站漏洞掃描，推薦EeSafe網站安全聯盟。
查找與修補
一、注入點的查找
當我們想要測試某個站點時，一般會架上注入工具對其狂轟亂炸，這樣做雖然有時能找到注入點，但還是有些盲目，我個人的看法是：如果有源碼的話，就從源碼入手，在源碼中查找注入點。對於源碼，有些朋友可能覺得很難，其實源碼並不神秘，它也是有一定的語法規則的，看一套優秀的源碼就像是在欣賞一部精美的電影，只要我們堅持每天看一些優秀源碼，再加上網路這個老師的指點，用不了多久，源碼的神秘面紗就會被你揭去。閑話少說，下面我們就開始查找注入點，目標有兩個：一是Request，二是SQL語句。
說到Request，這個是ASP程序中的一個內建對象，怎麼？不懂？那就跟我先來惡補一下吧！它是用來獲取客戶端信息的，有五種方法，而會出現注入點的一般有以下三種：
1、Request.QueryString：取得客戶端提交的信息。當Form以Get方法提交信息，或是直接在URL中提交變數值時，在伺服器端接收數據時採用的就是這種方法。
2、Request.Form：同樣也是取得客戶端提交的信息，但它接收的是Form以Post方法提交的信息。
3、Request.Cookies：取得客戶端瀏覽器的Cookies信息。Cookies就是小甜餅，指的是一些私人信息，如用戶名、密碼之類的信息。
有些程序員為了減少錯誤，對於前兩種信息的獲取，會採用Request來取得客戶端提交的信息，這種方法，雖然可以通吃Request.QueryString和Request.Form的提交信息，但如果過濾的不好，就會被漏洞反咬一口。
了解過一些Request的知識後，下面就在「查找」中輸入「request」進行搜索，OK！當找到上面所列的三項Request語句後，再來看一下程序對這些Request語句是否做了過濾，比如ID值是否用INT過濾，例：id=int(request(id))；字元串值是否用replace ()或instr()等函數進行過濾單引號或一些特殊字元，例：username=replace(request(username),, )；或者程序是否採用本身的一些過濾函數來過濾這些提交值。從查找到這句request參數起，一直到SQL語句中使用這個提交值至，如果中間沒有上面的層層關卡，那麼，一個注入點，基本上就算是出現了。
說到SQL語句，不能不提到以下幾個常用的語句：
1、查詢語句：Select [(<欄位名1> [,<欄位名2>, ...])] FROM <表名JMDCW> [Where <條件表達式> [AND|OR <條件表達式>...]
2、更新語句：Update <表名JMDCW> SET 列名1 = 常量表達式1[,列名2 = 常量表達式2 ...] Where <條件表達式> [AND|OR <條件表達式>...]
3、刪除語句：Delete FROM〈表名JMDCW〉[Where <條件表達式> [AND|OR <條件表達式>...]]
這里不對SQL語句做介紹了。在上面列出的SQL語句中，注入點出現頻率最高的是Select語句，而注入參數的出沒地通常都是在Where之後的條件中。當一個沒有過濾的Request語句進入SQL語句後，就是注入大顯身手的時候了，不過，在進行注入之前還要先看一下該參數是直接引入，還是用單引號引入的，另外，該參數是否還應用於其他SQL語句中，然後，根據不同的信息，選擇不同的處理方式，或直接暴破，或UNION查詢，當然，如果存在注入點的程序使用的是SQL資料庫，那就不單單是得到一些重要信息，甚至還可以增加管理員。
下面用「螞蟻影院3.0」版注銷用戶(wantlogin.asp)中的一段源碼來做一下介紹：
引用
<%
if request(userid1)<> then
set rst=server.createobject(adodb.recordset)
sql=select money,online from users where userid=&request(userid1)& and password=&md5(request(pws))&
rst.open sql,conn,1,3
if rst.eof and rst.bof then
response.write<script>alert(用戶名或密碼錯誤！);history.back();</Script>
else
response.write<script>alert(恢復成功你現在可以登陸！);</Script>
response.write<script Language=Javascript>location.href = index.asp;</script>
rst.close
set rst=nothing
conn.close
set conn=nothing
end if
end if
%>
在其流程中，首先判斷取得的提交值userid1是否為空，不為空的話就進入SQL語句中，驗證取得的用戶名及密碼是否和資料庫內的用戶名及密碼一致，如果不一致，則彈出「用戶名及密碼錯誤」窗口，否則，就彈出「恢復成功」的窗口。這也是一段典型的注入漏洞源碼，並且，接收的方式還是使用的 request，這就給我們提交注入語句提供了最大的方便。如果我們在URL地址中提交如下字元：http: //127.0.0.1/wantlogin.asp?userid1=aa&pws=bb，因為沒有aa這個用戶，那麼就會彈出錯誤窗口，而如果我們將aa換成如下字元：aa or1=1 or 1=1，pws保持不變，這樣提交的語句到了SQL語句中就成了如下語句：
select money,online from users where userid1=aa or 1=1 or 1=1 and password=md5(bb)，以往我們所見到的測試代碼一般為「or 1=1」，而這里卻多用了一個 or ，為什麼要多用一個or呢？解釋一下，在邏輯運算符中，and的優先順序別高於or ，程序運行後會先運算後面的1=1 and password=md5(bb)，因為密碼是隨便輸入的，所以and後的password值為假，而and前的1=1雖然為真，但真and 假=假，所以，這個and的運算值為假，再來看or運算，因為前面的用戶名也是不存在的，其值當然為假，如此一來，where後的邏輯運算就成了如下表達式：假or真or假，結果值還是為真，這樣就會彈出「恢復成功」窗口，如果將其中的or 1=1 改為or 1=2，那邏輯表達式則成了：假or假or假，值當然也為假，彈出的就是「用戶名或密碼錯誤」的窗口。這樣，根據彈出窗口的不同，我們就可以構造一些特殊字元，然後猜測出需要的數據了，比如查詢管理員ID的語句，將or後的1=1更改為： 1=(Select top 1 id from admin)，這里暫用admin表示管理員表名，如果存在ID為1的管理員，那麼就會彈出「恢復成功」的窗口，否則，就證明管理員的ID不為1，那就要再用其他數字來測試。猜出管理員ID後，再把此段字元更改為猜測管理員名稱長度的字元：5<(Select len(adminname) from admin where id=1)，如為真，則證明長度大於5，否則長度小於或等於5。猜出長度後，再用asc()函數來猜測管理員的名稱：90<(select asc(mid(adminname,1,1)) from admin where id=1)，如此循環，就能暴破出管理員的名稱及密碼了。
上面提到的是Request.QueryString和Request.Form的注入方法，而Request.Cookies的注入方法則是要修改本地的Cookies值來實現的，推薦使用一些專門的Cookies修改工具，不過，用Cookies來注入相對而言，就麻煩了好多，但原理和前面的注入是一樣的，這里就不介紹了。
二、注入點的修補
在上面著重講了如何查找注入點及簡單的利用方法，當我們知道了攻後，也就明白了如何守，攻和守之間雖然是對立的，但也是相互的。明白了什麼地方存在注入點，再來修補也就容易多了。在前面查找注入點時，我也提到查看程序中是否對提交參數進行了過濾，每個程序對注入的過濾函數都不相同，我們在修補自已站點上的注入點時，可參照其他程序中的過濾函數，也可根據自已的需要，單獨過濾一些敏感的字元。這里，還是以上面的那個例子來說一下如何修補注入點。在前面的 SQL語句中有這一句：userid=&request(userid1)&，這其中對提交來的參數是用單引號來引入的，而我們能成功注入也是在提交參數中加入了單引號來閉合其語句，這樣，加入一個replace()函數對單引號進行過濾，修改後的語句為：userid= &replace(request(userid1),,)&，這樣用戶再提交帶有單引號的字元時， Replace()就會將單引號過濾為空，如此一來，提交的那些特殊字元也就失去了其意義。
當然，我們還可以在userid1進入SQL語句之前，對其長度進行一下判斷，如果超過規定的長度，就彈出錯誤，中止頁面執行並返回到指定的頁面。當然還可以借鑒一些優秀源碼中的過濾方法。總之，注入漏洞是可以避免的，即使出現了注入點，只要我們分析出其出現的原因，也就能很容易地將其修補了！
