1、DKBA華為技術(shù)有限公司內(nèi)部技術(shù)規(guī)范DKBA 1606-XXXX.XWeb應(yīng)用安全開發(fā)規(guī)范 V1.52013年XX月XX日發(fā)布 2013年XX月XX日實施華為技術(shù)有限公司Huawei Technologies Co., Ltd.版權(quán)所有侵權(quán)必究All rights reserved修訂聲明Revision declaration本規(guī)范擬制與解釋部門：網(wǎng)絡(luò)安全能力中心&電信軟件與核心網(wǎng)網(wǎng)絡(luò)安全工程部本規(guī)范的相關(guān)系列規(guī)范或文件：C&C+語言安全編程規(guī)范Java語言安全編程規(guī)范相關(guān)國際規(guī)范或文件一致性：無替代或作廢的其它規(guī)范或文件：無相關(guān)規(guī)范或文件的相互關(guān)系：產(chǎn)品網(wǎng)絡(luò)安全紅線和電信軟件與核心網(wǎng)業(yè)務(wù)部

2、安全能力基線中的Web安全要求引用了本規(guī)范的內(nèi)容，如果存在沖突，以本規(guī)范為準(zhǔn)。規(guī)范號主要起草部門專家主要評審部門專家修訂情況DKBA 1606-2007.4安全解決方案：趙武42873，楊光磊57125，萬振華55108軟件公司設(shè)計管理部：劉茂征11000，劉高峰63564，何偉祥33428安全解決方案：劉海軍12014，吳宇翔18167，吳海翔57182接入網(wǎng)：彭東紅27279無線：胡濤46634核心網(wǎng)：吳桂彬 41508，甘嘉棟 33229，馬進 32897，謝秀洪 33194，張毅 27651，張永鋒 40582業(yè)軟：包宜強56737，丁小龍63583，董鵬越60793，傅鑒杏36918

3、，傅用成30333，龔連陽18753，胡海，胡海華52463，李誠37517，李大鋒54630，李戰(zhàn)杰21615，劉創(chuàng)文65632，劉飛46266，劉劍51690，欒陽62227，羅仁鈞65560，羅湘武06277，馬亮，孟詠喜22499，潘海濤27360，孫林46580，王福40317，王錦亮36430，王美玲，王謨磊65558，王玉龍24387，楊娟，張鋒43381，張健，張軼57143，鄒韜51591V1.0何偉祥33428劉高峰 63564，龔連陽 ，許汝波 62966，吳宇翔 ，王歡 ，呂曉雨 56987V1.2增加了Web Service、Ajax和上傳和下載相關(guān)的安全規(guī)范。何偉祥

4、V1.3增加了防止會話固定和防止跨站請求偽造的安全規(guī)范。何偉祥V1.4增加了規(guī)則3.4.1的實施指導(dǎo)；刪除了建議3.4.1；修改了6 配套CBB介紹的內(nèi)容和獲取方式。增加了3.9 DWR何偉祥 吳淑榮 魏建雄 謝和坤 李田 孫波 朱雙紅 王偉 陳偉 V1.5增加規(guī)則3.3.9、規(guī)則3.6.5、規(guī)則4.7.1、建議4.7.2、4.8 PHP增加3.8 RESTful Web Service修改規(guī)則、規(guī)則、規(guī)則3.4.1、規(guī)則4.6.1刪除3.2.1口令策略和規(guī)則3.1.3、規(guī)則、規(guī)則4.7.1附件文檔作為對象直接插入主文檔目錄 Table of Cont

5、ents1概述71.1背景簡介71.2技術(shù)框架71.3使用對象81.4適用范圍81.5用詞約定92常見WEB安全漏洞93WEB設(shè)計安全規(guī)范103.1WEB部署要求103.2身份驗證113.2.1口令113.2.2認(rèn)證113.2.3驗證碼133.3會話管理133.4權(quán)限管理153.5敏感數(shù)據(jù)保護163.5.1敏感數(shù)據(jù)定義163.5.2敏感數(shù)據(jù)存儲163.5.3敏感數(shù)據(jù)傳輸173.6安全審計183.7WEB SERVICE193.8RESTFUL WEB SERVICE203.9DWR214WEB編程安全規(guī)范224.1輸入校驗224.2輸出編碼254.3上傳下載264.4異常處理264.5代碼注釋

6、264.6歸檔要求274.7其他284.8PHP295WEB安全配置規(guī)范316配套CBB介紹316.1WAF CBB316.2驗證碼CBB327附件327.1附件1 TOMCAT配置SSL指導(dǎo)327.2附件2 WEB SERVICE 安全接入開發(fā)指導(dǎo)327.3附件3 客戶端IP鑒權(quán)實施指導(dǎo)327.4附件4 口令安全要求327.5附件5 WEB權(quán)限管理設(shè)計規(guī)格說明書34Web應(yīng)用安全開發(fā)規(guī)范 V1.51概述1.1背景簡介在Internet大眾化及Web技術(shù)飛速演變的今天，Web安全所面臨的挑戰(zhàn)日益嚴(yán)峻。黑客攻擊技術(shù)越來越成熟和大眾化，針對Web的攻擊和破壞不斷增長，Web安全風(fēng)險達到了前所未有的

7、高度。許多程序員不知道如何開發(fā)安全的應(yīng)用程序，開發(fā)出來的Web應(yīng)用存在較多的安全漏洞，這些安全漏洞一旦被黑客利用將導(dǎo)致嚴(yán)重甚至是災(zāi)難性的后果。這并非危言聳聽，類似的網(wǎng)上事故舉不勝舉，公司的Web產(chǎn)品也曾多次遭黑客攻擊，甚至有黑客利用公司W(wǎng)eb產(chǎn)品的漏洞敲詐運營商，造成極其惡劣的影響。本規(guī)范就是提供一套完善的、系統(tǒng)化的、實用的Web安全開發(fā)方法供Web研發(fā)人員使用，以期達到提高Web安全的目的。本規(guī)范主要包括三大內(nèi)容：Web設(shè)計安全、Web編程安全、Web配置安全，配套CBB，多管齊下，實現(xiàn)Web應(yīng)用的整體安全性；本規(guī)范主要以JSP/Java編程語言為例。1.2技術(shù)框架圖1 典型的Web安全技術(shù)

