常見漏洞以及修復方法.doc

常見漏洞以及修復方法文:政府事業(yè)本部 第一事業(yè)部勞動人事開發(fā)部 劉世濤目錄(一)前言3(二)常見漏洞及原理分析31.sql腳本注入32.跨站點腳本編制33.不安全的HTTP方法及登錄驗證相關44.跨站點請求偽造45.危險性較低的開發(fā)及配置問題4(三)系統(tǒng)防御原理51.sql腳本注入52.跨站點腳本編制53.不安全的HTTP方法及登錄驗證相關64.跨站點請求偽造65.危險性較低的開發(fā)及配置問題6(四)結語7(一) 前言在做互聯(lián)網(wǎng)的項目中，由于網(wǎng)絡用戶數(shù)量大、環(huán)境更加復雜，對系統(tǒng)安全的考慮要更加慎重和全面。我在部門中參與了多個互聯(lián)網(wǎng)項目，以此為基礎，并結合IBM AppScan安全工具，介紹一下我們遇到的幾個安全方面的問題及其原理和解決方案。我們的項目使用的技術主要包括：spring、spring MVC、freemarker、hibernate。本文主要站在軟件系統(tǒng)的構建者和開發(fā)者的角度出發(fā)，類似網(wǎng)絡環(huán)境、服務器配置等，可以參考其他資料。(二) 常見漏洞及原理分析1. sql腳本注入后臺執(zhí)行sql語句時，使用字符串拼接的方式，并且該字符串是使用瀏覽器提交的數(shù)據(jù)時。攻擊者將提交的數(shù)據(jù)就行修改，可以達到執(zhí)行希望的sql的目的。該攻擊比較危險，可能會造成數(shù)據(jù)破壞和數(shù)據(jù)盜取的后果。例如：用戶提交username和password兩個字段，系統(tǒng)后臺判斷語句為String sql = “select * from user where name=”+username+” and password=”+password+”;后臺通過判斷查詢結果是否為空，來決定用戶的賬號和密碼是否正確。如果用戶將username的值寫為 admin or 1 or ，并且存在賬號名稱為admin的管理員用戶，則可以直接以admin登錄成功。以上例子只是很簡單的一種狀況，如果某些功能處理不好，有可能會造成大量數(shù)據(jù)被盜取的嚴重后果。2. 跨站點腳本編制攻擊者在瀏覽器向服務端提交的數(shù)據(jù)中，加入危險的內(nèi)容，如js腳本等。如果服務器端沒有響應的防御措施，則會被注入跨站腳本。典型的攻擊分為兩類：持久型：例如攻擊者在某博客內(nèi)留言，該留言內(nèi)容中嵌有一段獲取用戶賬號cookie的JS腳本。該博客被某個登錄用戶訪問時，腳本會在用戶未知的情況下運行，就會被盜取賬號等個人信息。非持久型：攻擊者在查詢的請求內(nèi)，使用URL參數(shù)的方式添加html語法內(nèi)容和非法js腳本，并且將該URL發(fā)送給登錄用戶。登陸用戶點擊連接之后，腳本會在用戶未知的情況下運行，就有可能被盜取賬號等個人信息。3. 不安全的HTTP方法及登錄驗證相關針對現(xiàn)有的常見漏洞進行解釋：1. 已解密的登錄請求、啟用了不安全的 HTTP 方法：如果沒有使用https協(xié)議，攻擊者可以在網(wǎng)絡層面對數(shù)據(jù)進行攔截。針對登錄、注冊等功能，賬戶等主要信息會被法攔截。2. 不充分帳戶封鎖：攻擊者可能會使用窮舉法對密碼進行暴力破解。3. 會話標識未更新：用戶在未登錄和登錄后的sessionid沒有進行更新，則攻擊者仿造一個帶有自定義的jsessionid參數(shù)的URL發(fā)送給被攻擊者，通常為登錄頁面，如果被攻擊者點擊鏈接之后，進行了登錄操作，jsessionid未更新，并且攻擊者擁有這個jsessionid，則可以使用這個sessionid作為攻擊者自身的信息，進入系統(tǒng)后，就擁有了被攻擊者的權限。4. 跨站點請求偽造在某個非法網(wǎng)站的頁面內(nèi)嵌入允許跨站點的標簽，例如js、img標簽。標簽的src屬性為某個操作的請求，例如轉(zhuǎn)賬、授權等等。當用戶在登錄被攻擊網(wǎng)站之后，如果訪問該非法頁面，則會自動向被攻擊網(wǎng)站發(fā)送一條請求，此時網(wǎng)站認為該請求是用戶本人的操作，攻擊成功。5. 危險性較低的開發(fā)及配置問題1. Bash Shell 歷史記錄文件檢索服務器配置2. Robots.txt 文件 Web 站點結構暴露3. 會話 cookie 中缺少 HttpOnly 屬性會話cookie沒有HttpOnly屬性，則在瀏覽器端可以使用js等手段進行修改4. 自動填寫未對密碼字段禁用的 HTML 屬性自動記錄密碼功能5. HTML 注釋敏感信息泄露注釋信息中含有某些關鍵字，如password等等6. 發(fā)現(xiàn)電子郵件地址模式注釋或代碼中存在郵件格式的信息，可能會有信息泄露7. 發(fā)現(xiàn)內(nèi)部 IP 泄露模式返回信息中，帶有內(nèi)部IP信息，可能會有信息泄露8. 客戶端（JavaScript）Cookie 引用瀏覽器端運行的js文件對cookie進行了引用，可能會被攻擊者利用。(三) 系統(tǒng)防御原理1. sql腳本注入要求所有的人員在開發(fā)過程中，杜絕食用字符串直接拼接sql語句的方式，而使用預編譯或命名參數(shù)的方式。例如：String sql = “select * from a where b=”+name+”; /name為瀏覽器請求的參數(shù)1. 預編譯的sql在jdbc中的體現(xiàn)為preparedstatement。查詢語句應為：select * from a where b=? ，時候使用preparedstatement.setXXX的方法進行變量設置。2. 命名參數(shù)在常用的orm框架中都有對應的方法，以spring的jdbctemplate為例：String sql =” select * from a where b=:name”;jdbctemplate.query(sql, new Objectname, )3. 通常使用hibernate等orm框架，使用其對應的java bean進行增刪改查操作都是安全的。 現(xiàn)在處理漏洞方法：使用過濾器來過濾非法字符，解決該漏洞！但是在程序開發(fā)中，請不要使用直接拼接sql語句！過濾器代碼：2. 跨站點腳本編制該漏洞的核心原因是未針對用戶提交的數(shù)據(jù)中含有html語義的內(nèi)容進行替換，從而造成用戶提交的數(shù)據(jù)可以被客戶端執(zhí)行造成的。解決辦法就是針對用戶提交的數(shù)據(jù)進行處理，將其中的特殊字符替換為用于顯示的html實體。例如：小于號（）替換為 <等等。如果你使用用于頁面展示的模板引擎，那恭喜你。這些模板引擎通常有自帶的處理方法，可以方便的將特殊子圖替換掉。如果沒有，那就需要自己進行替換，建議使用正則表達式，方便效率。下面以我們項目為例，介紹我的處理方法。1. 數(shù)據(jù)庫層面：添加系統(tǒng)級配置管理模塊，對系統(tǒng)庫表和字段進行配置。針對需要進行替換的數(shù)據(jù)庫表和字段，在管理模塊內(nèi)配置為需要替換。系統(tǒng)會在該字段被修改和保存時，通過hibernate攔截器。對數(shù)據(jù)內(nèi)的html語義字符替換為html實體，如小于號（）等。該操作可以防御危險性較高的持久型跨站點腳本攻擊。2. 頁面顯示層：添加系統(tǒng)級配置管理模塊，對用戶請求頁面進行配置。針對需要進行替換的頁面，將頁面動態(tài)顯示內(nèi)容（freemarker變量內(nèi)容，例如動態(tài)顯示的用戶名稱、展示數(shù)據(jù)等）進行替換，對數(shù)據(jù)內(nèi)的html語義字符替換為html實體。該操作可以防御所有的跨站點腳本攻擊。例如：攻擊者使用偽造請求數(shù)據(jù)的方法，提交了非法的js腳本，該請求數(shù)據(jù)在freemarker渲染頁面時，作為語句開發(fā)的 會被替換為 script 該內(nèi)容只會被作為普通文本進行解釋，而不會被瀏覽器作為腳本解釋。附：freemarker內(nèi)置處理方法：使用自定義TemplateLoader，在每個頁面載入時添加一行代碼這樣，所有的動態(tài)變量中的特殊字符都會被html實體替換。velocity也有類似的方法進行全局設置?，F(xiàn)在處理漏洞方法：使用過濾器來過濾非法字符，解決該漏洞！3. 不安全的HTTP方法及登錄驗證相關1. 已解密的登錄請求、啟用了不安全的 HTTP 方法：根據(jù)用戶的安全要求進行配置，根據(jù)項目情況安排2. 不充分帳戶封鎖：通常為進行測試，系統(tǒng)去掉了原有的驗證碼，出現(xiàn)了此漏洞。針對重要的請求，可以使用驗證碼，可以有效的防止暴力破解。根據(jù)用戶的安全要求，可以增加對登錄次數(shù)的限制。例如：如果連續(xù)登錄失敗10次，則一天之內(nèi)不允許再登錄。3. 會話標識未更新：用戶每次登陸成功之后，對用戶的相關標識進行更新。例如cookieid、jsessionid等。這樣，攻擊者無法獲取正確的會話標識。4. 跨站點請求偽造該漏洞屬于中級漏洞，常見網(wǎng)站往往不會進行處理。但是對于安全性要求較高的內(nèi)容，例如設計轉(zhuǎn)賬、重要的權限等，需要進行處理。防御方法：1. 針對安全要求高的請求，判斷請求的來源，對于來源非本站的請求進行處理。即request.getHeader(refer)；判斷來源頁面是否是本站內(nèi)部的頁面。可以防御簡單的跨站點請求偽造。但是，使用http客戶端軟件或者js腳本可以修改Header中的refer屬性，就要使用下面的方法了。2. 在系統(tǒng)內(nèi)設計一個算法，在生成請求頁面時，生成一個不規(guī)則的隨機碼。之后在用戶點擊這個頁面內(nèi)請求時，附帶這個隨機碼。之后再系統(tǒng)端對提交的隨機碼和下方的隨機碼進行比對，如果不符合，則說明該請求時偽造的。現(xiàn)在處理漏洞方法：使用過濾器來判斷request.getHeader(refer)是否是指定ip或者域名，解決該漏洞！5. 危險性較低的開發(fā)及配置問題1. Bash Shell 歷史記錄文件檢索修改服務器配置2. Robots.txt 文件 Web 站點結構暴露3.系統(tǒng)內(nèi)含有用于seo的robots.txt文件。但是robots文件只是一個聲明類的文件，并不能增加站內(nèi)敏感內(nèi)容的安全性。相反的是，如果在robots內(nèi)添加了敏感內(nèi)容結構的聲明，會將站點結構暴露給攻擊者。所以，使用robots文件要小心，該文件只是起到“防君子不防小人”的目的。例如之前某不良公司違反robots協(xié)議，造成用戶信息泄露的問題。4. 會話 cookie 中缺少 HttpOnly 屬性開發(fā)時針對cookie操作，添加httponly屬性，由于該方法屬于servlet3.0規(guī)范，根據(jù)項目要求配置。5. 自動填寫未對密碼字段禁用的 HTML 屬性開發(fā)時，針對password文本框添加autocomplete=off的屬性6. HTML 注釋敏感信息泄露要求開發(fā)中，避免在注釋內(nèi)出現(xiàn)危險的詞匯信息。但是有時使用的開源組件內(nèi)部會有此問題，需要衡量。7. 發(fā)現(xiàn)電子郵件地址模式要求開發(fā)中，避免出現(xiàn)危險的email信息。但是有時使用的開源組件內(nèi)部會有此問題，需要衡量。8. 發(fā)現(xiàn)