以工作中某項目的安全改善過程為例，分享了常用網(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è)的第 三方安全測試公司進(jìn)行了安全性的全面檢測，同時也針對性地進(jìn)行了安全性的改善，特別是在應(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è)安全測試公司進(jìn)行測試，其中的重點問題列表 如下：

問題1：易受 到SQL注入攻擊

風(fēng)險：攻擊者可以通過應(yīng)用程序發(fā)送數(shù)據(jù)庫命令，這些命令將被服 務(wù)器執(zhí)行。這可以用來對數(shù)據(jù)庫進(jìn)行完全控制。這些SQL注入漏洞可以通過在其中一個區(qū)域插入“and 7 = 7 -”或“and 8 = 9 -”，并 比較結(jié)果進(jìn)行判斷。

分析：SQL注入攻擊是由于服務(wù)器對參數(shù)檢查不夠，而導(dǎo)致攻擊 者借此獲得敏感信息。因此，需要使用參數(shù)化查詢以確保攻擊者無法操作數(shù)據(jù)庫的SQL查詢語句。例如，如果應(yīng)用程序要求輸入名稱，那它應(yīng)該只接受字母字符、 空格和撇號，而不接受任何其他字符。也就是說，在應(yīng)用程序中的所有輸入域?qū)嵤┓?wù)器端白名單技術(shù)。特別是所有用于SQL語句的輸入域，需要空格的都應(yīng)該用 引號括起來。

改善：在程序中所有可接受外部參數(shù)的地方進(jìn)行逐一識別，以過濾 危險字符。如在全局函數(shù)中定義“禁止字符串列表”，該表中列出所要過濾出的SQL攻擊代碼可能包含的字符串。

and |exec |insert |select |delete |update |count | * |chr |mid |master |truncate |char |declare |<|>|’|(|)|{|}

//當(dāng)然可以根據(jù)網(wǎng)站的特點完善和修改本列表

接下來做如下處理：

問題2：易受 到跨站點腳本攻擊

風(fēng)險：此漏洞可以被用來獲取身份驗證Cookie，攻擊管理員 賬戶，或使應(yīng)用程序的用戶攻擊其他服務(wù)器和系統(tǒng)。該漏洞可以通過在某區(qū)域中插入 “<script>alert(‘23389950’);</script>”來判斷。

分析：這也需要在本網(wǎng)站的所有輸入域?qū)嵤┓?wù)器端白名單技術(shù)。 如果需要特殊字符，應(yīng)該轉(zhuǎn)換為更安全的形式。如適用于各種語言的HTML轉(zhuǎn)碼：

• &應(yīng)轉(zhuǎn)換為 &；
• “應(yīng)轉(zhuǎn)換為”；
• ‘應(yīng)轉(zhuǎn)換為&39；
• >應(yīng)轉(zhuǎn)換為>；
• <應(yīng)轉(zhuǎn)換為<。

改善：除了這些標(biāo)準(zhǔn)的HTML轉(zhuǎn)碼之外，對于可疑字符串也要進(jìn) 行強(qiáng)化檢查和轉(zhuǎn)化，并進(jìn)一步執(zhí)行以下操作：（1）對各頁面的輸入?yún)?shù)進(jìn)行強(qiáng)化檢查；（2）對原來只在客戶端判斷的參數(shù)，在服務(wù)器端進(jìn)一步強(qiáng)化檢查;（3） 最終提供了全局的轉(zhuǎn)碼和過濾的函數(shù)。當(dāng)然這需要在性能和擴(kuò)展性以及安全性方面的平衡綜合考慮。

問題3：非安 全的CrossDomain.XML文件