8、框架圖1 顯示了典型的Web安全的技術(shù)框架和安全技術(shù)點，這些安全技術(shù)點，貫穿整個Web設(shè)計開發(fā)過程。上圖各個區(qū)域中存在任何一點薄弱環(huán)節(jié)，都容易導(dǎo)致安全漏洞。由于HTTP的開放性，Web應(yīng)用程序必須能夠通過某種形式的身份驗證來識別用戶，并確保身份驗證過程是安全的，同樣必須很好地保護用于跟蹤已驗證用戶的會話處理機制。為了防止一些惡意輸入，還要對輸入的數(shù)據(jù)和參數(shù)進行校驗。另外還要考慮Web系統(tǒng)的安全配置，敏感數(shù)據(jù)的保護和用戶的權(quán)限管理，以及所有操作的安全審計。當(dāng)然還要考慮代碼安全，以及其他方面的威脅。表 1 列出了一些Web缺陷類別，并針對每類缺陷列出了由于設(shè)計不當(dāng)可能會導(dǎo)致的潛在問題。針對這些潛在

9、的問題，本規(guī)范中有相應(yīng)的解決措施。表1 Web 應(yīng)用程序缺陷和由于不良設(shè)計可能導(dǎo)致的問題缺陷類別由于不良設(shè)計可能導(dǎo)致的問題身份驗證身份偽造、口令破解、權(quán)限提升和未授權(quán)訪問。會話管理通過捕獲導(dǎo)致會話劫持和會話偽造。權(quán)限管理訪問機密或受限數(shù)據(jù)、篡改和執(zhí)行未授權(quán)操作。配置管理未授權(quán)訪問管理界面、更新配置數(shù)據(jù)、訪問用戶帳戶和帳戶配置文件。敏感數(shù)據(jù)機密信息泄漏和數(shù)據(jù)篡改。加密技術(shù)未授權(quán)訪問機密數(shù)據(jù)或帳戶信息。安全審計未能識別入侵征兆、無法證明用戶的操作，以及在問題診斷中存在困難。輸入檢驗通過嵌入查詢字符串、窗體字段、Cookie 和 HTTP 標(biāo)頭中的惡意字符串所執(zhí)行的攻擊。包括命令執(zhí)行、跨站點腳本編寫

10、 (XSS)、SQL 注入和緩沖區(qū)溢出攻擊等。參數(shù)操作路徑遍歷攻擊、命令執(zhí)行、此外還有跳過訪問控制機制、導(dǎo)致信息泄露、權(quán)限提升和拒絕服務(wù)。異常管理拒絕服務(wù)和敏感的系統(tǒng)級詳細信息泄露。1.3使用對象本規(guī)范的讀者及使用對象主要為Web相關(guān)的需求分析人員、設(shè)計人員、開發(fā)人員、測試人員等。1.4適用范圍本規(guī)范的制定考慮了公司各種Web應(yīng)用開發(fā)的共性，適合于公司絕大部分Web產(chǎn)品，要求Web產(chǎn)品開發(fā)必須遵循。對于嵌入式系統(tǒng)（如ADSL Modem、硬件防火墻）中的Web應(yīng)用，由于其特殊性（CPU、內(nèi)存、磁盤容量有限，沒有成熟的Web容器），不強制遵循本規(guī)范的所有內(nèi)容，只需遵循以下章節(jié)的規(guī)則要求：3.2身

11、份驗證3.3會話管理3.5敏感數(shù)據(jù)保護4.1輸入校驗4.2輸出編碼4.3上傳下載4.5代碼注釋4.6歸檔要求1.5用詞約定?規(guī)則：強制必須遵守的原則?建議：需要加以考慮的原則?說明：對此規(guī)則或建議進行相應(yīng)的解釋?實施指導(dǎo)：對此規(guī)則或建議的實施進行相應(yīng)的指導(dǎo)2常見Web安全漏洞Web應(yīng)用的安全漏洞有很多，無法窮舉。針對眾多的Web漏洞，OWASP的專家們結(jié)合各自在各領(lǐng)域的應(yīng)用安全工作經(jīng)驗及智慧，提出了十大Web應(yīng)用程序安全漏洞，幫助人們關(guān)注最嚴(yán)重的漏洞。（OWASP即開放Web應(yīng)用安全項目，是一個旨在幫助人們理解和提高Web應(yīng)用及服務(wù)安全性的項目組織。）表2 十大Web應(yīng)用程序安全漏洞列表序號漏

12、洞名稱漏洞描述1注入注入攻擊漏洞，例如SQL、OS命令以及LDAP注入。這些攻擊發(fā)生在當(dāng)不可信的數(shù)據(jù)作為命令或者查詢語句的一部分，被發(fā)送給解釋器的時候。攻擊者發(fā)送的惡意數(shù)據(jù)可以欺騙解釋器，以執(zhí)行計劃外的命令或者訪問未被授權(quán)的數(shù)據(jù)。2跨站腳本當(dāng)應(yīng)用程序收到含有不可信的數(shù)據(jù)，在沒有進行適當(dāng)?shù)尿炞C和轉(zhuǎn)義的情況下，就將它發(fā)送給一個網(wǎng)頁瀏覽器，這就會產(chǎn)生跨站腳本攻擊（簡稱XSS）。XSS允許攻擊者在受害者的瀏覽器上執(zhí)行腳本，從而劫持用戶會話、危害網(wǎng)站、或者將用戶轉(zhuǎn)向至惡意網(wǎng)站。3失效的身份認(rèn)證和會話管理與身份認(rèn)證和會話管理相關(guān)的應(yīng)用程序功能往往得不到正確的實現(xiàn)，這就導(dǎo)致了攻擊者破壞密碼、密匙、會話令牌或

13、攻擊其他的漏洞去冒充其他用戶的身份。4不安全的直接對象引用當(dāng)開發(fā)人員暴露一個對內(nèi)部實現(xiàn)對象的引用時，例如，一個文件、目錄或者數(shù)據(jù)庫密匙，就會產(chǎn)生一個不安全的直接對象引用。在沒有訪問控制檢測或其他保護時，攻擊者會操控這些引用去訪問未授權(quán)數(shù)據(jù)。5跨站請求偽造一個跨站請求偽造攻擊迫使登錄用戶的瀏覽器將偽造的HTTP請求，包括該用戶的會話cookie和其他認(rèn)證信息，發(fā)送到一個存在漏洞的Web應(yīng)用程序。這就允許了攻擊者迫使用戶瀏覽器向存在漏洞的應(yīng)用程序發(fā)送請求，而這些請求會被應(yīng)用程序認(rèn)為是用戶的合法請求。6安全配置錯誤好的安全需要對應(yīng)用程序、框架、應(yīng)用程序服務(wù)器、Web服務(wù)器、數(shù)據(jù)庫服務(wù)器和平臺，定義和

