web安全-剖析_基礎構架剖析

時間 2020-06-06

標籤 web 安全剖析基礎構架欄目 HTML 简体版

原文原文鏈接

剖析是用於研究和精確描述網站結構和應用工做方式的策略，是一個很是重要卻常被忽視的Web入侵方向.html

基礎架構的支持：Web服務器，硬件/軟件，DNS項目，網絡設備，負載平衡器等.前端

1、介紹nginx

2、基本的標誌獲取web

3、高級HTTP指紋識別數據庫

4、基礎構架中介apache

1、介紹後端

　　1.足跡法(Footprinting)-使用各類基於互聯網的研究方法肯定目標應用或組織的範圍.傳統上有許多工具和技術用於這項任務:安全

　　　　a.互聯網註冊研究服務器

　　　　b.DNS詢問cookie

　　　　c.整體組織研究

　　2.基本基礎架構偵察技術，如：

　　　　a.服務器發現(Ping掃描)　

　　　　b.網絡服務識別(端口掃描)

　　3.公認端口HTTP的TCP 80 以及/或用於HTTPS/SSL/TLS的TCP 443操做.

　　提示:不要忽視端口掃描，許多web應用經過運行於Web服務器或者其餘DMZ中與Web應用服務器相鄰的服務器上的不恰當服務遭到入侵.

2、基本的標誌獲取

　　標誌獲取(Banner grabbing), 識別運行中的Web服務器軟件的類型和型號(版本).

[root@localhost netcat-0.7.1]# nc 210.14.147.222 80
HEAD / HTTP/1.0

HTTP/1.1 403 Forbidden
Server: nginx/1.6.0
Date: Sun, 27 Sep 2015 13:58:34 GMT
Content-Type: text/html
Content-Length: 168
Connection: close

3、高級HTTP指紋識別

　　跟高級的標誌獲取技術已經獲取，可以肯定真正運行的Web服務器。將針對HTTP的標誌獲取稱爲Web服務器指紋識別(Fingerprinting),他再也不只是簡單地關注部首值，還觀察各類服務其中每一個Web服務器中每一個Web服務器的整體表現以及其響應的獨特性.例如：IIS服務器對無效的HTTP請求的響應和可能不一樣於Apache Web服務器.這是肯定實際運行的Web服務器類型和型號的好方法，也是學習Web服務器之間細微差異的重要之處.還有許多其餘方法.

　　1.意外的HTTP方法.不一樣web服務器對不一樣類型的請求作出的不一樣反應：(其中已用粗體標出)

Sun One Web Server                      IIS5.x
$ nc  sun.site.com 80                    $ nc iis5.site.com 80
PUT / HTTP/1.0                           PUT / HTTP/1.0
Host:sun.site.com                        Host:iis5.site.com

HTTP/1.1 401 Unauthorized             　 HTTP/1.1 403 Forbidden
Server: Sun-ONE-Web-Server/6.1    　　　　Server:Microsoft-IIS/5.1 IIS 6.0                                  Apache 2.0.x
$ nc iis6.site.com 80                    $nc apache.site.com 80
PUT / HTTP/1.0                           PUT / HTTP/1.0
Host:iist6.site.com                      Host:apache.site.com

HTTP/1.1 411 Length Required　　　　　　　 HTTP/1.1 405 Method Not Allowed
Server:Microsoft-IIS/6.0                 Server:Apache/2.0.54
Content-Type:text/html

　　2.服務器首部異常

　　例如：在Apache 2.x中，Date:部首在最前面，在Server:首部之上,以下：

HTTP/1.1 200 OK
Cache-Control: private, max-age=0, no-cache
Content-Length: 43
Content-Type: image/gif
Date: Sun, 27 Sep 2015 14:20:01 GMT
Pragma: no-cache
Server: apache
X-Content-Type-Options: nosniff

　　又例如：在nginx中，Server:部首在最前面，在Date:部首之上.

