如何消除網站安全的七大風險
改善之前
第三方專業安全測試公司進行測試，其中的重點問題列表如下：
問題1：易受到SQL註入攻擊
風險：攻擊者可以通過應用程序發送數據庫命令，這些命令將被服務器執行。這可以用來對數據庫進行完全控制。這些SQL註入漏洞可以通過在其中壹個區域插入“and?7?=?7?-”或“and?8?=?9?-”，並比較結果進行判斷。
分析：SQL註入攻擊是由於服務器對參數檢查不夠，而導致攻擊者借此獲得敏感信息。因此，需要使用參數化查詢以確保攻擊者無法操作數據庫的SQL查詢語句。例如，如果應用程序要求輸入名稱，那它應該只接受字母字符、空格和撇號，而不接受任何其他字符。也就是說，在應用程序中的所有輸入域實施服務器端白名單技術。特別是所有用於SQL語句的輸入域，需要空格的都應該用引號括起來。
改善：在程序中所有可接受外部參數的地方進行逐壹識別，以過濾危險字符。如在全局函數中定義“禁止字符串列表”，該表中列出所要過濾出的SQL攻擊代碼可能包含的字符串。
and?|exec?|insert?|select?|delete?|update?|count?|?*?|chr?|mid?|master?|truncate?|char?|declare?|<|>|’|(|)|{|}
//當然可以根據網站的特點完善和修改本列表
接下來做如下處理：
問題2：易受到跨站點腳本攻擊
風險：此漏洞可以被用來獲取身份驗證Cookie，攻擊管理員賬戶，或使應用程序的用戶攻擊其他服務器和系統。該漏洞可以通過在某區域中插入“<script>alert(‘23389950’);</script>”來判斷。
分析：這也需要在本網站的所有輸入域實施服務器端白名單技術。如果需要特殊字符，應該轉換為更安全的形式。如適用於各種語言的HTML轉碼：
&應轉換為?&；
“應轉換為”；
‘應轉換為&39；
>應轉換為>；
<應轉換為<。
改善：除了這些標準的HTML轉碼之外，對於可疑字符串也要進行強化檢查和轉化，並進壹步執行以下操作：（1）對各頁面的輸入參數進行強化檢查；（2）對原來只在客戶端判斷的參數，在服務器端進壹步強化檢查;（3）最終提供了全局的轉碼和過濾的函數。當然這需要在性能和擴展性以及安全性方面的平衡綜合考慮。
問題3：非安全的CrossDomain.XML文件
風險：為解決Flash/Flex系統中的跨域問題，提出了crossdomain.xml跨域策略文件。雖然可以解決跨域問題，但是也帶來了惡意攻擊的風險，如果該策略文件裏允許訪問任何域，就可能允許發起對網絡服務器的跨站點請求偽造和跨站點腳本攻擊。比如，不安全Flash應用程序可能會訪問本地數據和用戶保存的網頁記錄，甚至傳播病毒和惡意代碼。
分析：考慮如何確保只對提供安全資源的可信域開放允許。
改善：經過調查，發現在程序目錄下的crossdomain.xml文件裏的配置如下：
<?xml?version=”1.0″?>
<!DOCTYPE?cross-domain-policy?SYSTEM?”/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參數AllowScript-Access?已設置為always
風險：當AllowScriptAccess為always時，表明嵌入的第三方Flash文件可以執行代碼。攻擊者此時就可以利用該缺陷嵌入任意第三方Flash文件而執行惡意
代碼。
分析：AllowScriptAccess參數可以是“always”、”sameDomain”或“never”。三個可選值中，“always”?表示Flash文件可以與其嵌入到的?HTML?頁進行通信，即使該Flash文件來自不同於HTML頁的域也可以。當參數為“sameDomain”時，僅當Flash文件與其嵌入到的HTML頁來自相同的域時，該Flash文件才能與該HTML頁進行通信，此值是AllowScriptAccess?的默認值。而當AllowScriptAccess為?“never”時，Flash文件將無法與任何HTML頁進行通信。
因此需要將AllowScriptAccess參數設置為“sameDomain”，可以防止壹個域中的Flash文件訪問另壹個域的?HTML?頁內的腳本。
改善
<param
name=”allowScriptAccess”?value=”always”?/>
改為
<param
name=”allowScriptAccess”?value=“sameDomain”?/>
問題5：網站後臺管理通過不安全鏈接實施
風險：管理訪問沒有強制實施SSL，這可能允許攻擊者監視並修改用戶和服務器之間的發送的包括賬戶憑據在內的所有數據。如果攻擊者通過代理或者路由軟件攔截服務器和管理員間的通信，敏感數據可能被截獲，進而管理員賬戶可能會受到危害。
分析：管理訪問沒有強制實施SSL，為防止數據攔截，管理訪問應該強制執行HTTPS?(SSL3.0)。
改善：運維對服務器進行了配置調整，單獨配置支持了SSL3.0訪問管理後臺。
問題6：驗證環節可以被繞過
風險：用戶發布信息時，雖然有頁面的驗證碼防止自動惡意發布，但仍可能被繞過進行自動提交。繞過的方式之壹是使用過濾和識別軟件，之二是可以利用Cookie或Session信息繞過驗證碼。
分析：圖像失真機制本身不是特別強，可以很容易地使用公開的過濾和識別軟件來識別。生成的圖片也是可以預測的，因為使用的字符集很簡單（只是數字），建議實現壹個更強大的驗證碼系統。
Cookie或session信息處理有漏洞導致驗證碼被繞過,?確保每壹個鏈接只能取得唯壹的驗證碼，並確保每個請求產生並需要壹個新的驗證碼。
改善：根據需要增加驗證碼的復雜度，而不只是單數字。
經過分析發現是因為驗證碼被存入了Session裏，而開發人員忘記在提交之後清空Session中的驗證碼的值，導致驗證碼在過期時間內壹直可用，從而可能被利用多次提交。因此在提交後追加了及時清空驗證碼的操作。
問題7：泄露敏感信息
風險：此信息只能用於協助利用其他漏洞，並不能直接用來破壞應用程序。網站的robots.txt文件裏可以獲得敏感目錄的信息，這可能允許攻擊者獲得有關應用程序內部的其他信息，這些信息可能被用來攻擊其他漏洞。
分析：robots.txt不應在提供管理界面的信息。如果robots.txt文件暴露了Web站點結構，則需要將敏感內容移至隔離位置，以避免搜索引擎機器人搜索到此內容。
改善：當然robots.txt要根據SEO的要求來處理，但也要同樣註意安全性。如：disallow:/testadmin/，其中testadmin為管理後臺，就被暴露了。可以根據實際情況是否必要決定刪除robots.txt文件或者把敏感目錄單獨配置禁止搜索引擎搜索。
其他問題匯總
除此以外，還有很多其他危害性相對較低的問題，分析如下。
問題：可能通過登錄頁面枚舉出用戶名，因為根據賬戶是否存在的錯誤信息是不同的。
對策：修改錯誤信息使之不帶有提示性，如“您輸入的郵箱或密碼不對!”?並且超過壹定次數則對該IP進行鎖定。
問題：檢測到可能泄露敏感信息或被惡意利用的冗余文件，如測試文件、bak文件、臨時文件。
對策：除去服務器中的相應文件。
問題：發現潛在機密信息，如名為order的文件很容易被聯想到用戶訂單。
對策：避免在文件名中含有完整的敏感詞匯或不要在容易猜測到的文件中保存敏感信息，或者限制對它們的訪問。
問題：發現內部信息泄露。
對策：除去代碼中漏刪的內部IP地址，內部組織，人員相關信息等。
***性原因分析
在發現的問題中，71%是與應用程序相關的安全性問題。可以修改應用程序相關的安全性問題，因為它們是由應用程序代碼中的缺陷造成的。29%是基礎結構和平臺安全性問題，可以由系統或網絡管理員來修訂“基礎結構和平臺安全性問題”，因為這些安全性問題是由第三方產品中的錯誤配置或缺陷造成的。
綜合主要的原因包括但不限於以下三個方面。
程序方面
未對用戶輸入正確執行危險字符清理；
Cookie和Session使用時安全性考慮不足；
HTML註釋中或Hidden?form包含敏感信息；
提供給用戶的錯誤信息包含敏感信息；
程序員在?Web?頁面上的調試信息等沒有及時刪除。
Web?應用程序編程或配置不安全；
配置方面
在Web目錄中留下的冗余文件沒有及時清理；
Web服務器或應用程序服務器是以不安全的方式配置的。
安全規範文檔不夠完善，開發人員的培訓不足；
開發人員的安全相關經驗和安全意識不足。
對於這些問題的解決方法-——技術之外
對於安全問題本身的解決可能只能case?by?case?，但為了預防更多潛在問題的引入，技術之外方面的改善也不容忽視：
1.?對於開發人員在項目初期即進行安全開發的培訓，強化安全意識。
2.?建立用於***享安全經驗的平臺，將經驗形成Checklist作為安全指南文檔。
3.?將成熟的代碼成果提煉出公***安全模塊以備後用。
本次改善之後總結出壹些常用基本安全原則供大家參考，見“非官方不完整網站開發安全原則”。
作者簡介：晁曉娟，目前在互聯網公司負責項目管理。InfoQ中文站SOA社區編輯，有多年的Web開發管理經驗，關註項目管理、架構和產品。
(本文來自《程序員》雜誌13年02期)