14、執(zhí)行安全配置。由于許多設(shè)置的默認(rèn)值并不是安全的，因此，必須定義、實施和維護所有這些設(shè)置。這包括了對所有的軟件保護及時地更新，包括所有應(yīng)用程序的庫文件。7失敗的URL訪問權(quán)限限制許多Web應(yīng)用程序在顯示受保護的鏈接和按鈕之前會檢測URL訪問權(quán)限。但是，當(dāng)這些頁面被訪問時，應(yīng)用程序也需要執(zhí)行類似的訪問控制檢測，否則攻擊者將可以偽裝這些URL去訪問隱藏的網(wǎng)頁。8未經(jīng)驗證的重定向和前轉(zhuǎn)Web應(yīng)用程序經(jīng)常將用戶重定向和前轉(zhuǎn)到其他網(wǎng)頁和網(wǎng)站，并且利用不可信的數(shù)據(jù)去判定目的頁面。如果沒有得到適當(dāng)驗證，攻擊者可以將受害用戶重定向到釣魚網(wǎng)站或惡意網(wǎng)站，或者使用前轉(zhuǎn)去訪問未經(jīng)授權(quán)的網(wǎng)頁。9不安全的加密存儲許多We

15、b應(yīng)用程序并沒有使用恰當(dāng)?shù)募用艽胧┗騂ash算法保護敏感數(shù)據(jù)，比如信用卡、社會安全號碼（SSN）、認(rèn)證憑據(jù)等。攻擊者可能利用這種弱保護數(shù)據(jù)實行身份盜竊、信用卡欺騙或或其他犯罪。10傳輸層保護不足應(yīng)用程序時常沒有身份認(rèn)證、加密措施，甚至沒有保護敏感網(wǎng)絡(luò)數(shù)據(jù)的保密性和完整性。而當(dāng)進行保護時，應(yīng)用程序有時采用弱算法、使用過期或無效的證書，或不正確地使用這些技術(shù)。3Web設(shè)計安全規(guī)范3.1Web部署要求規(guī)則3.1.1：如果 Web 應(yīng)用對 Internet 開放，Web服務(wù)器應(yīng)當(dāng)置于DMZ區(qū)，在Web服務(wù)器與Internet之間，Web服務(wù)器與內(nèi)網(wǎng)之間應(yīng)當(dāng)有防火墻隔離，并設(shè)置合理的策略。規(guī)則3.1.2

16、：如果 Web 應(yīng)用對 Internet 開放，Web服務(wù)器應(yīng)該部署在其專用的服務(wù)器上，應(yīng)避免將數(shù)據(jù)庫服務(wù)器或其他核心應(yīng)用與Web服務(wù)器部署在同一臺主機上。說明：Web服務(wù)器比較容易被攻擊，如果數(shù)據(jù)庫或核心應(yīng)用與Web服務(wù)器部署在同一臺主機，一旦Web服務(wù)器被攻陷，那么數(shù)據(jù)庫和核心應(yīng)用也就被攻擊者掌控了。規(guī)則3.1.3：Web站點的根目錄必須安裝在非系統(tǒng)卷中。說明：Web站點根目錄安裝在非系統(tǒng)卷，如單獨創(chuàng)建一個目錄/home/Web作為Web站點根目錄，能夠防止攻擊者使用目錄遍歷攻擊訪問系統(tǒng)工具和可執(zhí)行文件。建議3.1.1：Web服務(wù)器與應(yīng)用服務(wù)器需物理分離（即安裝在不同的主機上），以提高應(yīng)用

17、的安全性。建議3.1.2：如果Web應(yīng)用系統(tǒng)存在不同的訪問等級（如個人帳號使用、客戶服務(wù)、管理），那么應(yīng)該通過不同的Web服務(wù)器來處理來自不同訪問等級的請求，而且Web應(yīng)用應(yīng)該鑒別請求是否來自正確的Web服務(wù)器。說明：這樣便于通過防火墻的訪問控制策略和Web應(yīng)用來控制不同訪問等級的訪問，比如通過防火墻策略控制，只允許內(nèi)網(wǎng)訪問管理Portal。建議3.1.3：對于客戶服務(wù)和管理類的訪問，除了普通的認(rèn)證，還應(yīng)該增加額外的訪問限制。說明：額外的訪問限制，可以限制請求來自企業(yè)內(nèi)網(wǎng)，可以建立VPN，或采用雙向認(rèn)證的SSL；或采用更簡單的辦法，通過IP地址白名單對客戶端的IP地址進行過濾判斷，實施參考附件

18、3客戶端IP鑒權(quán)實施指導(dǎo)。3.2身份驗證3.2.1口令關(guān)于Web應(yīng)用及容器涉及到的口令，請遵循產(chǎn)品網(wǎng)絡(luò)安全紅線的口令安全要求（詳細內(nèi)容請見：附件4 口令安全要求.xlsx）。3.2.2認(rèn)證規(guī)則：對用戶的最終認(rèn)證處理過程必須放到應(yīng)用服務(wù)器進行。說明：不允許僅僅通過腳本或其他形式在客戶端進行驗證，必須在應(yīng)用服務(wù)器進行最終認(rèn)證處理（如果采用集中認(rèn)證，那么對用戶的最終認(rèn)證就是放在集中認(rèn)證服務(wù)器進行）。規(guī)則：網(wǎng)頁上的登錄/認(rèn)證表單必須加入驗證碼。說明：使用驗證碼的目的是為了阻止攻擊者使用自動登錄工具連續(xù)嘗試登錄，從而降低被暴力破解的可能。如果覺得驗證碼影響用戶體驗，那么可以在

19、前3次登錄嘗試中不使用驗證碼，3次登錄失敗后必須使用驗證碼。驗證碼在設(shè)計上必須要考慮到一些安全因素，以免能被輕易地破解。具體實現(xiàn)細節(jié)請查看3.2.3驗證碼。如圖：圖2 驗證碼實施指導(dǎo)：建議使用電信軟件與核心網(wǎng)網(wǎng)絡(luò)安全工程部提供的驗證碼CBB。備注：對于嵌入式系統(tǒng)，如果實現(xiàn)驗證碼比較困難，可以通過多次認(rèn)證失敗鎖定客戶端IP的方式來防止暴力破解。規(guī)則：用戶名、密碼和驗證碼必須在同一個請求中提交給服務(wù)器，必須先判斷驗證碼是否正確，只有當(dāng)驗證碼檢驗通過后才進行用戶名和密碼的檢驗，否則直接提示驗證碼錯誤。說明：如果驗證碼和用戶名、密碼分開提交，攻擊者就可以繞過驗證碼校驗（如：先手工提交正確