HTTP/1.1 304 Not Modified
Server: nginx
Date: Sun, 27 Sep 2015 14:20:00 GMT
Connection: keep-alive
Last-Modified: Tue, 06 Nov 2012 02:01:10 GMT
ETag: "50986f66-2d1a"
Expires: Sun, 27 Sep 2015 14:35:01 GMT
Cache-Control: max-age=900

　　再例如，在Sun One上，Server:和Date:首部的順序與IIS 5.1相同，但注意，Content-length中，」length「是小寫。Content-type:也同樣,而IIS5.1中，這些部首都以大寫開頭:

HTTP/1.1 200 OK
Server: Sun-One-Web-Server/6.1
Date: Mon,22 Aug 2005 20:33:36 GMT
Content-length:2628
Content-type:text/html
Last-modified:Tue,01 Apr 2003 20:47:57 GMT
Accept-ranges:bytes
Connection:close

　　3.Httprint工具

　　　　a.Net-Square的Httprint工具.帶有一個可定製的web服務器特徵碼數據庫.

　　　　b.SHODAN,一個搜索引擎，搜索的對象是可以對信息安全產生影響的計算機(路由，服務器等.),互聯網的大部分區域都已經爲SHODAN索引,能夠簡單的識別，

　　　　　　.gov域中的全部IIS服務器.

　　　　　　瑞士的全部的Apache服務器.

　　　　　　全部具備特定Web服務器平臺已知漏洞的系統的IP地址

4、基礎構架中介

　　包括，負載均衡器，虛擬服務器配置，代理和Web應用防火牆.

　　A.虛擬服務器.在一臺機器上運行多個虛擬IP的服務器.

　　B.檢測負載平衡器，通常不可見，許多攻擊者進行評估的時候忽略了它們，但負載平衡器可能極大地改變評估的方式.平衡器用來確保單個服務器的請求不會超載，用來分割流量.

　　C.對鄰近IP範圍進行端口掃描，識別負載平衡器的一種簡單方法是，首先肯定公認服務器IP地址，而後編寫腳本對周圍IP範圍發出請求.若是獲得多個幾乎相同的響應,這可能都是負載平衡器的相同Web服務器.偶爾也會碰到一個或者幾個服務器和其餘有所不一樣。如軟件版本過期，或者替代的SSH和FTP，這些異常多是某種服務安全配置錯誤，能夠針對IP地址單獨發起攻擊.

　　D.時間戳分析,檢測負載平衡器的一個方法就是分析響應時間戳，由於許多服務器沒有同步時間，能夠經過在一秒內發出多個請求來肯定是否有多臺服務器.

　　E.ETag和Last-Modified的差別:經過比較相同請求資源的首部響應中的ETag和Last-Modified值，肯定是否會從多個服務器上獲得不一樣的文件.

ETag: "20095-2de2-3fdf365353cc0"
ETag: "6ac117-2c5e-3eb9ddfaa3a40"
Last_Modified: Sun, 19 Dec 2004 20:30:25 GMT
Last_Modified: Sun, 19 Dec 2004 20:31:12 GMT

　　上面時間戳的差別代表服務器沒有當即複製，請求的資源在大約1分鐘以後才複製到其餘服務器.

　　F.負載平衡器Cookie:有些代理服務器和負載平衡器在HTTP會話中添加本身的Cookie，以便它們能夠保持更好的狀態.

　　　　eg:AA002=1131030950-54332355234/12343234

　　　　通過搜索AA002是一個跟蹤Cookie，表示"Avenue A"

　　G.枚舉SSL異常:看看網站的SSL證書是否存在差別，或者SSL證書是否都支持相同的密碼長度.

　　H.檢查HTML源碼:相同的頁面的屢次請求可能返回不一樣的HTML源代碼註釋.

　　I.檢測代理：

　　　　IRACE請求：TRACE請求通知Web服務器回覆剛剛收到的請求內容.在HTTP/1.1中做爲調試工具.代理服務器將修改請求而且將其發送給Web服務器，代理服務器接着傳回收到的請求.這樣就能發現代理服務器對請求的修改.eg:

