|
以工作中某項目的安全改善過程為例，分享了常用網(wǎng)站安 全性的典型問題和解決對策,，希望對網(wǎng)站開發(fā)者有借鑒意義,。
有過網(wǎng)站開發(fā)經(jīng)驗的朋友都知道網(wǎng)站安全是構(gòu)建網(wǎng)站時必 須要考慮的一個因素，網(wǎng)站安全的重點在于服務器的安全配置管理以及程序腳本的完善性,。值得注意的是,，如果服務器的賬號和權(quán)限由于管理不善而泄露了，即使技 術上網(wǎng)站系統(tǒng)再安全,，也不可避免會受到攻擊,。 在筆者曾經(jīng)參與過的一個項目中，客戶方邀請了專業(yè)的第 三方安全測試公司進行了安全性的全面檢測,，同時也針對性地進行了安全性的改善,，特別是在應用程序方面。此文將分享改善過程中的幾個典型問題的分析和解決對 策,，包括SQL注入攻擊,、跨站點腳本攻擊、驗證碼繞過等,，希望能夠為大家在改善網(wǎng)站安全方面的工作提供參考，并采取相應的防范措施,。
項目背景 該項目使用的技術和平臺： OS：Windows 2008 Server, Enterprise Edition 64- bit Database：Microsoft SQL 2005 Server, Standard Edition WebServer：IIS7.0 開發(fā)平臺：.NET Framework 2.0 考慮到網(wǎng)站安全的跨平臺和通用性,，文中討論時僅提供對 應策略不使用實際代碼，這里所有的項目網(wǎng)站用到的域名統(tǒng)一用example.com代替,。
改善之前 第三方專業(yè)安全測試公司進行測試,，其中的重點問題列表 如下：
問題1：易受 到SQL注入攻擊 風險：攻擊者可以通過應用程序發(fā)送數(shù)據(jù)庫命令，這些命令將被服 務器執(zhí)行,。這可以用來對數(shù)據(jù)庫進行完全控制,。這些SQL注入漏洞可以通過在其中一個區(qū)域插入“and 7 = 7 -”或“and 8 = 9 -”，并 比較結(jié)果進行判斷,。 分析：SQL注入攻擊是由于服務器對參數(shù)檢查不夠,，而導致攻擊 者借此獲得敏感信息。因此,，需要使用參數(shù)化查詢以確保攻擊者無法操作數(shù)據(jù)庫的SQL查詢語句,。例如，如果應用程序要求輸入名稱,，那它應該只接受字母字符,、 空格和撇號，而不接受任何其他字符,。也就是說,，在應用程序中的所有輸入域?qū)嵤┓掌鞫税酌麊渭夹g。特別是所有用于SQL語句的輸入域，需要空格的都應該用 引號括起來,。 改善：在程序中所有可接受外部參數(shù)的地方進行逐一識別,，以過濾 危險字符。如在全局函數(shù)中定義“禁止字符串列表”,，該表中列出所要過濾出的SQL攻擊代碼可能包含的字符串,。 and |exec |insert |select |delete |update |count | * |chr |mid |master |truncate |char |declare |<|>|’|(|)|{|} //當然可以根據(jù)網(wǎng)站的特點完善和修改本列表 接下來做如下處理：
問題2：易受 到跨站點腳本攻擊 風險：此漏洞可以被用來獲取身份驗證Cookie，攻擊管理員 賬戶,，或使應用程序的用戶攻擊其他服務器和系統(tǒng),。該漏洞可以通過在某區(qū)域中插入 “<script>alert(‘23389950’);</script>”來判斷。 分析：這也需要在本網(wǎng)站的所有輸入域?qū)嵤┓掌鞫税酌麊渭夹g,。 如果需要特殊字符,，應該轉(zhuǎn)換為更安全的形式。如適用于各種語言的HTML轉(zhuǎn)碼：
改善：除了這些標準的HTML轉(zhuǎn)碼之外，對于可疑字符串也要進 行強化檢查和轉(zhuǎn)化,，并進一步執(zhí)行以下操作：（1）對各頁面的輸入?yún)?shù)進行強化檢查,；（2）對原來只在客戶端判斷的參數(shù)，在服務器端進一步強化檢查;（3） 最終提供了全局的轉(zhuǎn)碼和過濾的函數(shù),。當然這需要在性能和擴展性以及安全性方面的平衡綜合考慮,。 問題3：非安 全的CrossDomain.XML文件 風險：為解決Flash/Flex系統(tǒng)中的跨域問題，提出了 crossdomain.xml跨域策略文件,。雖然可以解決跨域問題,，但是也帶來了惡意攻擊的風險，如果該策略文件里允許訪問任何域,，就可能允許發(fā)起對網(wǎng) 絡服務器的跨站點請求偽造和跨站點腳本攻擊,。比如，不安全Flash應用程序可能會訪問本地數(shù)據(jù)和用戶保存的網(wǎng)頁記錄,，甚至傳播病毒和惡意代碼,。 分析：考慮如何確保只對提供安全資源的可信域開放允許。 改善：經(jīng)過調(diào)查,，發(fā)現(xiàn)在程序目錄下的 crossdomain.xml文件里的配置如下： <?xml version=”1.0″?> <!DOCTYPE cross-domain-policy SYSTEM ”http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd”> <cross-domain-policy> <allow-access-from domain=”*” /> </cross-domain-policy> 文件中的allow-access-from 實體設 置為星號設置為允許任何域訪問,，將其修改為 <allow-access-from domain=”*.example.com” />， 表示只允許本域訪問,，該問題就解決了,。 問題 4：Flash參數(shù)AllowScript-Access 已設置為always 風險：當AllowScriptAccess為always
時,，表明嵌入的第三方Flash文件可以執(zhí)行代碼。攻擊者此時就可以利用該缺陷嵌入任意第三方Flash文件而執(zhí)行惡意 分析：AllowScriptAccess參數(shù)可以是 “always”,、”sameDomain”或“never”。三個可選值中,，“always” 表示Flash文件可以與其嵌入到的 HTML 頁進行 通信,，即使該Flash文件來自不同于HTML頁的域也可以。當參數(shù)為“sameDomain”時,，僅當Flash文件與其嵌入到的HTML頁來自相同的 域時,，該Flash文件才能與該HTML頁進行通信，此值是AllowScriptAccess 的默認值,。而當AllowScriptAccess 為 “never”時,，F(xiàn)lash文件將無法與任何HTML頁進行通信。 因此需要將AllowScriptAccess參數(shù)設 置為“sameDomain”,，可以防止一個域中的Flash文件訪問另一個域的 HTML 頁內(nèi)的腳本,。 改善 <param name=”allowScriptAccess” value=”always” /> 改為 <param name=”allowScriptAccess” value=“sameDomain” />
問題5：網(wǎng)站 后臺管理通過不安全鏈接實施 風險：管理訪問沒有強制實施SSL，這可能允許攻擊者監(jiān)視并修 改用戶和服務器之間的發(fā)送的包括賬戶憑據(jù)在內(nèi)的所有數(shù)據(jù),。如果攻擊者通過代理或者路由軟件攔截服務器和管理員間的通信,，敏感數(shù)據(jù)可能被截獲，進而管理員賬 戶可能會受到危害,。 分析：管理訪問沒有強制實施SSL,，為防止數(shù)據(jù)攔截，管理訪問 應該強制執(zhí)行HTTPS (SSL3.0),。 改善：運維對服務器進行了配置調(diào)整，單獨配置支持了 SSL3.0訪問管理后臺,。 問題6：驗證 環(huán)節(jié)可以被繞過 風險：用戶發(fā)布信息時,，雖然有頁面的驗證碼防止自動惡意發(fā)布， 但仍可能被繞過進行自動提交,。繞過的方式之一是使用過濾和識別軟件,，之二是可以利用Cookie或Session信息繞過驗證碼。 分析：圖像失真機制本身不是特別強,，可以很容易地使用公開的過 濾和識別軟件來識別,。生成的圖片也是可以預測的，因為使用的字符集很簡單（只是數(shù)字）,，建議實現(xiàn)一個更強大的驗證碼系統(tǒng),。 Cookie或session信息處理有漏洞導致驗證 碼被繞過, 確保每一個鏈接只能取得唯一的驗證碼，并確保每個請求產(chǎn)生并需要一個新的驗證碼,。 改善：根據(jù)需要增加驗證碼的復雜度,，而不只是單數(shù)字,。 經(jīng)過分析發(fā)現(xiàn)是因為驗證碼被存入了Session里， 而開發(fā)人員忘記在提交之后清空Session中的驗證碼的值,，導致驗證碼在過期時間內(nèi)一直可用,，從而可能被利用多次提交。因此在提交后追加了及時清空驗證 碼的操作,。 問題7：泄露 敏感信息 風險：此信息只能用于協(xié)助利用其他漏洞,，并不能直接用來破壞應 用程序。網(wǎng)站的robots.txt文件里可以獲得敏感目錄的信息,，這可能允許攻擊者獲得有關應用程序內(nèi)部的其他信息,，這些信息可能被用來攻擊其他漏洞。 分析：robots.txt不應在提供管理界面的信息,。如果 robots.txt文件暴露了Web站點結(jié)構(gòu),，則需要將敏感內(nèi)容移至隔離位置，以避免搜索引擎機器人搜索到此內(nèi)容,。 改善：當然robots.txt要根據(jù)SEO的要求來處理,，但 也要同樣注意安全性。如：disallow:/testadmin/,，其中testadmin為管理后臺,，就被暴露了?？梢愿鶕?jù)實際情況是否必要決定刪除 robots.txt文件或者把敏感目錄單獨配置禁止搜索引擎搜索,。 其他問題匯總 除此以外，還有很多其他危害性相對較低的問題,，分析如 下,。 問題：可 能通過登錄頁面枚舉出用戶名，因為根據(jù)賬戶是否存在的錯誤信息是不同的,。 對策：修 改錯誤信息使之不帶有提示性,，如“您輸入的郵箱或密碼不對!” 并且超過一定次數(shù)則對該IP進行鎖定。 問題：檢 測到可能泄露敏感信息或被惡意利用的冗余文件,，如測試文件,、bak文件、臨時文件,。 對策：除去服務器中的相應文件,。 問題：發(fā)現(xiàn)潛在機密信息，如名為order的文件很容 易被聯(lián)想到用戶訂單,。 對策：避免在文件名中含有完整的敏感詞匯或不要在容易 猜測到的文件中保存敏感信息,，或者限制對它們的訪問。 問題：發(fā)現(xiàn)內(nèi)部信息泄露,。 對策：除去代碼中漏刪的內(nèi)部IP地址,，內(nèi)部組織,，人員 相關信息等。
共性原因分析 在發(fā)現(xiàn)的問題中,，71%是與應用程序相關的安全性問 題,。可以修改應用程序相關的安全性問題,，因為它們是由應用程序代碼中的缺陷造成的,。29%是基礎結(jié)構(gòu)和平臺安全性問題，可以由系統(tǒng)或網(wǎng)絡管理員來修訂“基 礎結(jié)構(gòu)和平臺安全性問題”,，因為這些安全性問題是由第三方產(chǎn)品中的錯誤配置或缺陷造成的,。 綜合主要的原因包括但不限于以下三個方面。 程序方面
配置方面
對于這些問題 的解決方法-——技術之外 對于安全問題本身的解決可能只能 case by case ，但為了預防更多潛在問題的引入,，技術之外方面的改善也不容忽視： 1. 對于開發(fā)人員在項目初期即進行安全開發(fā)的培訓,， 強化安全意識。 2. 建立用于共享安全經(jīng)驗的平臺,，將經(jīng)驗形成 Checklist作為安全指南文檔,。 3. 將成熟的代碼成果提煉出公共安全模塊以備后用。 本次改善之后總結(jié)出一些常用基本安全原則供大家參考,， 見“非官方不完整網(wǎng)站開發(fā)安全原則”。 |
|
|