20、的驗證碼，再通過程序暴力破解），驗證碼就形同虛設(shè)，攻擊者依然可以暴力破解用戶名及口令。規(guī)則：所有登錄頁面的認(rèn)證處理模塊必須統(tǒng)一。說明：可以存在多個登錄頁面，但是不允許存在多個可用于處理登錄認(rèn)證請求的模塊，防止不一致的認(rèn)證方式。規(guī)則：所有針對其他第三方開放接口的認(rèn)證處理模塊必須統(tǒng)一。規(guī)則：認(rèn)證處理模塊必須對提交的參數(shù)進行合法性檢查。說明：具體輸入校驗部分請查看4.1輸入校驗。規(guī)則：認(rèn)證失敗后，不能提示給用戶詳細以及明確的錯誤原因，只能給出一般性的提示。說明：可以提示：用戶名或者口令錯誤，登錄失??；不能提示：用戶名不存在、口令必須是 6 位等

21、等。規(guī)則：最終用戶portal和管理portal分離。說明：最終用戶portal和管理portal分離，防止相互影響，防止來自用戶面的攻擊影響管理面。實施指導(dǎo)：將最終用戶portal和管理portal分別部署在?煌?奈錮矸(tm)務(wù)器；如果為了解決成本合設(shè)（部署在同一臺物理服務(wù)器上），那么，必須做到端口分離（通過不同的端口提供Web服務(wù)），一般的Web容器（如tomcat）支持為不同的Web應(yīng)用創(chuàng)建不同的端口。規(guī)則：禁止在系統(tǒng)中預(yù)留任何的后門帳號或特殊的訪問機制。規(guī)則0：對于重要的管理事務(wù)或重要的交易事務(wù)要進行重新認(rèn)證，以防范會話劫持和跨站請求偽造給用

22、戶帶來損失。說明：重要的管理事務(wù)，比如重新啟動業(yè)務(wù)模塊；重要的交易事務(wù)，比如轉(zhuǎn)賬、余額轉(zhuǎn)移、充值等。重新認(rèn)證，比如讓用戶重新輸入口令。規(guī)則1：用戶名和密碼認(rèn)證通過后，必須更換會話標(biāo)識，以防止會話固定（session fixation）漏洞。實施指導(dǎo)：場景一：對于從HTTP轉(zhuǎn)到HTTPS再轉(zhuǎn)到HTTP（也就是僅在認(rèn)證過程采用HTTPS，認(rèn)證成功后又轉(zhuǎn)到HTTP）的，在用戶名和密碼認(rèn)證通過后增加以下行代碼：request.getSession().invalidate();HttpSession newSession=request.getSession(true);Cookie c

