http://wiki.open.qq.com/wiki/Web%E6%BC%8F%E6%B4%9E%E6%A3%80%E6%B5%8B%E5%8F%8A%E4%BF%AE%E5%A4%8D
目錄[隱藏] |
1. 注入漏洞
1.1 SQL注入漏洞
名稱： SQL注入漏洞（SQL Injection）
描述：Web程序代碼中對於用戶提交的參數未做過濾就直接放到SQL語句中執行，導致參數中的特殊字符打破了SQL語句原有邏輯，黑客可以利用該漏洞執行任意SQL語句。
檢測方法：通過修改參數來判斷是否存在漏洞。
修復方案：
1. 針對ASP.NET的防XSS庫，Microsoft有提供統一的方法，具體可以參見如下鏈接:http://www.cnblogs.com/hcmfys/archive/2008/07/11/1240809.html
2. 針對其它語言如下細分：
在代碼級對帶入SQL語句中的外部參數進行轉義或過濾：
（1）對於整數，判斷變量是否符合[0-9]的值；其他限定值，也可以進行合法性校驗
（2）對於字符串，對SQL語句特殊字符進行轉義(單引號轉成兩個單引號，雙引號轉成兩個雙引號)。關於這點，PHP有類似的轉義函數mysql_escape_string和mysql_real_escape_string。
建議：
（1）使用騰訊CMEM存儲方案；
（2)對與數據庫進行交互的用戶請求數據，要先做過濾，防止SQL注入。
1.2 XSS漏洞
名稱：XSS注入漏洞（Cross-site Scripting）
描述：Web程序代碼中把用戶提交的參數未做過濾就直接輸出到頁面，參數中的特殊字符打破了HTML頁面的原有邏輯，黑客可以利用該漏洞執行惡意HTML/JS代碼、構造蠕蟲傳播、篡改頁面實施釣魚攻擊等。
檢測方法：通過修改參數來判斷是否存在漏洞。
比如用戶輸入內容：’<u>a</u>”的時候，合法的顯示是： ’<u>a</u>” ，合法的顯示的源碼是：
而存在漏洞的頁面顯示卻是：’a”
源碼是：
修復方案：
1. 開發者應該嚴格按照openid和openkey的校驗規則判斷openid和openkey是否合法，且判斷其它參數的合法性，不合法不返回任何內容。
2. 嚴格限制URL參數輸入值的格式，不能包含不必要的特殊字符（ %0d、%0a、%0D 、%0A 等）。
3. 針對ASP.NET的防XSS庫，Microsoft有提供統一的庫，具體可以參見如下鏈接
微軟官網：http://msdn.microsoft.com/en-us/library/aa973813.aspx
4. 具體的js方法如下：
（1）對於用戶輸入的參數值展現在HTML正文中或者屬性值中的情況，例如：
展現在html正文中：<a href='http://www.contoso.com'>Un-trusted input</a>
展現在屬性值中：<input name="searchword" value="Un-trusted input">
此時需要將紅色的不可信內容中做如下的轉碼(即將< > ‘ “ ` 轉成html實體)：
（2）對於用戶輸入落在<script>的內容中的情況，例如:
<script type="text/javascript">
…
var mymsg="Un-trusted input";
var uin=Un-trusted input;
…
</script>
需要將紅色的不可信內容中做如下的轉碼: [a-zA-Z0-9.-_,]以及ASC值大於0x80之外的所有字符轉化爲\x**這種形式，例如：
1.3 命令注入漏洞
名稱：命令注入漏洞（Command Injection）
描述：Web程序代碼中把用戶提交的參數未做過濾就直接使用shell執行，攻擊者可以執行任意系統命令。
檢測方法：通過修改參數來判斷是否存在漏洞。
修復方案：在代碼級調用shell時，對命令行中的特殊字符進行轉義（|、&、；等），防止執行其他非法命令。
PHP中可使用escapeshellarg、escapeshellcmd來轉義。
1.4 HTTP響應頭注入漏洞
名稱：HTTP響應頭注入漏洞（HTTP-Response-Splitting，HTTP_header_injection）
描述：Web程序代碼中把用戶提交的參數未做過濾就直接輸出到HTTP響應頭中，攻擊者可以利用該漏洞來注入HTTP響應頭，可以造成xss攻擊、欺騙用戶下載惡意可執行文件等攻擊。
另外根據國際安全組織司acunetix統計，以下apache存在header injection漏洞：1.3.34/2.0.57/2.2.1。
檢測方法：通過修改參數來判斷是否存在漏洞。
比如國內某著名網站曾經出現過header注入漏洞，如下url：
http://www.YYYYYYYYY.com/YYYYWeb/jsp/website/agentInvoke.jsp?agentid=%0D%0AX-foo:%20bar
抓包時發現：
修復方案：
1. 在設置HTTP響應頭的代碼中，過濾回車換行（%0d%0a、%0D%0A)字符。
2. 不採用有漏洞版本的apache服務器，同時對參數做合法性校驗以及長度限制，謹慎的根據用戶所傳入參數做http返回包的header設置。
1.5 跳轉漏洞
名稱：跳轉漏洞
描述：Web程序直接跳轉到參數中的URL，或頁面引入任意的開發者URL。
檢測方法：修改參數中的合法URL爲非法URL。例如測試一下如下URL：
http://***.qq.com/cgi-bin/demo_es.cgi?backurl=http://www.***.com，看是否會跳轉到注入的http://www.***.com站點。
修復方案：在控制頁面轉向的地方校驗傳入的URL是否爲可信域名。
例如以下是一段校驗是否是騰訊域名的JS函數：
function VaildURL(sUrl)
{
return (/^(https?:\/\/)?[\w\-.]+\.(qq|paipai|soso|taotao)\.com($|\/|\\)/i).test(sUrl)||(/^[\w][\w\/\.\-_%]+$/i).test(sUrl)||(/^[\/\\][^\/\\]/i).test(sUrl) ? true : false;
}
1.6 XML注入漏洞
名稱：XML注入漏洞
描述：Web程序代碼中把用戶提交的參數未做過濾就直接輸出到XML中。
檢測方法：通過修改參數來判斷是否存在漏洞。
修復方案：在代碼級輸出時對XML特殊字符（“<”、“>”、“>]]”）進行轉義。
2. 信息泄漏漏洞
2.1 PHPInfo()信息泄漏漏洞
名稱：PHPInfo()信息泄漏漏洞
描述：Web站點的某些測試頁面可能會使用到PHP的phpinfo()函數，會輸出服務器的關鍵信息。如下圖所示：
檢測方法：訪問http://[ip]/test.php 以及http://[ip]/phpinfo.php看是否成功。
修復方案：刪除該PHP文件。
2.2 測試頁面泄漏在外網漏洞
名稱：測試頁面泄漏在外網漏洞
描述：一些測試頁面泄漏到外網，導致外界誤傳公司被黑客入侵。如下圖所示：
1. http://parts.baby.qzoneapp.com/
2. http://parts.baby.qzoneapp.com/test.php
3. http://other.baby.qzoneapp.com
檢測方法：檢測頁面內容，看是否是測試頁面。
修復方案：刪除測試頁面，例如test.cgi，phpinfo.php，info.pho， .svn/entries等。
2.3 備份文件泄漏在外網漏洞
名稱：備份文件泄漏在外網漏洞
描述：編輯器或者人員在編輯文件時，產生的臨時文件，如vim自動保存爲.swp後綴、UltrlEditor自動保存.bak後綴等，這些文件會泄漏源代碼或者敏感信息。如下圖所示：
泄漏源代碼可以讓黑客完全瞭解後臺開發語言、架構、配置信息等。下圖是國內某著名網站曾經出現過的源代碼泄漏漏洞：
檢測方法：在cgi文件後面添加.bak、.swp、.old、~等後綴探測。
修復方案：刪除備份文件。
2.4 版本管理工具文件信息泄漏漏洞
名稱：版本管理工具文件信息泄漏漏洞
描述：版本管理工具SVN和CVS會在所有目錄添加特殊文件，如果這些文件同步到Web目錄後就會泄漏路徑等信息。如下圖所示：
檢測方法：訪問http://[ip]/CVS/Entriesp 以及http://[ip]/.svn/entriesp看是否成功。
修復方案：刪除SVN各目錄下的.svn目錄；刪除CVS的CVS目錄。
2.5 HTTP認證泄漏漏洞
名稱：HTTP認證泄漏漏洞
描述：Web目錄開啓了HTTP Basic認證，但未做IP限制，導致攻擊者可以暴力破解帳號密碼。如下圖所示：
修復方案：限制IP訪問該目錄。
2.6 管理後臺泄漏漏洞
名稱：管理後臺泄漏漏洞
描述：管理後臺的帳號和密碼設計過於簡單，容易被猜測到，導致攻擊者可以暴力破解帳號密碼。如下圖所示：
修復方案：
1. 將管理後臺的服務綁定到內網ip上，禁止開放在外網。
2. 如果該管理後臺必須提供給外網訪問，則未登錄頁面不要顯示過多內容，防止敏感信息泄漏，登錄帳號需經過認證，且密碼設置規則儘量複雜，增加驗證碼，以防止暴力破解。
2.7 泄漏員工電子郵箱漏洞以及分機號碼
名稱：泄漏員工電子郵箱漏洞以及分機號碼
描述：泄漏員工內部電子郵箱以及分機號碼相當於泄漏了員工內部ID，可以爲黑客進行社會工程學攻擊提供有價值的材料，同時也爲黑客暴力破解後臺服務提供重要的帳號信息。
修復方案：刪除頁面註釋等地方中出現騰訊員工電子郵箱以及分機號碼的地方。
2.8 錯誤詳情泄漏漏洞
名稱：錯誤詳情泄漏漏洞
描述：頁面含有CGI處理錯誤的代碼級別的詳細信息，例如sql語句執行錯誤原因，php的錯誤行數等。
檢測方法：修改參數爲非法參數，看頁面返回的錯誤信息是否泄漏了過於詳細的代碼級別的信息。
修復方案：將錯誤信息對用戶透明化，在CGI處理錯誤後可以返回友好的提示語以及返回碼。但是不可以提示用戶出錯的代碼級別的詳細原因。
3. 請求僞造漏洞
3.1 CSRF漏洞
名稱：CSRF漏洞（Cross Site Request Forgery）
描述：用戶以當前身份瀏覽到flash或者開發者網站時，JS/flash可以迫使用戶瀏覽器向任意CGI發起請求，此請求包含用戶身份標識，CGI如無限制則會以用戶身份進行操作。
檢測方法：
1. 在實際的測試過程中，測試人員需要判斷操作是否爲保存類操作，是否強制爲POST方式傳輸參數。
判斷方式是通過抓包工具把所有的POST參數都改成GET方式提交。
需要注意的是，這種方法只可防止圖片跳轉式CSRF漏洞，如果頁面上有XSS漏洞話，CSRF無法防禦。
2. 最簡單的辦法就是查閱該cgi是否帶有無法預知的參數，例如隨機字符串等。
修復方案：可使用以下任意辦法防禦CSRF攻擊：
1. 在表單中添加form token（隱藏域中的隨機字符串）；
2. 請求referrer驗證；
3. 關鍵請求使用驗證碼。
3.2 JSON-hijackin漏洞
名稱：JSON-hijackin漏洞
描述：CGI以JSON形式輸出數據，黑客控制的開發者站點以CSRF手段強迫用戶瀏覽器請求CGI得到JSON數據，黑客可以獲取敏感信息。
檢測方法：
1. 檢查返回的json數據是否包含敏感信息，例如用戶ID，session key，郵箱地址，手機號碼，好友關係鏈等。
2. 確認提交是否帶有無法預知的參數，例如隨機字符串等。
修復方案：可使用以下任意辦法防禦JSON-hijackin攻擊：
1. 在請求中添加form token（隱藏域中的隨機字符串）；
2. 請求referrer驗證。
4. 權限控制漏洞
4.1 文件上傳漏洞
名稱：文件上傳漏洞
描述：接受文件上傳的Web程序未對文件類型和格式做合法性校驗，導致攻擊者可以上傳Webshell（.php、.jsp等）或者非期望格式的文件（.jpg後綴的HTML文件）
修復方案：文件上傳的CGI做到：
1. 上傳文件類型和格式校驗；
2. 上傳文件以二進制形式下載，不提供直接訪問。
4.2 crossdomain.xml配置不當漏洞
名稱：crossdomain.xml配置不當漏洞
描述：網站根目錄下的文件crossdomain.xml指明瞭遠程flash是否可以加載當前網站的資源（圖片、網頁內容、flash等）。
如果配置不當，可能帶來CSRF攻擊。如下圖所示：
檢測方法：
訪問http://[domain]/crossdomain.xml
修復方案：對於不需要外部加載資源的網站，crossdomain.xml中更改allow-access-from的domain屬性爲域名白名單。
修復大致樣本參考如下（備註：示例中的app10000.qzoneapp.com,app10000.imgcache.qzoneapp.com請修改爲自己指定的站點）：
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from secure="false" domain="*.qq.com"/>
<allow-access-from secure="false" domain="*.soso.com"/>
<allow-access-from secure="false" domain="*.paipai.com"/>
<allow-access-from secure="false" domain="*.gtimg.cn"/>
<allow-access-from secure="false" domain="*.pengyou.com"/>
<allow-access-from secure="false" domain="app10000.qzoneapp.com"/>
<allow-access-from secure="false" domain="app10000.imgcache.qzoneapp.com"/>
</cross-domain-policy>
4.3 flash標籤配置不當漏洞
名稱：flash標籤配置不當漏洞
描述：網頁在引入flash的時候，會通過object/embed標籤，在設置的時候，如果一些屬性配置不當，會帶來安全問題：
1. allowScriptAccess：是否允許flash訪問瀏覽器腳本。如果不對不信任的flash限制，默認會允許調用瀏覽器腳本，產生XSS漏洞。
always（默認值），總是允許；sameDomain，同域允許；never，不允許
2. allowNetworking：是否允許flash訪問ActionScript中的網絡API。如果不對不信任的flash限制，會帶來flash彈窗、CSRF等問題。
all，允許所有功能，會帶來flash彈窗危害；internal，可以向外發送請求/加載網頁；none，無法進行任何網絡相關動作（業務正常功能可能無法使用）
修復方案：對於不信任flash源，allowScriptAccess設置爲never，allowNetworking設置爲none（業務需要可以放寬爲internal）。
4.4 embed標籤配置不當漏洞
名稱：embed標籤配置不當漏洞
描述：網頁會通過embed標籤引入媒體文件（如rm、avi等視頻音頻），這些媒體文件中如有腳本指令（彈窗/跳轉），如果沒有限制就會出現安全問題。
檢測方法：檢查embed標籤中是否有invokes標籤。
修復方案：添加屬性invokes值爲-1。
4.5 併發漏洞
名稱：併發漏洞
描述：攻擊者通過併發http/tcp請求而達到次獲獎、多次收穫、多次獲贈等非正常邏輯所能觸發的效果。
下面以簡化的例子說明在交易的Web應用程序中潛在的並行問題，並涉及聯合儲蓄帳戶中的兩個用戶（線程）都登錄到同一帳戶試圖轉賬的情況：
帳戶A有100存款，帳戶B有100存款。用戶1和用戶2都希望從帳戶A轉10分到帳戶B.
如果是正確的交易的結果應該是：帳戶A 80分，帳戶B 120分。
然而由於併發性的問題，可以得到下面的結果：
用戶1檢查帳戶A （ = 100 分）
用戶2檢查帳戶A （ = 100 分）
用戶2需要從帳戶A 拿取10 分（ = 90 分） ，並把它放在帳戶B （ = 110 分）
用戶1需要從帳戶A 拿取10分（仍然認爲含有100 個分）（ = 90 分） ，並把它放到B（ = 120 分）
結果：帳戶A 90 分，帳戶B 120 分。
檢測方法：發送併發http/tcp請求，查看併發前後CGI 功能是否正常。例如：併發前先統計好數據，併發後再統計數據，檢查2次數據是否合理。
修復方案：對數據庫操作加鎖。
4.6 Cookie安全性漏洞
名稱：Cookie安全性漏洞
描述：cookie的屬性設置不當可能會造成其他SNS遊戲的運行出錯等安全隱患。
檢測方法：抓取數據包查看cookie的domain屬性設定是否合理。
修復方案：對cookie字段的domain屬性做嚴格的設定，openkey以及openid的domain只能設置到子域，禁止設置到父域qzoneapp.com。如下圖所示：
4.7 Frame-proxy攻擊漏洞
名稱：Frame-proxy攻擊漏洞
描述：在一些老版本瀏覽器（比如IE6）下，Frame-proxy攻擊可以把非常駐XSS漏洞以常駐型的方式做攻擊。
修復方案：qzoneapp.com域名下的應用不能再通過iframe嵌入qq.com域名下頁面。
原理如下圖所示，假設域名xiaoyou.qq.com底下沒有任何xss漏洞，然後xiaoyou.qq.com通過iframe嵌入了一個xxx.qzoneapp.com域名。
假設qq.com的某個子域vul.qq.com存在一個非常駐的xss漏洞，那麼當xxx.qzoneapp.com通過iframe嵌入vul.qq.com時，訪問xiaoyou.qq.com域名的用戶將受到常駐型XSS漏洞的攻擊。
