網站指紋是 Web 服務組件在開發時留下的類型、版本等標記信息，包括 Web服務器指紋、Web運用指紋及前端框架指紋等。我們可以通過前端網頁和返回一些 HTTP 頭信息來判斷網站使用的哪些開發框架、服務器、系統，在滲透測試時也可以提供有針對性的測試思路。

一、Web 應用技術概覽

1.1 架構

大多數 web 應用可以粗略劃分為三個組件(component)。

1、客戶端, 大多數情況下是瀏覽器。

2、服務端, Web服務器接收客戶端的HTTP請求并進行響應。另外，有時候 Web服務器只轉發請求到應用服務器(Application Server),由應用服務器來處理請求。

3、后端存儲, 后端存儲一般是DBMS,用于查詢和存儲數據。

所有組件都有不同行為，這些不同行為將影響漏洞的存在性和可利用性。所有組件(無論是客戶端還是服務端)都有可能產生漏洞或者其他安全問題。

1.2 客戶端技術

主流的客戶端技術每天都在被大量互聯網用戶使用，包括 HTML, JavaScript, Flash … 他們常用的瀏覽器則是 Chrome, Firefox, Opera, IE/Edge, Safari 等。另外，包括Android應用的 webview 以及部分PC客戶端應用(比如QQ或者某些游戲登陸器),也會引入一部分 web 客戶端技術。

1.3 服務端技術

在服務端，盡管使用任何技術的任何Web應用都有或多或少的潛在漏洞，但對于某些特定技術(如PHP, Struts2等)的網站,則相對更容易產生漏洞。簡單劃分的話服務端技術大概有以下幾類。

1、Web服務器(Web Server), 包括 Apache, lighttpd, Nginx, IIS.

2、應用服務器(Application Server), 包括 Tomcat, Jboss, Oracle Application server .

3、編程語言, 包括 PHP, Java, Ruby, Python, C#. 對于后三種語言，一些常見的框架包括 Ruby-on-Rails, .Net MVC, Django 等。

1.4 后端存儲技術

對于大多數中小型網站，數據庫和Web服務器是在同一臺主機的。常見的后端存儲技術包括:

1、關系型數據庫, 包括 MySQL, Oracle, DB2, SQL Server, PostgreSQL, SQLite 等。

2、NoSQL, 包括 MongoDB, CouchDB, Redis 等。

3、目錄訪問, 包括 openLDAP, Active Directory。

二、Web 服務器指紋分析

2.1 Web 服務器指紋內容

我們想要尋找哪些信息。

1、Web服務器名稱，版本

2、Web服務器后端是否有應用服務器

3、數據庫(DBMS)是否部署在同一主機(host)，數據庫類型

4、是否使用反向代理(reverse proxy)

5、是否使用負載均衡(load balancing)

6、Web應用使用的編程語言

2.2 手工檢測技巧

2.2.1 HTTP分析

使用chrome開發者工具或者burpsuite交互式抓包分析HTTP數據。

1、重點觀察 響應頭(Response Header)的 Server, X-Powered-By, Set-Cookie 字段。

2、使用畸形 Host字段的 HTTP請求試探，觀察響應頭。

比如 Struts2 的特征之一就是會設置特殊的JSESSIONID的cookie字段。

Set-Cookie: JSESSIONID=C09CBBF************7CF6D25D4F0

又或者以freebuf為例，你可以觀察到兩個有趣的字段，Server字段以及WP-Super-Cache。

Server字段說明 freebuf 的服務器版本是 Apache 2.2.21

WP-Super-Cache 字段則表明 freebuf 使用名為 WP Super Cache 的 WordPress 插件。

2.2.2 瀏覽網站

2.2.2.1 關注HTML源碼

重點關注以下幾處

1、上傳與下載功能

2、認證表單與URL(login,logout, reset password)

3、后臺管理頁面(administration section)

4、數據輸入點，例如”留言板，聯系我們，個人資料，商品評論，搜索，編輯器”等

觀察這些位置的HTML源碼(特殊的class名稱)及其注釋(comment)部分，可能暴露有價值信息。

2.2.2.2 根據網站頁面后綴判斷

通常而言

1、存在.php結尾的文件說明該web應用是用PHP寫的。

2、存在.jsp或者.do的文件，說明該web應用是由Java寫的。

3、存在.asp或者.aspx結尾的文件，說明該web應用可能是由VB或者C#寫的。

需要注意的是(低概率事件)，某些腦洞奇特的管理員/開發者/運維可能會將Java編寫的程序用.php的結尾，或者讓某些PHP應用使用.do結尾。

如果網站路徑存在 RESTful URL 的特征，例如

/objects/ # will give you a list of all the objects;
/objects/new # will give you the page to create a new object;
/objects/12 # will give you the object with the id 12;
/objects/12/edit # will give you the page to modify the object with the id 12;

則很有可能是由 Ruby On Rails 或者 Python 開發的。

2.2.2.3 favicon.ico

可以通過默認 favicon.ico 來判斷CMS，比如 Drupal 的默認icon是一個水滴狀的物體。在HTML源碼處搜索關鍵詞icon或者shortcut。

舉個例子：

<link href="/images/branding/product/ico/googleg_lodp.ico" rel="shortcut icon">
<link rel="icon" type="image/png" sizes="96x96" href="/favicon-96x96.png">
<link rel="shortcut icon" href="//res.wx.qq.com/a/wx_fed/webwx/res/static/img/3wOU-7F.ico" type="image/x-icon">

