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