旁註攻擊即攻擊者在攻擊目標時，對目標網站“無從下手”，找不到漏洞時，攻擊者就可能會通過具有同一伺服器的網站滲透到目標網站，從而獲取目標站點的許可權。這一過程就是旁註攻擊的過程。

旁註攻擊並不屬於目標站點程式的漏洞，而是來自“外部”的攻擊。另外，攻擊者在進行旁註操作時，一般都會與提權技術結合在一起，旁註與提權是密不可分的。

13.1 伺服器端Web 架構

旁註攻擊多數發生在中小型網站中，因為直接購買伺服器的價格比較昂貴，對中小型站點不合適，例如，個人部落格、小型論壇、新聞釋出站點一般都會選擇購買網站空間、VPS 或與他人合租伺服器減少開銷，這樣比較合適。但這樣一來， 自己的網站就很可能會與他人的網站放置於同一伺服器。另外，一些企業使用者也可能將OA、官方網站等系統放置於同一伺服器。

這樣就會出現一個問題：當目標網站設計得非常安全時，攻擊者就可以對具有同一伺服器的網站進行滲透，直至滲透到目標網站為止。你可以保證自己的網站是比較安全的，但是你能保證同一伺服器上所有的網站都是安全的嗎？在剖析旁註攻擊之前，我們首先需要對伺服器Web 應用程式架構有一個清楚的認識。一個伺服器可能存在多個網站或多個資料庫。例如，若服域器存在“xxser.com”、“secbug.org”與“moonsos.com”，Web 應用程式分別存放在D 盤的“xxser”、 “secbug”、“moonsos"目錄中。其中，“xxser.com"與“secbug.org"使用MySQL 資料庫，資料庫名稱為“xxser” 與“secbug"，“moonsos.com”則使用SQL Server資料庫，庫名為“moonsos"，當攻擊者在攻擊“xxser.com”時，並未發現風險，但通過攻擊“secbug.org” 得到了資料庫的root許可權，
這樣“xxser.com”"的資料可能會被洩露，因為它使用的也是MySQL資料庫，而“moonsos.com” 卻不會受影響，因為它們並不位於同一個資料庫。但同樣不再安全，攻擊者可能通過資料庫提權的方式獲取伺服器的管理員許可權。

大型網站也存在旁註攻擊的風險，比如:“ secbug.org"有很多子域名，每個子域名都對應不同的Web 應用程式。例如:“www.secbug.org”、 “bbs. secbug.org”和“vip. secbug.org”。所以說，只要目標網站伺服器存在其他網站，都有可能會被旁註攻擊，大型網站也不例外。

13.2 IP 逆向查詢

通過前面章節的學習可知：攻擊者可能會通過同伺服器的網站滲透目標網站。那麼攻擊者如何知道伺服器上放置了哪些網站呢？

我們無法直接準確地獲取伺服器有多少個網站(除非你是這臺伺服器的管理人員)，但可以模糊地查詢出伺服器上部署了哪些網站。許多網站都提供了基於IP 到網站的逆向查詢功能，通過這類網站攻擊者可以查詢到部署在同一Web 伺服器上的網站，如“http://www.yougetsignal.com/tools/web-sites-on-web-server/"就提供了反向查詢功能，如下圖所示：

可以看到，“www.baidu.com” 的伺服器IP 為“104.193.88.77”， 並且在這臺伺服器上部署了10個網站。雖然此時查詢出了10個，但並不能保證所有的網站都查出來了。

下面是常見的IP 反查網站：

http://tool.chinaz.com/Same/
http://dns.aizhan.com/
http://www.114best.com/ip/

很多讀者可能有疑問：上述系統怎麼知道同一伺服器有哪些網站呢？其實很多系統都呼叫了搜尋引擎的介面來抓取，伺服器IP 通過呼叫介面，可以獲得同一伺服器的網站域名，而很多網站只是將網站的域名擷取出來，讓使用者更方便。

13.3 SQL跨庫查詢

SQL旁註即為跨庫查詢攻擊，是管理員沒有分配好資料庫使用者許可權所導致的問題。

通常，在一個資料庫中會有多名使用者，使用者之間互不干擾，但如果許可權分配不當，使用者之間就可能存在越權操作。比如，某臺伺服器中安裝了MySQL資料庫，A使用者和B使用者都為當前MySQL資料庫中的使用者，A使用者所對應的資料庫為ADB，B使用者所對應的資料庫為BDB，如果A使用者可以操作B使用者所對應的資料，那麼這就屬於越權操作，也被攻擊者稱為跨庫查詢。

在伺服器中存在網站“http//www.xxser.com"與http://www.secbug.org”, 攻擊者的目標為“www.xxser.com”，但“www.xxser.com”設計得非常安全,那麼攻擊者就可能利用“www.secbug.org”對“www.xxser.com"實施攻擊。下面是一個簡單的SQL跨庫查詢的例子。

URL“HTTP://www.secbug.org/user/ogin.php"存在注入漏洞，攔截後的HTTP請求為：