"Via:","x-Forwarded-For:","Proxy-Connection:"
HTTP/1.0 200 OK 
Access-Control-Allow-Origin: * 
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, TRACE, HEAD, CONNECT 
Access-Control-Allow-Headers: authorization 
Access-Control-Max-Age: 3628800 
Content-Type: text/html 
Date: Fri, 05 Dec 2014 21:35:45 GMT 
Cache-Control: no-cache,must-revalidate 
Expires: Thu, 26 Oct 1995 00:00:00 GMT 
Transfer-Encoding: chunked 
Server: Allegro-Software-RomPager/5.10b1 
Via: 1.1 192.168.1.5

　　　　反向代理是一個前端代理，未來自互聯網的入站請求路由到後端服務器，其中兩種修改方式：（1）將從新映射URL指向內部服務器上的相應URL。例如，TRACE /index.aspx HTTP/1.1 可能改成TRACE /site1/folder/index.asp HTTP/1.1 （2）反向代理修改Host：首部指向相關的內部服務器來轉發請求.

　　J.標準鏈接測試:CONNECT命令主要用於代理服務器代理SSL鏈接.代理表明客戶端創建一個SSL鏈接，例如：CONNECT https://secure.site.com:443 ，將通知代理服務器創建一個指向secure.site.com 443端口的SSL鏈接.但這個命可能會被濫用，用於鏈接網絡內部的服務器.

*Request*
CONNECT remote-webserver:80 HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
Host: remote-webserver
*Successful Response*
HTTP/1.1 200 Connection established

　　可用的一種較好的技術是識別目標的內部IP地址範圍，而後對者一範圍進行端口掃描.

　　K.檢測Web應用防火牆:能夠看做Web應用入侵防護系統(IPS)

　　　　若是在測試中你老是被踢出來，或者在發送攻擊請求時超時，那麼極可能在你和應用之間有一個應用防火牆.另外一個跡象是，始終返回相同類型的錯誤.

　　　　一些常見的Web應用防火牆和一些很是簡單的檢測方法》

　　　　》Teros：該防火牆將對簡單的TRACE請求或者任何無效的HTTP請求響應以下錯誤：

TRACE / HTTP/1.0
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

HTTP/1.0 500
Content-Type:text/html
<html><head><title>Error</title></head><body>
<h2>ERROR:500</h2>
Invalid method code<br>
</body></html>

　　　　檢測的Teros的另外一種方法是定位它發出的cookie .like this : st8id=1aeaadf13asdf243sd233435k33c3s.00.d4512ad323342sdf) 大部分狀況下cookie的值將具備相似的字符集和長度.

　　　　》F5 Trafficshield：

　　　　　　發送一個沒有數據的PUT方法.將出現以下錯誤:

PUT / HTTP/1.0
Host:www.site.com
User-Agent:Mozilla/4.0 (compatible;MSIE 5.01;Windows NT 5.0)

HTTP/1.0 400 Bad Request
Content-Type:text/html
<html><head><title>Error</title></head>
<body><h1>HTTP Error 400 </h1>
<h2>400 Bad Request</h2>
The server could not understand your request.<br>Your error ID is :5fa97729</body></html>

　　　　TrafficShield也有一個專用的標準Cookie：ASINFO

　　　　》Netcontinuum：

　　　　　　該防火牆的Cookie爲NCI_SessionId。而且該設備對全部無效請求都響應一個404錯誤.

　　　　》URLScan：

　　　　　　這是一個免費的ISAPI過濾器，爲控制HTTP請求提供了不少靈活工具。這類產品不提供動態保護，而是依賴冗長的特徵代碼配置文件或者容許長度文件配置來阻止攻擊.

　　　　　　默認規則下,若是發送一個超過260個字符的路徑，URLScan將響應一個404錯誤.但若是田間如下任何一個部首，URLScan將拒絕該請求：

　　　　　　　　Translate：

　　　　　　　　IF:

　　　　　　　　Lock-Token：

　　　　　　　　Transfer-Encoding：

　　　　　　以上部首將致使URLscan返回404錯誤.

　　　　》SecureIIS：