23、ookie = new Cookie(JSESSIONID,newSession.getId(); cookie.setMaxAge(-1);cookie.setSecure(false);cookie.setPath(request.getContextPath();response.addCookie(cookie);場景二：對于全程采用HTTPS協(xié)議，或者全程采用HTTP協(xié)議的，在用戶名和密碼認(rèn)證通過后增加以下行代碼：request.getSession().invalidate();request.getSession(true);建議：管理頁面建議實施強身份認(rèn)證。說明：

24、如雙因素認(rèn)證、SSL雙向證書認(rèn)證、生物認(rèn)證等；還可以通過應(yīng)用程序限制只允許某些特定的IP地址訪問管理頁面，并且這些特定的IP地址可配置。建議：同一客戶端在多次連續(xù)嘗試登錄失敗后，服務(wù)端需要進行用戶帳號或者是客戶端所在機器的 IP 地址的鎖定策略，且該鎖定策略必須設(shè)置解鎖時長，超時后自動解鎖。說明：登錄失敗應(yīng)該提示用戶：如果重試多少次不成功系統(tǒng)將會鎖定。在鎖定期間不允許該用戶帳號（或者客戶端所在機器的 IP 地址）登錄。允許連續(xù)失敗的次數(shù)（指從最后一次成功以來失敗次數(shù)的累計值）可配置，取值范圍為：0-99 次，0表示不執(zhí)行鎖定策略，建議默認(rèn)：5 次。鎖定時長的取值范圍為：0-999

25、 分鐘，建議默認(rèn)：30 分鐘，當(dāng)取值為 0 時，表示無限期鎖定，只能通過管理員手動解鎖（需要提供管理員對服務(wù)器鎖定其它用戶帳號/IP進行解鎖的功能界面）。建議優(yōu)先使用帳號鎖定策略。注意：應(yīng)用程序的超級用戶帳號不能被鎖定，只能鎖定操作的客戶端所在的 IP，這是為了防止系統(tǒng)不可用。特別說明：鎖客戶端IP策略存在缺陷，當(dāng)用戶使用proxy上網(wǎng)時，那么鎖定客戶端IP會導(dǎo)致使用該proxy上網(wǎng)的所有用戶在IP鎖定期間都不能使用該Web應(yīng)用；鎖定用戶帳戶的策略也存在缺陷，當(dāng)攻擊者不斷嘗試某帳戶的口令，就給該帳戶帶來拒絕服務(wù)攻擊，使該帳戶不可用。3.2.3驗證碼規(guī)則：驗證碼必須是單一圖片，且只

26、能采用 JPEG、PNG或GIF格式。說明：驗證碼不能使用文本格式，不允許多圖片組合（如用四個圖片拼成的驗證碼）。規(guī)則：驗證碼內(nèi)容不能與客戶端提交的任何信息相關(guān)聯(lián)。說明：在使用驗證碼生成模塊時不允許接收來自客戶端的任何參數(shù)，例如：禁止通過getcode.jsp?code=1234的URL請求，將1234作為驗證碼隨機數(shù)。規(guī)則：驗證碼模塊生成的隨機數(shù)不能在客戶端的靜態(tài)頁面中的網(wǎng)頁源代碼里出現(xiàn)。說明：在客戶端網(wǎng)頁上點擊鼠標(biāo)右鍵、選擇查看源文件時，必須看不到驗證碼模塊生成的隨機數(shù)。規(guī)則：驗證碼字符串要求是隨機生成，生成的隨機數(shù)必須是安全的。說明：對于java

27、語言可以使用類 java.security.SecureRandom來生成安全的隨機數(shù)。規(guī)則：驗證碼要求有背景干擾，背景干擾元素的顏色、位置、數(shù)量要求隨機變化。規(guī)則：驗證碼在一次使用后要求立即失效，新的請求需要重新生成驗證碼。說明：進行驗證碼校驗后，立即將會話中的驗證碼信息清空，而不是等到生成新的驗證碼時再去覆蓋舊的驗證碼，防止驗證碼多次有效；注意：當(dāng)客戶端提交的驗證碼為空，驗證不通過。說明：以上規(guī)則可以通過使用電信軟件與核心網(wǎng)網(wǎng)絡(luò)安?灘刻峁?驗證碼CBB來實現(xiàn)。3.3會話管理規(guī)則3.3.1：使用會話cookie維持會話。說明：目前主流的Web容器通過以下幾種方式維

28、持會話：隱藏域、URL重寫、持久性cookie、會話cookie，但通過隱藏域、URL重寫或持久性cookie方式維持的會話容易被竊取，所以要求使用會話cookie維持會話。如果條件限制必須通過持久性cookie維持會話的話，那么cookie信息中的重要數(shù)據(jù)部分如身份信息、計費信息等都必須進行加密。（cookie有兩種：會話cookie和持久性cookie；會話cookie，也就是非持久性cookie，不設(shè)置過期時間，其生命期為瀏覽器會話期間，只要關(guān)閉瀏覽器窗口，cookie就消失了；會話cookie一般不存儲在硬盤上而是保存在內(nèi)存里。持久性cookie，設(shè)置了過期時間，被瀏覽器保存到硬盤上，

29、關(guān)閉后再次打開瀏覽器，持久性cookie仍然有效直到超過設(shè)定的過期時間。）備注：對于嵌入式系統(tǒng)的Web，不適合本條規(guī)則，按規(guī)則3.3.9實施。規(guī)則3.3.2：會話過程中不允許修改的信息，必須作為會話狀態(tài)的一部分在服務(wù)器端存儲和維護。說明：會話過程中不允許修改的信息，例如，當(dāng)用戶通過認(rèn)證后，其用戶標(biāo)識在整個會話過程中不能被篡改。禁止通過隱藏域或URL重寫等不安全的方式存儲和維護。對JSP語言，就是應(yīng)該通過session對象進行存儲和維護。規(guī)則3.3.3：當(dāng)Web應(yīng)用跟蹤到非法會話，則必須記錄日志、清除會話并返回到認(rèn)證界面。說明：非法會話的概念就是通過一系列的服務(wù)端合法性檢測（包括訪問未授權(quán)資源，

30、缺少必要參數(shù)等情況），最終發(fā)現(xiàn)的不是正常請求產(chǎn)生的會話。規(guī)則3.3.4：禁止使用客戶端提交的未經(jīng)審核的信息來給會話信息賦值。說明：防止會話信息被篡改，如惡意用戶通過URL篡改手機號碼等。規(guī)則3.3.5：當(dāng)用戶退出時，必須清除該用戶的會話信息。說明：防止遺留在內(nèi)存中的會話信息被竊取，減少內(nèi)存占用。實施指導(dǎo)：對于JSP或java語言使用如下語句：request.getSession().invalidate();規(guī)則3.3.6：必須設(shè)置會話超時機制，在超時過后必須要清除該會話信息。說明：建議默認(rèn)會話超時時間為10分鐘（備注：對于嵌入式系統(tǒng)中的Web，建議默認(rèn)超時時間為5分鐘，以減少系統(tǒng)資源占用）。

31、如果沒有特殊需求，禁止使用自動發(fā)起請求的機制來阻止session超時。規(guī)則3.3.7：在服務(wù)器端對業(yè)務(wù)流程進行必要的流程安全控制，保證流程銜接正確，防止關(guān)鍵鑒別步驟被繞過、重復(fù)、亂序。說明：客戶端流程控制很容易被旁路（繞過），因此流程控制必須在服務(wù)器端實現(xiàn)。實施指導(dǎo)：可以通過在session對象中創(chuàng)建一個表示流程當(dāng)前狀態(tài)的標(biāo)識位，用0、1、2、3、.、N分別表示不同的處理步驟，標(biāo)識位的初始值為0，當(dāng)接收到步驟N的處理請求時，判斷該標(biāo)識位是否為N-1，如果不為N-1，則表示步驟被繞過（或重復(fù)或亂序），拒絕受理，否則受理，受理完成后更改標(biāo)識位為N。規(guī)則3.3.8：所有登錄后才能訪問的頁面都必須有明

32、顯的注銷（或退出）的按鈕或菜單，如果該按鈕或菜單被點擊，則必須使對應(yīng)的會話立即失效。說明：這樣做是為了讓用戶能夠方便地、安全地注銷或退出，減小會話劫持的風(fēng)險。規(guī)則3.3.9：如果產(chǎn)品（如嵌入式系統(tǒng)）無法使用通用的Web容器，只能自己實現(xiàn)Web服務(wù)，那么必須自己實現(xiàn)會話管理，并滿足以下要求：?采用會話cookie維持會話。?生成會話標(biāo)識（session ID）要保證足夠的隨機、離散，以便不能被猜測、枚舉，要求session ID要至少要32字節(jié)，要支持字母和數(shù)字字符集。?服務(wù)端必須對客戶端提交的session ID的有效性進行校驗。說明：在嵌入式系統(tǒng)中部署Web應(yīng)用，由于軟硬件資源所限，往往無法

33、使用通用的Web容器及容器的會話管理功能，只能自己實現(xiàn)。另外，為了節(jié)省內(nèi)存，嵌入式webserver進程往往是動態(tài)啟動，為了使session更快的超時，建議增加心跳機制，對客戶端瀏覽器是否關(guān)閉進行探測，5s一個心跳，30s沒有心跳則session超時，關(guān)閉該session。3.4權(quán)限管理規(guī)則3.4.1：對于每一個需要授權(quán)訪問的頁面或servlet的請求都必須核實用戶的會話標(biāo)識是否合法、用戶是否被授權(quán)執(zhí)行這個操作。說明：防止用戶通過直接輸入URL，越權(quán)請求并執(zhí)行一些頁面或servlet；建議通過過濾器實現(xiàn)。實施指導(dǎo)：請參考附件5 Web權(quán)限管理設(shè)計規(guī)格說明書.docx。規(guī)則3.4.2：授權(quán)和用戶

34、角色數(shù)據(jù)必須存放在服務(wù)器端，不能存放在客戶端，鑒權(quán)處理也必須在服務(wù)器端完成。說明：禁止將授權(quán)和角色數(shù)據(jù)存放在客戶端中（比如cookie或隱藏域中），以防止被篡改。規(guī)則3.4.3：一個帳號只能擁有必需的角色和必需的權(quán)限。一個組只能擁有必需的角色和必需的權(quán)限。一個角色只能擁有必需的權(quán)限。說明：做到權(quán)限最小化和職責(zé)分離（職責(zé)分離就是分清帳號角色，系統(tǒng)管理帳號只用于系統(tǒng)管理，審計帳號只用于審計，操作員帳號只用于業(yè)務(wù)維護操作，普通用戶帳號只能使用業(yè)務(wù)。）這樣即使帳號被攻擊者盜取，也能把安全損失控制在最小的限度。規(guī)則3.4.4：對于運行應(yīng)用程序的操作系統(tǒng)帳號，不應(yīng)使用root、administrator、

35、supervisor等特權(quán)帳號或高級別權(quán)限帳號，應(yīng)該盡可能地使用低級別權(quán)限的操作系統(tǒng)帳號。規(guī)則3.4.5：對于應(yīng)用程序連接數(shù)據(jù)庫服務(wù)器的數(shù)據(jù)庫帳號，在滿足業(yè)務(wù)需求的前提下，必須使用最低級別權(quán)限的數(shù)據(jù)庫帳號。說明：根據(jù)業(yè)務(wù)系統(tǒng)要求，創(chuàng)建相應(yīng)的數(shù)據(jù)庫帳號，并授予必需的數(shù)據(jù)庫權(quán)限。不能使用sa、sysman等管理帳號或高級別權(quán)限帳號。3.5敏感數(shù)據(jù)保護3.5.1敏感數(shù)據(jù)定義敏感數(shù)據(jù)包括但不限于：口令、密鑰、證書、會話標(biāo)識、License、隱私數(shù)據(jù)（如短消息的內(nèi)容）、授權(quán)憑據(jù)、個人數(shù)據(jù)（如姓名、住址、電話等）等，在程序文件、配置文件、日志文件、備份文件及數(shù)據(jù)庫中都有可能包含敏感數(shù)據(jù)。3.5.2敏感數(shù)據(jù)

36、存儲規(guī)則：禁止在代碼中存儲敏感數(shù)據(jù)。說明：禁止在代碼中存儲如數(shù)據(jù)庫連接字符串、口令和密鑰之類的敏感數(shù)據(jù)，這樣容易導(dǎo)致泄密。用于加密密鑰的密鑰可以硬編碼在代碼中。規(guī)則：禁止密鑰或帳號的口令以明文形式存儲在數(shù)據(jù)庫或者文件中。說明：密鑰或帳號的口令必須經(jīng)過加密存儲。例外情況，如果Web容器的配置文件中只能以明文方式配置連接數(shù)據(jù)庫的用戶名和口令，那么就不用強制遵循該規(guī)則，將該配置文件的屬性改為只有屬主可讀寫。規(guī)則：禁止在 cookie 中以明文形式存儲敏感數(shù)據(jù)。說明：cookie信息容易被竊取，盡量不要在cookie中存儲敏感數(shù)據(jù)；如果條件限制必須使用cook

37、ie存儲敏感信息時，必須先對敏感信息加密再存儲到cookie。規(guī)則：禁止在隱藏域中存放明文形式的敏感數(shù)據(jù)。規(guī)則：禁止用自己開發(fā)的加密算法，必須使用公開、安全的標(biāo)準(zhǔn)加密算法。實施指導(dǎo)：場景 1：后臺服務(wù)端保存數(shù)據(jù)庫的登錄口令后臺服務(wù)器登錄數(shù)據(jù)庫需要使用登錄數(shù)據(jù)庫的明文口令，此時后臺服務(wù)器加密保存該口令后，下次登錄時需要還原成明文，因此，在這種情況下，不可用不可逆的加密算法，而需要使用對稱加密算法或者非對稱加密算法，一般也不建議采用非對稱加密算法。推薦的對稱加密算法：AES128、AES192、AES256。場景 2：后臺服務(wù)端保存用戶的登錄口令在該場景下，一般情況是：

38、客戶端提交用戶名及用戶口令，后臺服務(wù)端對用戶名及用戶口令進行驗證，然后返回驗證的結(jié)果。此時，在后臺服務(wù)端，用戶口令可以不需要還原，因此建議使用不可逆的加密算法，對用戶名+口令字符串進行加密。推薦的不可逆加密算法： SHA256、SHA384、SHA512，HMAC-SHA256、HMAC-SHA384、HMAC-SHA512。規(guī)則：禁止在日志中記錄明文的敏感數(shù)據(jù)。說明：禁止在日志中記錄明文的敏感數(shù)據(jù)（如口令、會話標(biāo)識jsessionid等），防止敏感信息泄漏。規(guī)則：禁止帶有敏感數(shù)據(jù)的Web頁面緩存。說明：帶有敏感數(shù)據(jù)的Web頁面都應(yīng)該禁止緩存，以防止敏感信息泄漏或通

39、過代理服務(wù)器上網(wǎng)的用戶數(shù)據(jù)互竄問題。實施指導(dǎo)：在HTML頁面的標(biāo)簽內(nèi)加入如下代碼：在JSP頁面的最前面加入如下代碼：注意：以上代碼對于采用強制緩存策略的代理服務(wù)器不生效（代理服務(wù)器默認(rèn)是不緩存的），要防止代理服務(wù)器緩存頁面，可以在鏈接后加入一個隨機數(shù)pageid,此時鏈接變成：http:/localhost:8080/query.do?a=2&pageid=, 其中數(shù)字是隨機生成的，每次請求此頁面時，隨機數(shù)都不同，IE始終認(rèn)為此為一個新請求，并重新解析，生成新的響應(yīng)頁面。3.5.3敏感數(shù)據(jù)傳輸規(guī)則：帶有敏感數(shù)據(jù)的表單必須使用 HTTP-POST 方法提交。說明：禁止使用 HTTP

40、-GET 方法提交帶有敏感數(shù)據(jù)的表單（form），因為該方法使用查詢字符串傳遞表單數(shù)據(jù)，易被查看、篡改。如果是使用servlet處理提交的表單數(shù)據(jù)，那么不在doGet方法中處理，只在doPost方法處理。實施指導(dǎo)：1. 對于JSP頁面，將表單的屬性method賦值為post，如下2. 如果是使用servlet處理提交的表單數(shù)據(jù)，那么只在doPost方法中處理，參考代碼如下public class ValidationServlet extends HttpServletpublic void doPost(HttpServletRequest request, HttpServletRespo

41、nse response) throws IOException, ServletException /對提交的表單數(shù)據(jù)進行校驗規(guī)則：在客戶端和服務(wù)器間傳遞明文的敏感數(shù)據(jù)時，必須使用帶服務(wù)器端證書的SSL。說明：如果在客戶端和服務(wù)器間傳遞如帳號、口令等明文的敏感數(shù)據(jù)，必須使用帶服務(wù)器端證書的SSL。由于SSL對服務(wù)端的CPU資源消耗很大，實施時必須考慮服務(wù)器的承受能力。實施指導(dǎo)：1. SSL的配置請參考附件1 Tomcat配置SSL指導(dǎo)。2. Web應(yīng)用中，從https切換到http過程中會丟失session，無法保持會話的連續(xù)。解決的辦法就是用http-https-http過程

42、代替https-http過程，保證會話的連續(xù)性。原因：當(dāng)https請求轉(zhuǎn)為http請求的時候，因為原先的session的secure屬性值是true，無法再http協(xié)議中傳輸，因此，系統(tǒng)生成新的session，且新的session沒有繼承舊session的屬性和值，因此，無法保持會話連續(xù)。而http-https-http這個過程，session始終不變，因此，可以保持會話連?規(guī)則：禁止在URL中攜帶會話標(biāo)識（如jsessionid）。說明：由于瀏覽器會保存URL歷史記錄，如果URL中攜帶會話標(biāo)識，則在多人共用的PC上會話標(biāo)識容易被其他人看到，一旦該會話標(biāo)識還在其生命有效期，則惡意

43、用戶可以冒充受害用戶訪問Web應(yīng)用系統(tǒng)。規(guī)則：禁止將對用戶保密的信息傳送到客戶端。說明：這些信息一旦傳送到客戶端，那么用戶也就可以獲取到了。3.6安全審計本節(jié)的安全審計是針對Web業(yè)務(wù)應(yīng)用，不包括對操作系統(tǒng)、Web容器的安全審計。對于操作系統(tǒng)和Web容器的安全審計，可以參考對應(yīng)的操作系統(tǒng)安全基線和Web安全配置規(guī)范。規(guī)則3.6.1：應(yīng)用服務(wù)器必須對安全事件及操作事件進行日志記錄。說明：安全事件包括登錄、注銷、添加、刪除、修改用戶、授權(quán)、取消權(quán)限、鑒權(quán)、修改用戶口令等；操作事件包括對業(yè)務(wù)系統(tǒng)配置參數(shù)的修改，對重要業(yè)務(wù)數(shù)據(jù)的創(chuàng)建、刪除、修改、查詢等；對于上述事件的結(jié)果，不管是成功還是

44、失敗，都需要記錄日志。規(guī)則3.6.2：安全日志必須包括但不限于如下內(nèi)容：事件發(fā)生的時間、事件類型、客戶端IP、客戶端機器名、當(dāng)前用戶的標(biāo)識、受影響的個體（數(shù)據(jù)、資源）、成功或失敗標(biāo)識、啟動該事件的進程標(biāo)識以及對該事件的詳細描述。規(guī)則3.6.3：嚴(yán)格限制對安全日志的訪問。說明：只有Web應(yīng)用程序的管理員才能查詢數(shù)據(jù)庫表形式或文件形式的安全日志；除數(shù)據(jù)庫超級管理員外，只有應(yīng)用程序連接數(shù)據(jù)庫的帳號可以查詢（select）及插入（insert）安全日志表；除操作系統(tǒng)超級管理員外，只有應(yīng)用程序的運行帳戶才能讀、寫文件形式的安全日志（但不允許刪除）。確保日志的安全，限制對日志的訪問，這加大了攻擊者篡改日志

45、文件以掩飾其攻擊行為的難度。規(guī)則3.6.4：對日志模塊占用資源必須有相應(yīng)的限制機制。說明：限制日志模塊占用的資源，以防止如自動的惡意登陸嘗試導(dǎo)致的資源枯竭類DOS攻擊；比如限制日志記錄占用的磁盤空間。規(guī)則3.6.5：禁止日志文件和操作系統(tǒng)存儲在同一個分區(qū)中，同時，應(yīng)使用轉(zhuǎn)儲、滾動、輪循機制，來防止存儲日志的分區(qū)寫滿。說明：所需空間和具體業(yè)務(wù)、局點容量、日志保存周期相關(guān)，要根據(jù)實際情況估算。建議3.6.1：安全日志應(yīng)該有備份及清理機制。說明：備份及清理機制包括定期備份及清理安全日志和監(jiān)控用于存放安全日志的磁盤空間的使用情況?？梢耘渲枚ㄆ趥浞菁扒謇淼臅r間，可以配置以用于存放安全日志的磁盤空間使用率

46、達到多少時進行備份及清理。建議3.6.2：通過網(wǎng)絡(luò)形式保存安全日志。說明：在生成安全日志時，即時將日志保存到網(wǎng)絡(luò)上其他主機，而且生成安全日志的應(yīng)用程序不能再訪問存放在其他主機的日志。3.7Web Service規(guī)則3.7.1：對Web Service接口的調(diào)用必須進行認(rèn)證。說明：認(rèn)證就是確定誰在調(diào)用Web Service，并且證實調(diào)用者身份。實施指導(dǎo)：可以通過在消息頭中增加用戶名和口令，作為認(rèn)證憑據(jù)；對于安全性要求不高、只向同一信任域內(nèi)其他主機開放的Web Service接口，可以通過簡單的IP認(rèn)證來實現(xiàn)接口的認(rèn)證（只有服務(wù)器端指定IP地址的客戶端才允許調(diào)用，IP地址可配置）。規(guī)則3.7.2：

47、如果調(diào)用者的權(quán)限各不相同，那么必須對Web Service接口的調(diào)用進行鑒權(quán)。說明：鑒權(quán)就是判斷調(diào)用者是否有權(quán)限調(diào)用該Web Service接口。實施指導(dǎo)：可以通過Axis的handler對調(diào)用進行鑒權(quán)。規(guī)則3.7.3：通過Web Service接口傳遞敏感數(shù)據(jù)時，必須保障其機密性。實施指導(dǎo)：方案1：請參考附件2 Web Service 安全接入開發(fā)指導(dǎo)。方案2：采用https安全協(xié)議。規(guī)則3.7.4：通過Web Service接口傳遞重要的交易數(shù)據(jù)時，必須保障其完整性和不可抵賴性。說明：重要的交易數(shù)據(jù)，如轉(zhuǎn)賬時涉及的轉(zhuǎn)入賬號、轉(zhuǎn)出賬號、金額等。實施指導(dǎo)：請參考附件2 Web Service

48、安全接入開發(fā)指導(dǎo)。規(guī)則3.7.5：如果Web Service只對特定的IP開放，那么必須對調(diào)用Web Service接口的客戶端IP進行鑒權(quán)，只有在IP地址白名單中的客戶端才允許調(diào)用，IP地址白名單可配置。實施指導(dǎo)：請參考附件3客戶端IP鑒權(quán)實施指導(dǎo)。規(guī)則3.7.6：對Web Service接口調(diào)用進行日志記錄。說明：日志內(nèi)容包括但不限于如下內(nèi)容：調(diào)用時間、操作類型、調(diào)用接口名稱、詳細的接口參數(shù)、客戶端IP、客戶端機器名、調(diào)用者的用戶標(biāo)識、受影響的個體（數(shù)據(jù)、資源）、成功或失敗標(biāo)識。規(guī)則3.7.7：必須對Web Service提交的參數(shù)進行輸入校驗。說明：具體輸入校驗部分請查看4.1輸入校驗。

49、3.8RESTful Web ServiceRESTful Web Service（也稱為 RESTful Web API）是一個使用HTTP并遵循REST原則的Web服務(wù)。規(guī)則3.8.1：對RESTful Web Service的調(diào)用必須進行認(rèn)證。說明：認(rèn)證就是確定誰在調(diào)用RESTful Web Service，并且證實調(diào)用者身份。實施指導(dǎo)：客戶端發(fā)起的Restful請求需要在消息頭帶Authorization字段，內(nèi)容填Basic Base64(user:pass)，服務(wù)端對user和passwd進行認(rèn)證。注意：user和pass必須加密保存在配置文件或數(shù)據(jù)庫中，不能寫死在代碼中；傳輸時采

50、用https安全協(xié)議。對于安全性要求不高、只向同一信任域內(nèi)其他主機開放的Web Service接口，可以通過簡單的IP認(rèn)證來實現(xiàn)接口的認(rèn)證（只有服務(wù)器端指定IP地址的客戶端才允許調(diào)用，IP地址可配置）。規(guī)則3.8.2：如果調(diào)用者的權(quán)限各不相同，那么必須對RESTful Web Service的調(diào)用進行鑒權(quán)。說明：鑒權(quán)就是判斷調(diào)用者是否有權(quán)限調(diào)用該RESTful Web Service。規(guī)則3.8.3：通過RESTful Web Service傳遞敏感數(shù)據(jù)時，必須保障其機密性。實施指導(dǎo)：采用https安全協(xié)議。規(guī)則3.8.4：如果RESTful Web Service只對特定的IP開放，那么必須

51、對調(diào)用RESTful Web Service的客戶端IP進行鑒權(quán)，只有在IP地址白名單中的客戶端才允許調(diào)用，IP地址白名單可配置。實施指導(dǎo)：請參考附件3客戶端IP鑒權(quán)實施指導(dǎo)。規(guī)則3.8.5：對RESTful Web Service調(diào)用進行日志記錄。說明：日志內(nèi)容包括但不限于如下內(nèi)容：調(diào)用時間、操作類型、調(diào)用接口名稱、詳細的接口參數(shù)、客戶端IP、客戶端機器名、調(diào)用者的用戶標(biāo)識、受影響的個體（數(shù)據(jù)、資源）、成功或失敗標(biāo)識。規(guī)則3.8.6：必須對RESTful Web Service提交的參數(shù)進行輸入校驗。說明：具體輸入校驗部分請查看4.1輸入校驗。3.9DWRDWR（Direct Web Rem

52、oting）是一種Java 和JavaScript 相結(jié)合的開源框架，可以幫助開發(fā)人員更容易地完成應(yīng)用Ajax 技術(shù)的Web 應(yīng)用程序，讓瀏覽器上的JavaScript 方法調(diào)用運行在Web 服務(wù)器上的Java 方法。規(guī)則3.9.1：關(guān)閉DWR 調(diào)試功能。說明：如果開啟了DWR調(diào)試功能，那么攻擊者可以輕易查看和調(diào)用系統(tǒng)提供的所有DWR接口，所以，版本發(fā)布時，一定要關(guān)閉DWR調(diào)試功能。實施指導(dǎo)：修改對應(yīng)的web.xml文件中的debug參數(shù)值為false：dwr-invokerorg.directwebremoting.servlet.DwrServletdebugfalse.規(guī)則3.9.2：對

53、DWR接口的調(diào)用必須進行認(rèn)證。說明：認(rèn)證就是確定誰在調(diào)用DWR接口，并且證實調(diào)用者身份。實施指導(dǎo)：對于DWR接口的認(rèn)證直接沿用3.2.2認(rèn)證機制，不用單獨再做認(rèn)證。規(guī)則3.9.3：對DWR接口的調(diào)用必須進行鑒權(quán)。說明：鑒權(quán)就是判斷調(diào)用者是否有權(quán)限調(diào)用該DWR接口。實施指導(dǎo)：DWR的請求和普通的Web請求一樣，都可以通過過濾器來鑒權(quán)，對于DWR接口的鑒權(quán)直接沿用規(guī)則3.4.1的鑒權(quán)機制，具體實現(xiàn)參照規(guī)則3.4.1的實施指導(dǎo)。規(guī)則3.9.4：必須對DWR提交的參數(shù)進行輸入校驗。說明：具體輸入校驗部分請查看4.1輸入校驗。4Web編程安全規(guī)范4.1輸入校驗規(guī)則4.1.1：必須對所有用戶產(chǎn)生的輸入進行

54、校驗，一旦數(shù)據(jù)不合法，應(yīng)該告知用戶輸入非法并且建議用戶糾正輸入。說明：用戶產(chǎn)生的輸入是指來自text、password、textareas或file表單域的數(shù)據(jù)；必須假定所有用戶產(chǎn)生的輸入都是不可信的，并對它們進行合法性校驗。規(guī)則4.1.2：必須對所有服務(wù)器產(chǎn)生的輸入進行校驗，一旦數(shù)據(jù)不合法，必須使會話失效，并記錄告警日志。說明：服務(wù)器產(chǎn)生的輸入是指除用戶產(chǎn)生的輸入以外的輸入，例如來自hidden fields、selection boxes、check boxes、radio buttons、cookies、HTTP headers、熱點鏈接包含的URL參數(shù)的數(shù)據(jù)或客戶端腳本等；必須假定所有服務(wù)器產(chǎn)生的輸入都是被篡改過的、惡意的，并對它們進行合法性校驗，如果不合法，說明有人惡意篡改數(shù)據(jù)。舉例：假如用戶資料填寫表單中的性別為必填項，用radio button（男和女對應(yīng)實際值分別為1和0）來限制用戶的輸入，如果應(yīng)用程序收到的性別值為2，那