POST /user/login.php HTTP/1.1
Host: wWw. secbug .org
Content-Length: 53
Origin: http:/ /www .secbug.org
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko)
Content- Type: application/x-ww- form-urlencoded
Accept-Language: zh-CN, zh;q=0.8
Cookie:_ jkb_ 10667=1
use rname= admi n&password=123456& sub= 8E7899%BB8E9899886

將HTTP請求儲存為secbug.txt，並且使用SQLMap“-r”與“-dbs”引數注入，結果如下：

available databases [9] :
[*] dedecmsv57gbksp1
[*] dvwa
[*] hacker
[*] information_ schema
[*] secbug
[*] mysq1
[*] test
[*] wordpress
[*] xxser

我們可以看到SQLMap 列出了所有的資料庫，因為此時的使用者許可權比較大，可以通過“www.secbug.org”的注入點進行跨庫查詢。

像SQL Server、MySQL、 Oracle 等資料庫，如果資料庫許可權設定不當，只要伺服器任意一個Web 應用程式存在SQL 注入漏洞，那麼整個伺服器的資料都將可能被“拖庫”，所有的網站也都可能被入侵。

在分配使用者許可權時，一定要保持一個原則：許可權最小原則。即所分配的許可權在不干擾程式執行的情況下，分配最小的許可權。

13.4 目錄越權

在之前我們瞭解過，正常情況下，每個Web 應用程式都存在於一個單獨的目錄中，各程式之間互不干擾，獨立執行。但伺服器管理員配置不當時，就會發生目錄越權的風險。

使用者A 的網站為“www.xxser.com”"，應用程式放在“d:xxser\”目錄中，此時正確的做法應該是將“www.xxser.com”所對應的程式限制在“d:xxser"目錄中操作，不應該有其他目錄的讀寫許可權。

伺服器上的網站分別有“www.xxser.com”、“wwwshuijiao8.com”與“ www.2cto.com”，攻擊者已經獲取了“www.shuijjao8.com"網站許可權，並且已經上傳Shell，如果目錄許可權未分配好，那麼攻擊者就可以直接進行目錄越權，將Shell 寫入“www.xxser.com”與“www.2cto.com” 網站中。目錄越權之後，伺服器上的所有網站都可能面臨被入侵的風險，甚至伺服器也可能被提權，因為攻擊者可以通過目錄越權漏洞進一步瞭解伺服器的架構，掌握敏感資訊，為下一步的提權
做準備。

有些讀者可能會有疑惑：如果目錄只有讀許可權，沒有寫入許可權，也會有風險嗎？答案是肯定的。試想，如果攻擊者已經得到了目標網站的管理員賬戶資訊，卻找不到後臺登入地址，此時如果攻擊者攻陷了同一伺服器的另一個網站，剛好擁有讀取目錄的許可權，那麼攻擊者就可以跳轉到目標網站程式的目錄，找到後臺登入地址，這樣就可以繼續對目標網站進行滲透。

有時一些低危漏洞可能並沒有直接的危害或風險，但是一旦與其他漏洞相結合，就可能產生巨大風險，變為高危漏洞。所以，我們應儘可能地讓“大堤沒有蟻穴”，無論是高危漏洞還是低危漏洞，都應一視同仁。

13.5 構造注入點

有些情況下，攻擊者入侵了同一伺服器的網站，但是目錄許可權做得比較嚴格，攻擊者無法進行“跨站”操作，這時如果資料庫許可權大。那麼攻擊者是不是可以通過資料庫來跨目錄讀寫檔案呢？沒錯，的確可以這樣。但有時候攻擊者滲透網站時，網站本身並不存在注入點，而是利用其他漏洞獲取的許可權，怎麼辦？這時，攻擊者一般會根據相應的指令碼語言來構造一個注入點，然後使用工具輔助完成後續任務。

構造注入點比較簡單，攻擊者最主要的是得到資料庫的賬戶資訊，然後使用指令碼連線。構造完成的注入點可以直接放到SQLMap 或其他注入工具中，這樣省去了手動寫SQL 語旬的步驟。不要小看構造注入點，例如，SQL Server注入點如果是DB_ Owner 許可權，就可以進行資料備份，可以將Shell 備份到指定的目錄，如果許可權足夠大，就可以提權。

通過這個例子，讀者或許對安全有一個更清晰的認識：安全是整體的，出問題的有時候不僅限於程式設計師的程式碼。

13.6 CDN

說到旁註攻擊，就不得不提起CDN，伺服器使用CDN 之後，真實的IP 將會隱藏起來，攻擊者無法找到目標主機的IP ，也就無法進行旁註攻擊。

CDN 的全稱是Content Delivery Network，即內容分發網路。其基本思路是：儘可能地避開網際網路上有可能影響資料傳輸速度和穩定性的瓶頸、環節，使內容的傳輸速度更快、更穩定。

例如，一個企業的網站伺服器在北京，運營商是電信，在廣東的聯通使用者訪問企業網站時，因為跨地區、跨運營商的原因，網站開啟速度就會比北京當地的電信使用者訪問速度慢很多，這樣就很容易造成企業客戶流失。