風(fēng)險：為解決Flash/Flex系統(tǒng)中的跨域問題，提出了 crossdomain.xml跨域策略文件。雖然可以解決跨域問題，但是也帶來了惡意攻擊的風(fēng)險，如果該策略文件里允許訪問任何域，就可能允許發(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

風(fēng)險：當(dāng)AllowScriptAccess為always 時，表明嵌入的第三方Flash文件可以執(zhí)行代碼。攻擊者此時就可以利用該缺陷嵌入任意第三方Flash文件而執(zhí)行惡意
代碼。

分析：AllowScriptAccess參數(shù)可以是 “always”、”sameDomain”或“never”。三個可選值中，“always” 表示Flash文件可以與其嵌入到的 HTML 頁進(jìn)行 通信，即使該Flash文件來自不同于HTML頁的域也可以。當(dāng)參數(shù)為“sameDomain”時，僅當(dāng)Flash文件與其嵌入到的HTML頁來自相同的 域時，該Flash文件才能與該HTML頁進(jìn)行通信，此值是AllowScriptAccess 的默認(rèn)值。而當(dāng)AllowScriptAccess 為 “never”時，F(xiàn)lash文件將無法與任何HTML頁進(jìn)行通信。

因此需要將AllowScriptAccess參數(shù)設(shè) 置為“sameDomain”，可以防止一個域中的Flash文件訪問另一個域的 HTML 頁內(nèi)的腳本。

改善

<param

name=”allowScriptAccess” value=”always” />

改為

<param

name=”allowScriptAccess” value=“sameDomain” />

問題5：網(wǎng)站 后臺管理通過不安全鏈接實施

風(fēng)險：管理訪問沒有強(qiáng)制實施SSL，這可能允許攻擊者監(jiān)視并修 改用戶和服務(wù)器之間的發(fā)送的包括賬戶憑據(jù)在內(nèi)的所有數(shù)據(jù)。如果攻擊者通過代理或者路由軟件攔截服務(wù)器和管理員間的通信，敏感數(shù)據(jù)可能被截獲，進(jìn)而管理員賬 戶可能會受到危害。

分析：管理訪問沒有強(qiáng)制實施SSL，為防止數(shù)據(jù)攔截，管理訪問 應(yīng)該強(qiáng)制執(zhí)行HTTPS (SSL3.0)。

改善：運維對服務(wù)器進(jìn)行了配置調(diào)整，單獨配置支持了 SSL3.0訪問管理后臺。

問題6：驗證 環(huán)節(jié)可以被繞過

風(fēng)險：用戶發(fā)布信息時，雖然有頁面的驗證碼防止自動惡意發(fā)布， 但仍可能被繞過進(jìn)行自動提交。繞過的方式之一是使用過濾和識別軟件，之二是可以利用Cookie或Session信息繞過驗證碼。

分析：圖像失真機(jī)制本身不是特別強(qiáng)，可以很容易地使用公開的過 濾和識別軟件來識別。生成的圖片也是可以預(yù)測的，因為使用的字符集很簡單（只是數(shù)字），建議實現(xiàn)一個更強(qiáng)大的驗證碼系統(tǒng)。

Cookie或session信息處理有漏洞導(dǎo)致驗證 碼被繞過, 確保每一個鏈接只能取得唯一的驗證碼，并確保每個請求產(chǎn)生并需要一個新的驗證碼。

改善：根據(jù)需要增加驗證碼的復(fù)雜度，而不只是單數(shù)字。

經(jīng)過分析發(fā)現(xiàn)是因為驗證碼被存入了Session里， 而開發(fā)人員忘記在提交之后清空Session中的驗證碼的值，導(dǎo)致驗證碼在過期時間內(nèi)一直可用，從而可能被利用多次提交。因此在提交后追加了及時清空驗證 碼的操作。

問題7：泄露 敏感信息

風(fēng)險：此信息只能用于協(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)容移至隔離位置，以避免搜索引擎機(jī)器人搜索到此內(nèi)容。

改善：當(dāng)然robots.txt要根據(jù)SEO的要求來處理，但 也要同樣注意安全性。如：disallow:/testadmin/，其中testadmin為管理后臺，就被暴露了。可以根據(jù)實際情況是否必要決定刪除 robots.txt文件或者把敏感目錄單獨配置禁止搜索引擎搜索。

其他問題匯總

除此以外，還有很多其他危害性相對較低的問題，分析如 下。

問題：可 能通過登錄頁面枚舉出用戶名，因為根據(jù)賬戶是否存在的錯誤信息是不同的。

對策：修 改錯誤信息使之不帶有提示性，如“您輸入的郵箱或密碼不對!” 并且超過一定次數(shù)則對該IP進(jìn)行鎖定。

問題：檢 測到可能泄露敏感信息或被惡意利用的冗余文件，如測試文件、bak文件、臨時文件。

對策：除去服務(wù)器中的相應(yīng)文件。

問題：發(fā)現(xiàn)潛在機(jī)密信息，如名為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)品中的錯誤配置或缺陷造成的。

綜合主要的原因包括但不限于以下三個方面。

程序方面

• 未對用戶輸入正確執(zhí)行危險字符清 理；
• Cookie和Session使用 時安全性考慮不足；
• HTML注釋中或 Hidden form包含敏感信息；
• 提供給用戶的錯誤信息包含敏感信 息；
• 程序員在 Web 頁面上的調(diào)試信 息等沒有及時刪除。
• Web 應(yīng)用程序編程或配置不安 全；

配置方面

• 在Web目錄中留下的冗余文件沒有 及時清理；
• Web服務(wù)器或應(yīng)用程序服務(wù)器是以 不安全的方式配置的。
• 安全規(guī)范文檔不夠完善，開發(fā)人員的 培訓(xùn)不足；
• 開發(fā)人員的安全相關(guān)經(jīng)驗和安全意識 不足。

對于這些問題 的解決方法-——技術(shù)之外

對于安全問題本身的解決可能只能 case by case ，但為了預(yù)防更多潛在問題的引入，技術(shù)之外方面的改善也不容忽視：

1. 對于開發(fā)人員在項目初期即進(jìn)行安全開發(fā)的培訓(xùn)， 強(qiáng)化安全意識。

2. 建立用于共享安全經(jīng)驗的平臺，將經(jīng)驗形成 Checklist作為安全指南文檔。

3. 將成熟的代碼成果提煉出公共安全模塊以備后用。

本次改善之后總結(jié)出一些常用基本安全原則供大家參考， 見“非官方不完整網(wǎng)站開發(fā)安全原則”。