2.2.2.4 robots.txt

有些cms會有默認robots.txt，所以我們可以通過robots.txt來幫助判斷CMS。下面的是舉了一個Joomla的robots.txt例子。由于robots.txt只是君子協議，所以你懂的，在滲透測試時它完全在說明你應該檢查哪些目錄。

# If the Joomla site is installed within a folder# eg www.example.com/joomla/ then the robots.txt file
# MUST be moved to the site root
# eg www.example.com/robots.txt 
# AND the joomla folder name MUST be prefixed to all of the# paths.
# eg the Disallow rule for the /administrator/ folder MUST
# be changed to read# Disallow: /joomla/administrator/#
# For more information about the robots.txt standard, see:
# http://www.robotstxt.org/orig.html## For syntax checking, see:
# http://tool.motoricerca.info/robots-checker.phtml 

User-agent: *
Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /modules/
Disallow: /plugins/
Disallow: /tmp/

2.2.2.5 目錄掃描(directory/pages busting)

可以使用wfuzz進行目錄掃描。

python wfuzz.py -w wordlist/general/common.txt http://testphp.vulnweb.com/FUZZ

詳細的使用方法請參考

https://github.com/xmendez/wfuzz/wiki/Getting-started

無論用什么具體的目錄掃描工具，最終是為了發現某些404頁面, SQL錯誤頁面或者其他異常頁面，這些頁面暴露的信息可能可以反映服務器類型與版本。除此以外，對于多數網站的后臺管理頁面通常都屬于某些常用的路徑(即包含在字典中)，因此我們在大多數情況可以通過目錄掃描來獲得。如果已知CMS類型，可以直接參考文檔來判斷后臺默認管理頁面的路徑。

2.2.2.6 刻意構造錯誤

錯誤頁面可以給你提供關于服務器的大量信息?？梢酝ㄟ^構造含有隨機字符串的URL，并訪問它來嘗試得到404頁面。

Tomcat的默認404頁面

Ruby on Rails的默認404頁面

還有幾種方法可以構造錯誤。比如在URL中添加特殊字符%00(NULL),%27(Single Quote),%22(Double Quote)?；蛘咴赨RL中刪除部分參數，刪除部分cookie中的參數(chrome 插件 edit this cookie)。

不熟練的Django開發者可能會開啟調試模式

Tomcat 5XX的錯誤時可能拋出異常會顯示調用棧

對于PHP的應用，還有一個很常用的技巧來構造錯誤。比如將 /index.php?name=hacker 替代為 /index.php?name[]=hacker。

關鍵是要仔細閱讀這些錯誤信息。雖然這聽起來有點蠢，但是你肯定會驚訝于會有多少開發者認為兩個錯誤頁面是一樣的，即使是錯誤消息的內容完全不同。The evil is in the detail.

三、Web應用指紋特征總結

3.1 HTTP響應頭(HTTP response header) 特征

正則匹配HTTP響應頭中的特殊字段。

"headers": { "X-AMP-Version": "([\\d.]+)\\;version:\\1", "Set-Cookie": "^AMP=" },

3.2 HTML 特征

重點關注 body, title 等標簽的內容和屬性。

3.2.1 特殊的文本

比如在 HTML title 標簽中的Powered by EmpireCMS之類。

3.2.2 特殊的class

HTML 中存在特定 class 屬性的某些 div 標簽。

<body class="ke-content">

在上面的代碼中，ke-content 這個 class 通常是在 kindeditor 中出現的。

3.2.3 meta標簽特征

舉個例子

<meta name="version" content="neblog-1.0"/>

3.2.4 script標簽特征

<script src="http://www.freebuf.com/buf/themes/freebuf/js/bootstrap.min.js"></script>

主要用于判斷是否使用jQuery,Bootstrap等

3.3 URL 特征

3.3.1 URL路徑特征

比如 wordpress，有一些常見路徑。

readme.html
wp-content/uploads/
wp-admin...

3.3.2 默認錯誤頁面

通過爬蟲嘗試尋找網站中的錯誤頁面。例如 Apache 默認404，Oracle的默認SQL錯誤頁面等。

3.3.3 robots.txt

某些CMS會有默認的robots.txt。在robots.txt的文本中直接說明CMS名稱和版本。(Discuz, Joomla)

3.3.4 favicon.ico 等特殊文件匹配

下載 favicon.ico 圖像進行md5摘要，對比icon庫是否存在相同md5的icon。計算量更大但檢索效果更好的方法就是做相似圖像檢索(基于SIFT，或者其他圖像特征)。

除了 favicon.ico 以外，還有其他logo文件可以考慮，比如Dedecms的/img/buttom_logo.gif。

3.4 主機端口特征

3.4.1 默認端口特征

對于后端DBMS的識別，如果主機對外開放DBMS的話，可以通過端口特征判斷。尤其是在開放默認端口比如3306,1443,27017等。

3.4.2 端口交互特征

Socket交互過程中的一些特殊字符串。具體看參考資料2-0×03-5.Socket。

3.4.3 Nmap OS指紋

通過 Nmap OS指紋可以初步判斷操作系統。

3.4.4 SSL證書

SSL證書信息。

本文鏈接：http://www.sztqnet.com/article/1139.html