又如，一個網站的伺服器效能比較差，承載能力有限，有時面臨突發流量招架不住，伺服器可能直接崩潰，尤其是在節日期間的電商網站，因訪問量暴漲而崩潰，使銷售額大幅度降低。

再如，一些中小企業租用的虛擬主機因為與很多網站共用一臺伺服器，而每個網站所分的頻寬有限，當訪問流量增多時，頻寬過小的網站開啟速度就會很慢，甚至沒有被攻擊就已經打不開了。

使用CDN之後的效果如下：

• ① 不用擔心自己網站的訪客，任何時間、任何地點和任何網路運營商都能快速開啟網站。
• ② 各種伺服器虛擬主機頻寬等採購成本(包括後期運營成本)都會大大減少。
• ③ 有效防禦SYN Flood、UDP Flood、ICMP Flood、CC 等常見的DDoS 攻擊等，CDN 有一套自己的安全處理機制。
• ④ 可以阻止大部分的Web 攻擊，例如SQL 注入、XSS 跨站等漏洞。

根據前面所講述的CDN 知識，可以得知CDN 最終目的是用來加速的，那麼CDN 如何加速呢？簡單地說，CDN 就是將原伺服器上可以快取的檔案(靜態檔案、圖片、JS、 CSS等)下載到快取伺服器，當使用者在訪問你的域名時，將會訪問快取伺服器，而不是直接去訪問源伺服器。

假設你的伺服器在北京，全國各地的使用者都會訪問北京的伺服器，但如果你使用了CDN，並在全國各地區都有CDN 節點伺服器，那麼各地區使用者在訪問網站時將不會訪問北京的伺服器，而是訪問各地區的CND 節點伺服器。這樣巨大的流量就被CDN 伺服器分散了，源伺服器的壓力自然就沒有那麼大了。

在國內訪問量較高的大型網站如新浪、網易等，均使用了CDN 網路加速技術，雖然網站的訪問量巨大，但無論在什麼地方訪問都會感覺速度很快，原因就是這樣。CDN 流程如下：

使用者提交域名
↓
瀏覽器對域名進行解析
↓
得到CDN 快取地址 
↓
根據IP 地址發出訪問請求
↓
快取伺服器內部DNS 得到真實的主機地址
↓
向真實IP 請求，並把請求返回客戶端
↓
客戶端/瀏覽器得到響應並回顯          

既然IP 已經被隱藏，那麼攻擊者在進行旁註攻擊時，不知道伺服器真正的IP 肯定是無從下手的。

像安全寶、加速樂等網際網路廠商，都提供了免費的CDN 供使用者使用，有興趣的讀者可以嘗試。

CDN 雖好，但它也有缺點，如: 攻擊者也可以直接攻擊CDN 節點造成網站無法訪問的現象。另外，攻擊者也有一些辦法可以獲取到其真實的IP。下面是一些常見的蒐集真實IP的方法。

• (1)phpinfo()

phpinfo()是PHP 中的一個函式， 這個函式可以顯示伺服器端的一些配置資訊，其中包括伺服器端的IP 地址，但這裡並不僅指phpinfo()函式，像ASP、JSP、ASP.NET 都有類似的函式、方法，方便開發者檢視伺服器配置資訊。如果伺服器存在類似於這樣的頁面，並被攻擊者得知,那麼攻擊者將可以從該頁面得到伺服器的真實IP。

• (2)子域名

很多網站一般都會對“www.xxx.com"使用CDN技術加速，而忽略一些子域名，這樣這些子域名就極有可能與主站存放在一臺伺服器中，攻擊者可能會通過蒐集網站的子域名，尋找“漏網之魚”。然後只需要利用“ping”命令，即可得到伺服器端的真實IP地址。例如，“ping xx.com”、“ping bs.xxx.com"、“ping book.xxx.com"等。

• (3)觀察IP變化

有些網站提供了檢視域名伺服器IP地址變化的功能，通過IP地址變化，我們可能猜測出伺服器的真實IP地址。如“http:/toolbar.netcraft.com/”。

我們不能把自身的安全交給CDN 來全權處理，或者說是過分依賴CDN，只有將自身的問題完全解決，才是真正的防禦之道。

13.7 小結

本章講述了攻擊者是如何實施旁註攻擊的，並且剖析了一些攻擊者在實施旁註攻擊時所用的手段和技巧。

旁註攻擊在很多時候都發生在一些小網站上。小網站一般都是租用空間或者用VPS，安全問題都交給了伺服器提供商去處理，特別是一些VPS 或者合租的伺服器，旁註都非常太簡單。因為站長們根本就不知道如何去防範提權、旁註等攻擊。

受到旁註攻擊時，我們並沒有特別好的防禦辦法，只能保證自己的網站安全，但能保證其他網站也是安全的嗎？所以，要防禦旁註攻擊，只能對伺服器許可權做嚴格的配置，詳細內容請參照第14章"提權”。