華為技術(shù)有限公司內(nèi)部技術(shù)規(guī)范

65/65DKBA華為技術(shù)有限公司內(nèi)部技術(shù)規(guī)范DKBA1606-XXXX.XWeb應(yīng)用安全開發(fā)規(guī)范V1.52013年XX月XX日公布2013年XX月XX日實施華為技術(shù)有限公司HuaweiTechnologiesCo.,Ltd.版權(quán)所有侵權(quán)必究Allrightsreserved修訂聲明Revisiondeclaration本規(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ù)部安全能力基線》中的Web安全要求引用了本規(guī)范的內(nèi)容，假如存在沖突，以本規(guī)范為準。規(guī)范號要緊起草部門專家要緊評審部門專家修訂情況DKBA1606-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，傅用成30333，龔連陽18753，胡海60017320，胡海華52463，李誠37517，李大鋒54630，李戰(zhàn)杰21615，劉創(chuàng)文65632，劉飛46266，劉劍51690，欒陽62227，羅仁鈞65560，羅湘武06277，馬亮60009259，孟詠喜22499，潘海濤27360，孫林46580，王福40317，王錦亮36430，王美玲60011866，王謨磊65558，王玉龍24387，楊娟60019875，張鋒43381，張健60005645，張軼57143，鄒韜51591V1.0何偉祥33428劉高峰63564，龔連陽00129383，許汝波62966，吳宇翔00120395，王歡00104062，呂曉雨56987V1.2增加了WebService、Ajax和上傳和下載相關(guān)的安全規(guī)范。何偉祥00162822V1.3增加了防止會話固定和防止跨站請求偽造的安全規(guī)范。何偉祥00162822V1.4增加了“規(guī)則3.4.1”的實施指導；刪除了“建議3.4.1”；修改了“6配套CBB介紹”的內(nèi)容和獵取方式。增加了“3.9DWR”何偉祥00162822吳淑榮00197720魏建雄00222906謝和坤00197709李田00042091孫波00175839朱雙紅00051429王偉00207440陳偉00141500V1.5增加“規(guī)則3.3.9、規(guī)則3.6.5、規(guī)則4.7.1、建議4.7.2、4.8PHP”增加“3.8RESTfulWebService”修改“規(guī)則、規(guī)則、規(guī)則3.4.1、規(guī)則4.6.1”刪除“3.2.1口令策略”和“規(guī)則3.1.3、規(guī)則、規(guī)則4.7.1”附件文檔作為對象直接插入主文檔

目錄TableofContents1 概述 71.1 背景簡介 71.2 技術(shù)框架 81.3 使用對象 91.4 適用范圍 91.5 用詞約定 92 常見Web安全漏洞 103 Web設(shè)計安全規(guī)范 113.1 Web部署要求 113.2 身份驗證 123.2.1 口令 123.2.2 認證 123.2.3 驗證碼 153.3 會話治理 163.4 權(quán)限治理 173.5 敏感數(shù)據(jù)愛護 183.5.1 敏感數(shù)據(jù)定義 183.5.2 敏感數(shù)據(jù)存儲 183.5.3 敏感數(shù)據(jù)傳輸 203.6 安全審計 213.7 WebService 223.8 RESTfulWebService 233.9 DWR 244 Web編程安全規(guī)范 254.1 輸入校驗 254.2 輸出編碼 304.3 上傳下載 304.4 異常處理 314.5 代碼注釋 314.6 歸檔要求 324.7 其他 334.8 PHP 345 Web安全配置規(guī)范 366 配套CBB介紹 376.1 WAFCBB 376.2 驗證碼CBB 387 附件 387.1 附件1Tomcat配置SSL指導 387.2 附件2WebService安全接入開發(fā)指導 387.3 附件3客戶端IP鑒權(quán)實施指導 387.4 附件4口令安全要求 387.5 附件5Web權(quán)限治理設(shè)計規(guī)格講明書 39

Web應(yīng)用安全開發(fā)規(guī)范V1.5概述背景簡介在Internet大眾化及Web技術(shù)飛速演變的今天，Web安全所面臨的挑戰(zhàn)日益嚴峻。黑客攻擊技術(shù)越來越成熟和大眾化，針對Web的攻擊和破壞不斷增長，Web安全風險達到了前所未有的高度。許多程序員不明白如何開發(fā)安全的應(yīng)用程序，開發(fā)出來的Web應(yīng)用存在較多的安全漏洞，這些安全漏洞一旦被黑客利用將導致嚴峻甚至是災(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編程語言為例。技術(shù)框架典型的Web安全技術(shù)框架圖1顯示了典型的Web安全的技術(shù)框架和安全技術(shù)點，這些安全技術(shù)點，貫穿整個Web設(shè)計開發(fā)過程。上圖各個區(qū)域中存在任何一點薄弱環(huán)節(jié)，都容易導致安全漏洞。由于HTTP的開放性，Web應(yīng)用程序必須能夠通過某種形式的身份驗證來識不用戶，并確保身份驗證過程是安全的，同樣必須專門好地愛護用于跟蹤已驗證用戶的會話處理機制。為了防止一些惡意輸入，還要對輸入的數(shù)據(jù)和參數(shù)進行校驗。另外還要考慮Web系統(tǒng)的安全配置，敏感數(shù)據(jù)的愛護和用戶的權(quán)限治理，以及所有操作的安全審計。因此還要考慮代碼安全，以及其他方面的威脅。表1列出了一些Web缺陷類不，并針對每類缺陷列出了由于設(shè)計不當可能會導致的潛在問題。針對這些潛在的問題，本規(guī)范中有相應(yīng)的解決措施。Web應(yīng)用程序缺陷和由于不良設(shè)計可能導致的問題缺陷類不由于不良設(shè)計可能導致的問題身份驗證身份偽造、口令破解、權(quán)限提升和未授權(quán)訪問。會話治理通過捕獲導致會話劫持和會話偽造。權(quán)限治理訪問機密或受限數(shù)據(jù)、篡改和執(zhí)行未授權(quán)操作。配置治理未授權(quán)訪問治理界面、更新配置數(shù)據(jù)、訪問用戶帳戶和帳戶配置文件。敏感數(shù)據(jù)機密信息泄漏和數(shù)據(jù)篡改。加密技術(shù)未授權(quán)訪問機密數(shù)據(jù)或帳戶信息。安全審計未能識不入侵征兆、無法證明用戶的操作，以及在問題診斷中存在困難。輸入檢驗通過嵌入查詢字符串、窗體字段、Cookie和HTTP標頭中的惡意字符串所執(zhí)行的攻擊。包括命令執(zhí)行、跨站點腳本編寫(XSS)、SQL注入和緩沖區(qū)溢出攻擊等。參數(shù)操作路徑遍歷攻擊、命令執(zhí)行、此外還有躍過訪問操縱機制、導致信息泄露、權(quán)限提升和拒絕服務(wù)。異常治理拒絕服務(wù)和敏感的系統(tǒng)級詳細信息泄露。使用對象本規(guī)范的讀者及使用對象要緊為Web相關(guān)的需求分析人員、設(shè)計人員、開發(fā)人員、測試人員等。適用范圍本規(guī)范的制定考慮了公司各種Web應(yīng)用開發(fā)的共性，適合于公司絕大部分Web產(chǎn)品，要求Web產(chǎn)品開發(fā)必須遵循。關(guān)于嵌入式系統(tǒng)（如ADSLModem、硬件防火墻）中的Web應(yīng)用，由于其專門性（CPU、內(nèi)存、磁盤容量有限，沒有成熟的Web容器），不強制遵循本規(guī)范的所有內(nèi)容，只需遵循以下章節(jié)的規(guī)則要求：3.2身份驗證3.3會話治理3.5敏感數(shù)據(jù)愛護4.1輸入校驗4.2輸出編碼4.3上傳下載4.5代碼注釋4.6歸檔要求用詞約定規(guī)則：強制必須遵守的原則建議：需要加以考慮的原則講明：對此規(guī)則或建議進行相應(yīng)的解釋實施指導：對此規(guī)則或建議的實施進行相應(yīng)的指導常見Web安全漏洞Web應(yīng)用的安全漏洞有專門多，無法窮舉。針對眾多的Web漏洞，OWASP的專家們結(jié)合各自在各領(lǐng)域的應(yīng)用安全工作經(jīng)驗及智慧，提出了十大Web應(yīng)用程序安全漏洞，關(guān)心人們關(guān)注最嚴峻的漏洞。（OWASP即開放Web應(yīng)用安全項目，是一個旨在關(guān)心人們理解和提高Web應(yīng)用及服務(wù)安全性的項目組織。）十大Web應(yīng)用程序安全漏洞列表序號漏洞名稱漏洞描述1注入注入攻擊漏洞，例如SQL、OS命令以及LDAP注入。這些攻擊發(fā)生在當不可信的數(shù)據(jù)作為命令或者查詢語句的一部分，被發(fā)送給解釋器的時候。攻擊者發(fā)送的惡意數(shù)據(jù)能夠欺騙解釋器，以執(zhí)行打算外的命令或者訪問未被授權(quán)的數(shù)據(jù)。2跨站腳本當應(yīng)用程序收到含有不可信的數(shù)據(jù)，在沒有進行適當?shù)尿炞C和轉(zhuǎn)義的情況下，就將它發(fā)送給一個網(wǎng)頁掃瞄器，這就會產(chǎn)生跨站腳本攻擊（簡稱XSS）。XSS同意攻擊者在受害者的掃瞄器上執(zhí)行腳本，從而劫持用戶會話、危害網(wǎng)站、或者將用戶轉(zhuǎn)向至惡意網(wǎng)站。3失效的身份認證和會話治理與身份認證和會話治理相關(guān)的應(yīng)用程序功能往往得不到正確的實現(xiàn)，這就導致了攻擊者破壞密碼、密匙、會話令牌或攻擊其他的漏洞去冒充其他用戶的身份。4不安全的直接對象引用當開發(fā)人員暴露一個對內(nèi)部實現(xiàn)對象的引用時，例如，一個文件、目錄或者數(shù)據(jù)庫密匙，就會產(chǎn)生一個不安全的直接對象引用。在沒有訪問操縱檢測或其他愛護時，攻擊者會操控這些引用去訪問未授權(quán)數(shù)據(jù)。5跨站請求偽造一個跨站請求偽造攻擊迫使登錄用戶的掃瞄器將偽造的HTTP請求，包括該用戶的會話cookie和其他認證信息，發(fā)送到一個存在漏洞的Web應(yīng)用程序。這就同意了攻擊者迫使用戶掃瞄器向存在漏洞的應(yīng)用程序發(fā)送請求，而這些請求會被應(yīng)用程序認為是用戶的合法請求。6安全配置錯誤好的安全需要對應(yīng)用程序、框架、應(yīng)用程序服務(wù)器、Web服務(wù)器、數(shù)據(jù)庫服務(wù)器和平臺，定義和執(zhí)行安全配置。由于許多設(shè)置的默認值并不是安全的，因此，必須定義、實施和維護所有這些設(shè)置。這包括了對所有的軟件愛護及時地更新，包括所有應(yīng)用程序的庫文件。7失敗的URL訪問權(quán)限限制許多Web應(yīng)用程序在顯示受愛護的鏈接和按鈕之前會檢測URL訪問權(quán)限。然而，當這些頁面被訪問時，應(yīng)用程序也需要執(zhí)行類似的訪問操縱檢測，否則攻擊者將能夠偽裝這些URL去訪問隱藏的網(wǎng)頁。8未經(jīng)驗證的重定向和前轉(zhuǎn)Web應(yīng)用程序經(jīng)常將用戶重定向和前轉(zhuǎn)到其他網(wǎng)頁和網(wǎng)站，同時利用不可信的數(shù)據(jù)去判定目的頁面。假如沒有得到適當驗證，攻擊者能夠?qū)⑹芎τ脩糁囟ㄏ虻结烎~網(wǎng)站或惡意網(wǎng)站，或者使用前轉(zhuǎn)去訪問未經(jīng)授權(quán)的網(wǎng)頁。9不安全的加密存儲許多Web應(yīng)用程序并沒有使用恰當?shù)募用艽胧┗騂ash算法愛護敏感數(shù)據(jù)，比如信用卡、社會安全號碼（SSN）、認證憑據(jù)等。攻擊者可能利用這種弱愛護數(shù)據(jù)實行身份盜竊、信用卡欺騙或或其他犯罪。10傳輸層愛護不足應(yīng)用程序時常沒有身份認證、加密措施，甚至沒有愛護敏感網(wǎng)絡(luò)數(shù)據(jù)的保密性和完整性。而當進行愛護時，應(yīng)用程序有時采納弱算法、使用過期或無效的證書，或不正確地使用這些技術(shù)。Web設(shè)計安全規(guī)范Web部署要求規(guī)則3.1.1：假如Web應(yīng)用對Internet開放，Web服務(wù)器應(yīng)當置于DMZ區(qū)，在Web服務(wù)器與Internet之間，Web服務(wù)器與內(nèi)網(wǎng)之間應(yīng)當有防火墻隔離，并設(shè)置合理的策略。規(guī)則3.1.2：假如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)用的安全性。建議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：關(guān)于“客戶服務(wù)”和“治理”類的訪問，除了一般的認證，還應(yīng)該增加額外的訪問限制。講明：額外的訪問限制，能夠限制請求來自企業(yè)內(nèi)網(wǎng)，能夠建立VPN，或采納雙向認證的SSL；或采納更簡單的方法，通過IP地址白名單對客戶端的IP地址進行過濾推斷，實施參考《附件3客戶端IP鑒權(quán)實施指導》。身份驗證口令關(guān)于Web應(yīng)用及容器涉及到的口令，請遵循《產(chǎn)品網(wǎng)絡(luò)安全紅線》的口令安全要求（詳細內(nèi)容請見：附件4口令安全要求.xlsx）。認證規(guī)則：對用戶的最終認證處理過程必須放到應(yīng)用服務(wù)器進行講明：不同意僅僅通過腳本或其他形式在客戶端進行驗證，必須在應(yīng)用服務(wù)器進行最終認證處理（假如采納集中認證，那么對用戶的最終認證確實是放在集中認證服務(wù)器進行）。規(guī)則：網(wǎng)頁上的登錄/認證表單必須加入驗證碼講明：使用驗證碼的目的是為了阻止攻擊者使用自動登錄工具連續(xù)嘗試登錄，從而降低被暴力破解的可能。假如覺得驗證碼阻礙用戶體驗，那么能夠在前3次登錄嘗試中不使用驗證碼，3次登錄失敗后必須使用驗證碼。驗證碼在設(shè)計上必須要考慮到一些安全因素，以免能被輕易地破解。具體實現(xiàn)細節(jié)請查看REF_Ref194458552\r\h3.2.3REF_Ref194458577\h驗證碼。如圖：驗證碼實施指導：建議使用電信軟件與核心網(wǎng)網(wǎng)絡(luò)安全工程部提供的驗證碼CBB。備注：關(guān)于嵌入式系統(tǒng)，假如實現(xiàn)驗證碼比較困難，能夠通過多次認證失敗鎖定客戶端IP的方式來防止暴力破解。規(guī)則：用戶名、密碼和驗證碼必須在同一個請求中提交給服務(wù)器，必須先推斷驗證碼是否正確，只有當驗證碼檢驗通過后才進行用戶名和密碼的檢驗，否則直接提示驗證碼錯誤。講明：假如驗證碼和用戶名、密碼分開提交，攻擊者就能夠繞過驗證碼校驗（如：先手工提交正確的驗證碼，再通過程序暴力破解），驗證碼就形同虛設(shè)，攻擊者依舊能夠暴力破解用戶名及口令。規(guī)則：所有登錄頁面的認證處理模塊必須統(tǒng)一講明：能夠存在多個登錄頁面，然而不同意存在多個可用于處理登錄認證請求的模塊，防止不一致的認證方式。規(guī)則：所有針對其他第三方開放接口的認證處理模塊必須統(tǒng)一。規(guī)則：認證處理模塊必須對提交的參數(shù)進行合法性檢查。講明：具體輸入校驗部分請查看4.1輸入校驗。規(guī)則：認證失敗后，不能提示給用戶詳細以及明確的錯誤緣故，只能給出一般性的講明：能夠提示：“用戶名或者口令錯誤，登錄失敗”；不能提示：“用戶名不存在”、“口令必須是6位”等等。規(guī)則：最終用戶portal和治理portal分離。講明：最終用戶portal和治理portal分離，防止相互阻礙，防止來自用戶面的攻擊阻礙治理面。實施指導：將最終用戶portal和治理portal分不部署在不同的物理服務(wù)器；假如為了解決成本合設(shè)（部署在同一臺物理服務(wù)器上），那么，必須做到端口分離（通過不同的端口提供Web服務(wù)），一般的Web容器（如tomcat）支持為不同的Web應(yīng)用創(chuàng)建不同的端口。規(guī)則：禁止在系統(tǒng)中預留任何的后門帳號或?qū)ｉT的訪問機制。規(guī)則0：關(guān)于重要的治理事務(wù)或重要的交易事務(wù)要進行重新認證，以防范會話劫持和跨站請求偽造給用戶帶來損失。講明：重要的治理事務(wù)，比如重新啟動業(yè)務(wù)模塊；重要的交易事務(wù)，比如轉(zhuǎn)賬、余額轉(zhuǎn)移、充值等。重新認證，比如讓用戶重新輸入口令。規(guī)則1：用戶名和密碼認證通過后，必須更換會話標識，以防止會話固定（sessionfixation）漏洞。實施指導：場景一：關(guān)于從HTTP轉(zhuǎn)到HTTPS再轉(zhuǎn)到HTTP（也確實是僅在認證過程采納HTTPS，認證成功后又轉(zhuǎn)到HTTP）的，在用戶名和密碼認證通過后增加以下行代碼： request.getSession().invalidate(); HttpSessionnewSession=request.getSession(true); Cookiecookie=newCookie("JSESSIONID",newSession.getId()); cookie.setMaxAge(-1); cookie.setSecure(false); cookie.setPath(request.getContextPath()); response.addCookie(cookie);場景二：關(guān)于全程采納HTTPS協(xié)議，或者全程采納HTTP協(xié)議的，在用戶名和密碼認證通過后增加以下行代碼： request.getSession().invalidate(); request.getSession(true);建議：治理頁面建議實施強身份認講明：如雙因素認證、SSL雙向證書認證、生物認證等；還能夠通過應(yīng)用程序限制只同意某些特定的IP地址訪問治理頁面，同時這些特定的IP地址可配置。建議：同一客戶端在多次連續(xù)嘗試登錄失敗后，服務(wù)端需要進行用戶帳號或者是客戶端所在機器的IP地址的鎖定策略，且該鎖定策略必須設(shè)置解鎖時長，超時后自動解鎖。講明：登錄失敗應(yīng)該提示用戶：假如重試多少次不成功系統(tǒng)將會鎖定。在鎖定期間不同意該用戶帳號（或者客戶端所在機器的IP地址）登錄。同意連續(xù)失敗的次數(shù)（指從最后一次成功以來失敗次數(shù)的累計值）可配置，取值范圍為：0-99次，0表示不執(zhí)行鎖定策略，建議默認：5次。鎖定時長的取值范圍為：0-999分鐘，建議默認：30分鐘，當取值為0時，表示無限期鎖定，只能通過治理員手動解鎖（需要提供治理員對服務(wù)器鎖定其它用戶帳號/IP進行解鎖的功能界面）。建議優(yōu)先使用帳號鎖定策略。注意：應(yīng)用程序的超級用戶帳號不能被鎖定，只能鎖定操作的客戶端所在的IP，這是為了防止系統(tǒng)不可用。特不講明：鎖客戶端IP策略存在缺陷，當用戶使用proxy上網(wǎng)時，那么鎖定客戶端IP會導致使用該proxy上網(wǎng)的所有用戶在IP鎖定期間都不能使用該Web應(yīng)用；鎖定用戶帳戶的策略也存在缺陷，當攻擊者不斷嘗試某帳戶的口令，就給該帳戶帶來拒絕服務(wù)攻擊，使該帳戶不可用。驗證碼規(guī)則：驗證碼必須是單一圖片，且只能采納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)頁上點擊鼠標右鍵、選擇“查看源文件”時，必須看不到驗證碼模塊生成的隨機數(shù)。規(guī)則：驗證碼字符串要求是隨機生成，生成的講明：關(guān)于java語言能夠使用類java.security.SecureRandom來生成安全的隨機數(shù)。規(guī)則：驗證碼要求有背景干擾，背景干擾元素的顏色、位置、數(shù)量要求隨機變化規(guī)則：驗證碼在一次使用后要求立即失效，新的請求講明：進行驗證碼校驗后，立立即會話中的驗證碼信息清空，而不是等到生成新的驗證碼時再去覆蓋舊的驗證碼，防止驗證碼多次有效；注意：當客戶端提交的驗證碼為空，驗證不通過。講明：以上規(guī)則能夠通過使用電信軟件與核心網(wǎng)網(wǎng)絡(luò)安全工程部提供的驗證碼CBB來實現(xiàn)。會話治理規(guī)則3.3.1：使用會話cookie維持會話。講明：目前主流的Web容器通過以下幾種方式維持會話：隱藏域、URL重寫、持久性cookie、會話cookie，但通過隱藏域、URL重寫或持久性cookie方式維持的會話容易被竊取，因此要求使用會話cookie維持會話。假如條件限制必須通過持久性cookie維持會話的話，那么cookie信息中的重要數(shù)據(jù)部分如身份信息、計費信息等都必須進行加密。（cookie有兩種：會話cookie和持久性cookie；會話cookie，也確實是非持久性cookie，不設(shè)置過期時刻，其生命期為掃瞄器會話期間，只要關(guān)閉掃瞄器窗口，cookie就消逝了；會話cookie一般不存儲在硬盤上而是保存在內(nèi)存里。持久性cookie，設(shè)置了過期時刻，被掃瞄器保存到硬盤上，關(guān)閉后再次打開掃瞄器，持久性cookie仍然有效直到超過設(shè)定的過期時刻。）備注：關(guān)于嵌入式系統(tǒng)的Web，不適合本條規(guī)則，按“規(guī)則3.3.9”實施。規(guī)則3.3.2：會話過程中不同意修改的信息，必須作為會話狀態(tài)的一部分在服務(wù)器端存儲和維護講明：會話過程中不同意修改的信息，例如，當用戶通過認證后，其用戶標識在整個會話過程中不能被篡改。禁止通過隱藏域或URL重寫等不安全的方式存儲和維護。對JSP語言，確實是應(yīng)該通過session對象進行存儲和維護。規(guī)則3.3.3：當Web應(yīng)用跟蹤到非法會話，則必須記錄日志、清除會話講明：非法會話的概念確實是通過一系列的服務(wù)端合法性檢測（包括訪問未授權(quán)資源，缺少必要參數(shù)等情況），最終發(fā)覺的不是正常請求產(chǎn)生的會話。規(guī)則3.3.4：講明：防止會話信息被篡改，如惡意用戶通過URL篡改手機號碼等。規(guī)則3.3.5：講明：防止遺留在內(nèi)存中的會話信息被竊取，減少內(nèi)存占用。實施指導：關(guān)于JSP或java語言使用如下語句：request.getSession().invalidate();規(guī)則3.3.6：必須設(shè)置會話超時機制，在超時過后必須要清除該會話信息講明：建議默認會話超時時刻為10分鐘（備注：關(guān)于嵌入式系統(tǒng)中的Web，建議默認超時時刻為5分鐘，以減少系統(tǒng)資源占用）。假如沒有專門需求，禁止使用自動發(fā)起請求的機制來阻止session超時。規(guī)則3.3.7：講明：客戶端流程操縱專門容易被旁路（繞過），因此流程操縱必須在服務(wù)器端實現(xiàn)。實施指導：能夠通過在session對象中創(chuàng)建一個表示流程當前狀態(tài)的標識位，用0、1、2、3、…、N分不表示不同的處理步驟，標識位的初始值為0，當接收到步驟N的處理請求時，推斷該標識位是否為N-1，假如不為N-1，則表示步驟被繞過（或重復或亂序），拒絕受理，否則受理，受理完成后更改標識位為N。規(guī)則3.3.8：所有登錄后才能訪問的頁面都必須有明顯的“注銷（或退出）”的按鈕或菜單，假如該按鈕或菜單被點擊，則必須使對應(yīng)的會話立即失效講明：如此做是為了讓用戶能夠方便地、安全地注銷或退出，減小會話劫持的風險。規(guī)則3.3.9：假如產(chǎn)品（如嵌入式系統(tǒng)）無法使用通用的Web容器，只能自己實現(xiàn)Web服務(wù)，那么必須自己實現(xiàn)會話治理，并滿足以下要求：采納會話cookie維持會話。生成會話標識（sessionID）要保證足夠的隨機、離散，以便不能被推測、枚舉，要求sessionID要至少要32字節(jié)，要支持字母和數(shù)字字符集。服務(wù)端必須對客戶端提交的sessionID的有效性進行校驗。講明：在嵌入式系統(tǒng)中部署Web應(yīng)用，由于軟硬件資源所限，往往無法使用通用的Web容器及容器的會話治理功能，只能自己實現(xiàn)。另外，為了節(jié)約內(nèi)存，嵌入式webserver進程往往是動態(tài)啟動，為了使session更快的超時，建議增加心跳機制，對客戶端掃瞄器是否關(guān)閉進行探測，5s一個心跳，30s沒有心跳則session超時，關(guān)閉該session。權(quán)限治理規(guī)則3.4.1：關(guān)于每一個需要授權(quán)訪問的頁面或servlet的請求都講明：防止用戶通過直接輸入URL，越權(quán)請求并執(zhí)行一些頁面或servlet；建議通過過濾器實現(xiàn)。實施指導：請參考“附件5Web權(quán)限治理設(shè)計規(guī)格講明書.docx”。規(guī)則3.4.2：授權(quán)和用戶角色數(shù)據(jù)必須存放在服務(wù)器端，不能存放在客戶端，鑒權(quán)處理也必須在服務(wù)器端完成講明：禁止將授權(quán)和角色數(shù)據(jù)存放在客戶端中（比如cookie或隱藏域中），以防止被篡改。規(guī)則3.4.3：一個帳號只能擁有必需的角色和必需的權(quán)限。一個組只能擁有必需的角色和必需的權(quán)限。一個角色只能擁有必需的權(quán)限講明：做到權(quán)限最小化和職責分離（職責分離確實是分清帳號角色，系統(tǒng)治理帳號只用于系統(tǒng)治理，審計帳號只用于審計，操作員帳號只用于業(yè)務(wù)維護操作，一般用戶帳號只能使用業(yè)務(wù)。）如此即使帳號被攻擊者盜取，也能把安全損失操縱在最小的限度。規(guī)則3.4.4：關(guān)于運行應(yīng)用程序的操作系統(tǒng)帳號，不應(yīng)使用“root”、“administrator”、“supervisor”等特權(quán)帳號或高級不權(quán)限帳號，應(yīng)該盡可能地使用低級不權(quán)限的操作系統(tǒng)帳號規(guī)則3.4.5：關(guān)于應(yīng)用程序連接數(shù)據(jù)庫服務(wù)器的數(shù)據(jù)庫帳號，在滿足業(yè)務(wù)需求的前提下，必須使用最低級不權(quán)限的數(shù)據(jù)庫帳號講明：依照業(yè)務(wù)系統(tǒng)要求，創(chuàng)建相應(yīng)的數(shù)據(jù)庫帳號，并授予必需的數(shù)據(jù)庫權(quán)限。不能使用“sa”、“sysman”等治理帳號或高級不權(quán)限帳號。敏感數(shù)據(jù)愛護敏感數(shù)據(jù)定義敏感數(shù)據(jù)包括但不限于：口令、密鑰、證書、會話標識、License、隱私數(shù)據(jù)（如短消息的內(nèi)容）、授權(quán)憑據(jù)、個人數(shù)據(jù)（如姓名、住址、電話等）等，在程序文件、配置文件、日志文件、備份文件及數(shù)據(jù)庫中都有可能包含敏感數(shù)據(jù)。敏感數(shù)據(jù)存儲規(guī)則：禁止在代碼中存儲敏感數(shù)據(jù)。講明：禁止在代碼中存儲如數(shù)據(jù)庫連接字符串、口令和密鑰之類的敏感數(shù)據(jù)，如此容易導致泄密。用于加密密鑰的密鑰能夠硬編碼在代碼中。規(guī)則：禁止密鑰或帳號的口令以明文形式存儲在數(shù)據(jù)庫或者文件中。講明：密鑰或帳號的口令必須通過加密存儲。例外情況，假如Web容器的配置文件中只能以明文方式配置連接數(shù)據(jù)庫的用戶名和口令，那么就不用強制遵循該規(guī)則，將該配置文件的屬性改為只有屬主可讀寫。規(guī)則：禁止在cookie中以明文形式存儲敏感數(shù)據(jù)。講明：cookie信息容易被竊取，盡量不要在cookie中存儲敏感數(shù)據(jù)；假如條件限制必須使用cookie存儲敏感信息時，必須先對敏感信息加密再存儲到cookie。規(guī)則：禁止在隱藏域中存放明文形式的敏感數(shù)據(jù)。規(guī)則：實施指導：場景1：后臺服務(wù)端保存數(shù)據(jù)庫的登錄口令后臺服務(wù)器登錄數(shù)據(jù)庫需要使用登錄數(shù)據(jù)庫的明文口令，現(xiàn)在后臺服務(wù)器加密保存該口令后，下次登錄時需要還原成明文，因此，在這種情況下，不可用不可逆的加密算法，而需要使用對稱加密算法或者非對稱加密算法，一般也不建議采納非對稱加密算法。推舉的對稱加密算法：AES128、AES192、AES256。場景2：后臺服務(wù)端保存用戶的登錄口令在該場景下，一般情況是：客戶端提交用戶名及用戶口令，后臺服務(wù)端對用戶名及用戶口令進行驗證，然后返回驗證的結(jié)果。現(xiàn)在，在后臺服務(wù)端，用戶口令能夠不需要還原，因此建議使用不可逆的加密算法，對“用戶名+口令”字符串進行加密。推舉的不可逆加密算法：SHA256、SHA384、SHA512，HMAC-SHA256、HMAC-SHA384、HMAC-SHA512。規(guī)則：禁止在日志中記錄明文的敏感數(shù)據(jù)。講明：禁止在日志中記錄明文的敏感數(shù)據(jù)（如口令、會話標識jsessionid等），防止敏感信息泄漏。規(guī)則：禁止帶有敏感數(shù)據(jù)的Web頁面緩存。講明：帶有敏感數(shù)據(jù)的Web頁面都應(yīng)該禁止緩存，以防止敏感信息泄漏或通過代理服務(wù)器上網(wǎng)的用戶數(shù)據(jù)互竄問題。實施指導：在HTML頁面的<HEAD>標簽內(nèi)加入如下代碼：<HEAD><METAHTTP-EQUIV="Expires"CONTENT="0"><METAHTTP-EQUIV="Pragma"CONTENT="no-cache"><METAHTTP-EQUIV="Cache-control"CONTENT="no-cache"><METAHTTP-EQUIV="Cache"CONTENT="no-cache"></HEAD>在JSP頁面的最前面加入如下代碼：<%response.setHeader("Cache-Control","no-cache");response.setHeader("Pragma","no-cache");response.setDateHeader("Expires",0);%>注意：以上代碼關(guān)于采納強制緩存策略的代理服務(wù)器不生效（代理服務(wù)器默認是不緩存的），要防止代理服務(wù)器緩存頁面，能夠在鏈接后加入一個隨機數(shù)pageid,現(xiàn)在鏈接變成：http://localhost:8080/query.do?a=2&pageid=2245562,其中2245562數(shù)字是隨機生成的，每次請求此頁面時，隨機數(shù)都不同，IE始終認為此為一個新請求，并重新解析，生成新的響應(yīng)頁面。敏感數(shù)據(jù)傳輸規(guī)則：帶有敏感數(shù)據(jù)的表單必須使用HTTP-POST方法提交講明：禁止使用HTTP-GET方法提交帶有敏感數(shù)據(jù)的表單（form），因為該方法使用查詢字符串傳遞表單數(shù)據(jù)，易被查看、篡改。假如是使用servlet處理提交的表單數(shù)據(jù)，那么不在doGet方法中處理，只在doPost方法處理。實施指導：1.關(guān)于JSP頁面，將表單的屬性method賦值為"post"，如下<formname="form1"method="post"action="switch.jsp">2.假如是使用servlet處理提交的表單數(shù)據(jù)，那么只在doPost方法中處理，參考代碼如下publicclassValidationServletextendsHttpServlet{publicvoiddoPost(HttpServletRequestrequest,HttpServletResponseresponse)throwsIOException,ServletException{//對提交的表單數(shù)據(jù)進行校驗}}規(guī)則：在客戶端和服務(wù)器間傳遞明文的敏感數(shù)據(jù)時，必須使用帶服務(wù)器端證書的SSL。講明：假如在客戶端和服務(wù)器間傳遞如帳號、口令等明文的敏感數(shù)據(jù)，必須使用帶服務(wù)器端證書的SSL。由于SSL對服務(wù)端的CPU資源消耗專門大，實施時必須考慮服務(wù)器的承受能力。實施指導：1.SSL的配置請參考《附件1Tomcat配置SSL指導》。2.Web應(yīng)用中，從https切換到http過程中會丟失session，無法保持會話的連續(xù)。解決的方法確實是用http-https-http過程代替https-http過程，保證會話的連續(xù)性。緣故：當https請求轉(zhuǎn)為http請求的時候，因為原先的session的secure屬性值是true，無法再http協(xié)議中傳輸，因此，系統(tǒng)生成新的session，且新的session沒有繼承舊session的屬性和值，因此，無法保持會話連續(xù)。而http-https-http那個過程，session始終不變，因此，能夠保持會話連續(xù)。規(guī)則：禁止在URL中攜帶會話標識（如jsessionid）。講明：由于掃瞄器會保存URL歷史記錄，假如URL中攜帶會話標識，則在多人共用的PC上會話標識容易被其他人看到，一旦該會話標識還在其生命有效期，則惡意用戶能夠冒充受害用戶訪問Web應(yīng)用系統(tǒng)。規(guī)則：禁止將對用戶保密的信息傳送到客戶端。講明：這些信息一旦傳送到客戶端，那么用戶也就能夠獵取到了。安全審計本節(jié)的安全審計是針對Web業(yè)務(wù)應(yīng)用，不包括對操作系統(tǒng)、Web容器的安全審計。關(guān)于操作系統(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)建、刪除、修改、查詢等；關(guān)于上述事件的結(jié)果，不管是成功依舊失敗，都需要記錄日志。規(guī)則3.6.2：安全日志必須包括但不限于如下內(nèi)容：事件發(fā)生的時刻、事件類型、客戶端IP、客戶端機器名、當前用戶的標識、受阻礙的個體（數(shù)據(jù)、資源）、成功或失敗標識、啟動該事件的進程標識以及對該事件的詳細描述。規(guī)則3.6.3：講明：只有Web應(yīng)用程序的治理員才能查詢數(shù)據(jù)庫表形式或文件形式的安全日志；除數(shù)據(jù)庫超級治理員外，只有應(yīng)用程序連接數(shù)據(jù)庫的帳號能夠查詢（select）及插入（insert）安全日志表；除操作系統(tǒng)超級治理員外，只有應(yīng)用程序的運行帳戶才能讀、寫文件形式的安全日志（但不同意刪除）。確保日志的安全，限制對日志的訪問，這加大了攻擊者篡改日志文件以掩飾其攻擊行為的難度。規(guī)則3.6.4：對日志模塊占用資源必須有相應(yīng)的限制機制。講明：限制日志模塊占用的資源，以防止如自動的惡意登陸嘗試導致的資源枯竭類DOS攻擊；比如限制日志記錄占用的磁盤空間。規(guī)則3.6.5：禁止日志文件和操作系統(tǒng)存儲在同一個分區(qū)中，同時，應(yīng)使用轉(zhuǎn)儲、滾動、輪循機制，來防止存儲日志的分區(qū)寫滿。講明：所需空間和具體業(yè)務(wù)、局點容量、日志保存周期相關(guān)，要依照實際情況估算。建議3.6.1：講明：備份及清理機制包括定期備份及清理安全日志和監(jiān)控用于存放安全日志的磁盤空間的使用情況。能夠配置定期備份及清理的時刻，能夠配置以用于存放安全日志的磁盤空間使用率達到多少時進行備份及清理。建議3.6.2：講明：在生成安全日志時，即時將日志保存到網(wǎng)絡(luò)上其他主機，而且生成安全日志的應(yīng)用程序不能再訪問存放在其他主機的日志。WebService規(guī)則3.7.1：對WebService接口的調(diào)用必須進行認證。講明：認證確實是確定誰在調(diào)用WebService，同時證實調(diào)用者身份。實施指導：能夠通過在消息頭中增加用戶名和口令，作為認證憑據(jù)；關(guān)于安全性要求不高、只向同一信任域內(nèi)其他主機開放的WebService接口，能夠通過簡單的IP認證來實現(xiàn)接口的認證（只有服務(wù)器端指定IP地址的客戶端才同意調(diào)用，IP地址可配置）。規(guī)則3.7.2：假如調(diào)用者的權(quán)限各不相同，那么必須對WebService接口的調(diào)用進行鑒權(quán)。講明：鑒權(quán)確實是推斷調(diào)用者是否有權(quán)限調(diào)用該WebService接口。實施指導：能夠通過Axis的handler對調(diào)用進行鑒權(quán)。規(guī)則3.7.3：通過WebService接口傳遞敏感數(shù)據(jù)時，必須保障其機密性。實施指導：方案1：請參考《附件2WebService安全接入開發(fā)指導》。方案2：采納https安全協(xié)議。規(guī)則3.7.4：通過WebService接口傳遞重要的交易數(shù)據(jù)時，必須保障其完整性和不可抵賴性講明：重要的交易數(shù)據(jù)，如轉(zhuǎn)賬時涉及的“轉(zhuǎn)入賬號”、“轉(zhuǎn)出賬號”、“金額”等。實施指導：請參考《附件2WebService安全接入開發(fā)指導》。規(guī)則3.7.5：假如WebService只對特定的IP開放，那么必須對調(diào)用WebService接口的客戶端IP進行鑒權(quán)，只有在IP地址白名單中的客戶端才同意調(diào)用，IP地址白名單可配置實施指導：請參考《附件3客戶端IP鑒權(quán)實施指導》。規(guī)則3.7.6：對WebService接口調(diào)用進行日志記錄。講明：日志內(nèi)容包括但不限于如下內(nèi)容：調(diào)用時刻、操作類型、調(diào)用接口名稱、詳細的接口參數(shù)、客戶端IP、客戶端機器名、調(diào)用者的用戶標識、受阻礙的個體（數(shù)據(jù)、資源）、成功或失敗標識。規(guī)則3.7.7：必須對WebService提交的參數(shù)進行輸入校驗。講明：具體輸入校驗部分請查看4.1輸入校驗。RESTfulWebServiceRESTfulWebService（也稱為RESTfulWebAPI）是一個使用HTTP并遵循REST原則的Web服務(wù)。規(guī)則3.8.1：對RESTfulWebService的調(diào)用必須進行認證。講明：認證確實是確定誰在調(diào)用RESTfulWebService，同時證實調(diào)用者身份。實施指導：客戶端發(fā)起的Restful請求需要在消息頭帶Authorization字段，內(nèi)容填BasicBase64(user:pass)，服務(wù)端對user和passwd進行認證。注意：user和pass必須加密保存在配置文件或數(shù)據(jù)庫中，不能寫死在代碼中；傳輸時采納https安全協(xié)議。關(guān)于安全性要求不高、只向同一信任域內(nèi)其他主機開放的WebService接口，能夠通過簡單的IP認證來實現(xiàn)接口的認證（只有服務(wù)器端指定IP地址的客戶端才同意調(diào)用，IP地址可配置）。規(guī)則3.8.2：假如調(diào)用者的權(quán)限各不相同，那么必須對RESTfulWebService的調(diào)用進行鑒權(quán)。講明：鑒權(quán)確實是推斷調(diào)用者是否有權(quán)限調(diào)用該RESTfulWebService。規(guī)則3.8.3：通過RESTfulWebService傳遞敏感數(shù)據(jù)時，必須保障其機密性。實施指導：采納https安全協(xié)議。規(guī)則3.8.4：假如RESTfulWebService只對特定的IP開放，那么必須對調(diào)用RESTfulWebService的客戶端IP進行鑒權(quán)，只有在IP地址白名單中的客戶端才同意調(diào)用，IP地址白名單可配置。實施指導：請參考《附件3客戶端IP鑒權(quán)實施指導》。規(guī)則3.8.5：對RESTfulWebService調(diào)用進行日志記錄。講明：日志內(nèi)容包括但不限于如下內(nèi)容：調(diào)用時刻、操作類型、調(diào)用接口名稱、詳細的接口參數(shù)、客戶端IP、客戶端機器名、調(diào)用者的用戶標識、受阻礙的個體（數(shù)據(jù)、資源）、成功或失敗標識。規(guī)則3.8.6：必須對RESTfulWebService提交的參數(shù)進行輸入校驗。講明：具體輸入校驗部分請查看4.1輸入校驗。DWRDWR（DirectWebRemoting）是一種Java和JavaScript相結(jié)合的開源框架，能夠關(guān)心開發(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接口，因此，版本公布時，一定要關(guān)閉DWR調(diào)試功能。實施指導：修改對應(yīng)的web.xml文件中的debug參數(shù)值為false：<servlet><servlet-name>dwr-invoker</servlet-name><servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class><init-param><param-name>debug</param-name><param-value>false</param-value></init-param>規(guī)則3.9.2：對DWR接口的調(diào)用必須進行認證。講明：認證確實是確定誰在調(diào)用DWR接口，同時證實調(diào)用者身份。實施指導：關(guān)于DWR接口的認證直接沿用3.2.2認證機制，不用單獨再做認證。規(guī)則3.9.3：對DWR接口的調(diào)用必須進行鑒權(quán)。講明：鑒權(quán)確實是推斷調(diào)用者是否有權(quán)限調(diào)用該DWR接口。實施指導：DWR的請求和一般的Web請求一樣，都能夠通過過濾器來鑒權(quán)，關(guān)于DWR接口的鑒權(quán)直接沿用規(guī)則3.4.1的鑒權(quán)機制，具體實現(xiàn)參照規(guī)則3.4.1的實施指導。規(guī)則3.9.4：必須對DWR提交的參數(shù)進行輸入校驗。講明：具體輸入校驗部分請查看4.1輸入校驗。Web編程安全規(guī)范輸入校驗規(guī)則4.1.1：必須對所有用戶產(chǎn)生的輸入進行校驗，一旦數(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)生的輸入以外的輸入，例如來自hiddenfields、selectionboxes、checkboxes、radiobuttons、cookies、HTTPheaders、熱點鏈接包含的URL參數(shù)的數(shù)據(jù)或客戶端腳本等；必須假定所有服務(wù)器產(chǎn)生的輸入差不多上被篡改過的、惡意的，并對它們進行合法性校驗，假如不合法，講明有人惡意篡改數(shù)據(jù)。舉例：假如用戶資料填寫表單中的“性不”為必填項，用radiobutton（‘男’和‘女’對應(yīng)實際值分不為‘1’和‘0’）來限制用戶的輸入，假如應(yīng)用程序收到的“性不”值為‘2’，那么能夠斷定有人惡意篡改數(shù)據(jù)。規(guī)則4.1.3：禁止將HTTP標題頭中的任何未加密信息作為安全決策依據(jù)講明：HTTP標題頭是在HTTP請求和HTTP響應(yīng)的開始時期發(fā)送的。Web應(yīng)用程序必須確保不以HTTP標題頭中的任何未加密信息作為安全決策依據(jù)，因為攻擊者要操作這一標題頭是專門容易的。例如，標題頭中的referer字段包含來自請求源端的Web頁面的URL。不要依照referer字段的值做出任何安全決策（如檢查請求是否來源于Web應(yīng)用程序生成的頁面），因為該字段是專門容易被偽造的。規(guī)則4.1.4：不能依靠于客戶端校驗，必須使用服務(wù)端代碼講明：客戶端的校驗只能作為輔助手段，減少客戶端和服務(wù)端的信息交互次數(shù)。規(guī)則4.1.5：關(guān)于在客戶端差不多做了輸入校驗，在服務(wù)器端再次以相同的規(guī)則講明：確信存在攻擊行為，攻擊者繞過了客戶端的輸入校驗，因此必須使會話失效，并記入告警日志。規(guī)則4.1.6：假如輸入為數(shù)字參數(shù)則必須進行數(shù)字型推斷講明：那個地點的數(shù)字參數(shù)指的是完全由數(shù)字組成的數(shù)據(jù)。實施指導：Stringmobileno=request.getParameter("mobileno");StringcharacterPattern="^\\d+$";//正則表達式表示是否全為數(shù)字if(!mobileno.matches(characterPattern)){out.println(“InvalidInput”);}規(guī)則4.1.7：假如輸入只同意包含某些特定的字符或字符的組合，則講明：關(guān)于一些有規(guī)則可循的輸入，如email地址、日期、小數(shù)等，使用正則表達式進行白名單校驗，如此比使用黑名單進行校驗更有效。實施指導：email地址校驗的方法：StringemailAddress=request.getParameter("emailAddress");StringcharacterPattern="^([a-z0-9A-Z]+[_-]?)+[a-z0-9A-Z]@(([a-z0-9A-Z]+[_-]?)+(-[a-z0-9A-Z]+)?\\.)+[a-zA-Z]{2,4}$";//email正則表達式if(!emailAddress.matches(characterPattern)){out.println(“InvalidEmailAddress”);}規(guī)則4.1.8：假如輸入為字符串參數(shù)則必須進行字符型合法性推斷講明：可定義一個合法字符集。實施指導：Stringtext=request.getParameter("text");StringcharacterPattern="^[A-Za-z]*$";//開發(fā)者自行定義字符規(guī)則(方括號內(nèi)的字符集)if(!text.matches(characterPattern)){out.println(“InvalidInput”);}規(guī)則4.1.9：校驗輸入數(shù)據(jù)的長度講明：假如輸入數(shù)據(jù)是字符串，必須校驗字符串的長度是否符合要求，長度校驗會加大攻擊者實施攻擊的難度。規(guī)則4.1.10：校驗輸入數(shù)據(jù)的講明：假如輸入數(shù)據(jù)是數(shù)值，必須校驗數(shù)值的范圍是否正確，如年齡應(yīng)該為0～150之間的正整數(shù)。規(guī)則4.1.11：禁止通過字符串串聯(lián)直接使用用戶講明：禁止通過字符串串聯(lián)直接使用用戶輸入構(gòu)造可執(zhí)行SQL語句，如：stringsql="selectstatusfromUserswhereUserName='"+txtUserName.Text+"'";如此專門容易被SQL注入攻擊。規(guī)則4.1.12：關(guān)于java/JSP語言，使用預編譯語句PreparedStatement代替直接的語句執(zhí)行講明：使用預編譯語句PreparedStatement，類型化SQL參數(shù)將檢查輸入的類型，確保輸入值在數(shù)據(jù)庫中當作字符串、數(shù)字、日期或boolean等值而不是可執(zhí)行代碼進行處理，從而防止SQL注入攻擊。而且，由于PreparedStatement對象已預編譯過，因此其執(zhí)行速度要快于Statement對象。因此，多次執(zhí)行的SQL語句經(jīng)常創(chuàng)建為PreparedStatement對象，還能夠提高效率。實施指導：參考如下代碼：Stringinssql="insertintobuy(empid,name,age,birthday)values(?,?,?,?)";PreparedStatement

stmt

=

null;stmt=conn.prepareStatement(inssql);stmt.setString(1,empid);stmt.setString(2,name);stmt.setInt(3,age);stmt.setDate(4,birthday);stmt.execute();備注：使用like進行模糊查詢時，假如直接用"select*fromtablewherecommentlike%?%"，程序會報錯，必須采納如下方法Stringexpress="select*fromtablewherecommentlike?";pstmt=con.prepareStatement(express);Stringc="hello";pstmt.setString(1,"%"+c+"%");//參數(shù)自動添加單引號，最后的SQL語句為：select*fromtablewherecommentlike'%hello%'pstmt.execute();規(guī)則4.1.13：禁止動態(tài)構(gòu)建XPath語句講明：和動態(tài)構(gòu)建SQL一樣，動態(tài)構(gòu)建XPath語句也會導致注入漏洞（XPath注入）。動態(tài)構(gòu)建XPath語句的例子：publicbooleandoLogin(StringloginID,Stringpassword){ XPathExpressionexpr=pile("http://users/user[loginID/text()='"+loginID+"'andpassword/text()='"+password+"']/firstname/text()"); }規(guī)則4.1.14：在JavaBean中禁止使用講明：property="*"這表明用戶在可見的JSP頁面中輸入的，或是直接通過QueryString提交的參數(shù)值，將存儲到與參數(shù)名相匹配的bean屬性中。例如，網(wǎng)上購物程序，一般，用戶是如此提交請求的：/addToBasket.jsp?newItem=ITEM0105342，假如用戶提交：/addToBasket.jsp?newItem=ITEM0105342&balance=0，如此，balance=0的信息就被在存儲到了JavaBean中了，而balance是整個會話中用來存儲總費用的，當他們這時點擊“chekout”結(jié)賬的時候，費用就全免了。規(guī)則4.1.15：用于重定向的輸入?yún)?shù)不能包含回車和換行字符，以防止HTTP響應(yīng)拆分攻擊講明：注意，“回車”字符有多種表示方式（CR=%0d=\r），“換行”字符有多種表示方式（LF=%0a=\n）。規(guī)則4.1.16：假如服務(wù)端代碼執(zhí)行操作系統(tǒng)命令，禁止從客戶端獵取命令。講明：假如服務(wù)端代碼中使用Runtime.getRuntime().exec(cmd)或ProcessBuilder等執(zhí)行操作系統(tǒng)命令，那么禁止從客戶端獵取命令；而且最好不要從客戶端獵取命令的參數(shù)，假如必須從客戶獵取命令的參數(shù)，那么必須采納正則表達式對命令參數(shù)進行嚴格的校驗，以防止命令注入（因為，一旦從客戶端獵取命令或參數(shù)，通過;&|<>符號，特不容易構(gòu)造命令注入，危害系統(tǒng)）。輸出編碼規(guī)則4.2.1：關(guān)于不可信的數(shù)據(jù)，輸出到客戶端前必須先進行HTML編碼。講明：不可信的數(shù)據(jù)（也確實是其他業(yè)務(wù)系統(tǒng)生成的未經(jīng)本應(yīng)用程序驗證的表數(shù)據(jù)或文件數(shù)據(jù)），通過對輸出到客戶端的數(shù)據(jù)進行編碼，能夠防止掃瞄器將HTML視為可執(zhí)行腳本，從而防止跨站腳本攻擊。實施指導：JSP語言能夠通過替換輸出數(shù)據(jù)的專門字符【&<>”’()%+-】為其他表示形式后再輸出給客戶端，例如：<%StringOutStr="<script>alert('XSS')</script>";OutStr=OutStr.replaceAll("&","&");OutStr=OutStr.replaceAll("<","<");OutStr=OutStr.replaceAll(">",">");OutStr=OutStr.replaceAll("\"",""");OutStr=OutStr.replaceAll("\'","'");OutStr=OutStr.replaceAll("\\(","(");OutStr=OutStr.replaceAll("\\)",")");out.println(OutStr);%>ASP.NET語言能夠通過HtmlEncode方法對HTML的輸出進行編碼。PHP語言能夠通過htmlentities或htmlspecialchars方法對HTML輸出進行編碼。上傳下載規(guī)則4.3.1：必須在服務(wù)器端采納白名單方式對上傳或下載的文件類型規(guī)則4.3.2：禁止以用戶提交的數(shù)據(jù)作為讀/寫/上傳/下載文件的路徑或文件名，以防止目錄跨越講明：建議對寫/上傳文件的路徑或文件名采納隨機方式生成，或?qū)?上傳文件放置在有適當訪問許可的專門目錄。對讀/下載文件采納映射表（例如，用戶提交的讀文件參數(shù)為1，則讀取file1，參數(shù)為2，則讀取file2）。防止惡意用戶構(gòu)造路徑和文件名，實施目錄跨越和不安全直接對象引用攻擊。規(guī)則4.3.3：禁止將敏感文件（如日志文件、配置文件、數(shù)據(jù)庫文件等）存放在Web內(nèi)容目錄下。講明：Web內(nèi)容目錄指的是：通過Web能夠直接掃瞄、訪問的目錄，存放在Web內(nèi)容目錄下的文件容易被攻擊者直接下載。異常處理規(guī)則4.4.1：應(yīng)用程序出現(xiàn)異常時，禁止向客戶端暴露不必要的信息，只能向客戶端返回一般性的講明：應(yīng)用程序出現(xiàn)異常時，禁止將數(shù)據(jù)庫版本、數(shù)據(jù)庫結(jié)構(gòu)、操作系統(tǒng)版本、堆棧跟蹤、文件名和路徑信息、SQL查詢字符串等對攻擊者有用的信息返回給客戶端。建議重定向到一個統(tǒng)一、默認的錯誤提示頁面，進行信息過濾。規(guī)則4.4.2：應(yīng)用程序捕獲異常，講明：記錄詳細的錯誤消息，可供入侵檢測及問題定位。代碼注釋規(guī)則4.5.1規(guī)則4.5.2規(guī)則4.5.3規(guī)則4.5.4：規(guī)則4.5.5：關(guān)于動態(tài)講明：動態(tài)頁面包括ASP、PHP、JSP、CGI等由動態(tài)語言生成的頁面。通過掃瞄器查看源碼的功能，能夠查看動態(tài)頁面中的一般注釋信息，但看不到隱藏注釋（隱藏注釋可不能發(fā)送給客戶端）。因此，為了減少信息泄漏，建議只使用隱藏注釋。實施指導：<formaction=h.jsp><%--隱藏注釋1--%><textareaname=alength=200></textarea><inputtype=submitvalue=test></form><%//隱藏注釋2java.lang.Stringstr=(String)request.getParameter("a");/*隱藏注釋3*/str=str.replaceAll("<","<");out.println(str);%>歸檔要求規(guī)則4.6.1：版本歸檔時，必須刪除開發(fā)過程講明：惡意用戶能夠通過URL請求諸如.bak之類的文件，Web服務(wù)器會將這些文件以文本方式呈現(xiàn)給惡意用戶，造成代碼的泄漏，嚴峻威脅Web應(yīng)用的安全。實施指導：在web應(yīng)用的根目錄下執(zhí)行以下命令：find./-name"*.old"-o-name"*.OLD"-o-name"*.bak"-o-name"*.BAK"-o-name"*.temp"-o-name"*.tmp"-o-name"*.save"-o-name"*.backup"-o-name"*.orig"-o-name"*.000"-o-name"*~"-o-name"*~1"-o-name"*.dwt"-o-name"*.tpl"-o-name"*.zip"-o-name"*.7z"-o-name"*.rar"-o-name"*.gz"-o-name"*.tgz"-o-name"*.tar"-o-name"*.bz2"分析查找到的文件是否臨時文件、備份文件、無用文件，假如是則刪除。規(guī)則4.6.2：歸檔的頁面程序文件的擴展名必須講明：專門多Webserver對大小寫是敏感的，但對后綴的大小寫映像并沒有做正確的處理。攻擊者只要在URL中將JSP文件后綴從小寫變成大寫，Web服務(wù)器就不能正確處理那個文件后綴，而將其當作純文本顯示。攻擊者能夠通過查看源碼獲得這些程序的源代碼。因此，歸檔的頁面程序文件的擴展名必須使用小寫字母，如jsp、html、htm、asp等頁面程序文件的擴展名分不為jsp、html、htm、asp。規(guī)則4.6.3：歸檔講明：那個地點的“調(diào)試用的代碼”是指開發(fā)過程中進行臨時調(diào)試所用的、在Web應(yīng)用運行過程中不需要使用到的Web頁面代碼或servlet代碼。例如：在代碼開發(fā)過程中為了測試一個添加帳號的功能，開發(fā)人員臨時編寫了一個JSP頁面進行測試，那么在歸檔時，該JSP頁面必須刪除，以免被攻擊者利用。其他規(guī)則4.7.1：關(guān)于JSP語言，所有servlet必須進行靜態(tài)映射，不同意通過絕對路徑訪問。講明：在web.xml文件中為servlet配置URI映射，使用servlet時，引用它的URI映射，而不同意通過絕對路徑訪問。規(guī)則4.7.2：對客戶端提交的表單請求進行合法性校驗，防止跨站請求偽造攻擊。講明：跨站請求偽造（CSRF）是一種挾制終端用戶在當前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。攻擊者能夠迫使用戶去執(zhí)行攻擊者預先設(shè)置的操作，例如，假如用戶登錄網(wǎng)絡(luò)銀行去查看其存款余額，他沒有退出網(wǎng)絡(luò)銀行系統(tǒng)就去了自己喜愛的論壇去灌水，假如攻擊者在論壇中精心構(gòu)造了一個惡意的鏈接并誘使該用戶點擊了該鏈接，那么該用戶在網(wǎng)絡(luò)銀行帳戶中的資金就有可能被轉(zhuǎn)移到攻擊者指定的帳戶中。當CSRF針對一般用戶發(fā)動攻擊時，將對終端用戶的數(shù)據(jù)和操作指令構(gòu)成嚴峻的威脅；當受攻擊的終端用戶具有治理員帳戶的時候，CSRF攻擊將危及整個Web應(yīng)用程序。實施指導：方法一：為每個session創(chuàng)建唯一的隨機字符串，并在受理請求時驗證<formaction="/transfer.do"method="post"><inputtype="hidden"name="randomStr"value=<%=request.getSession().getAttribute("randomStr")%>></form>//推斷客戶端提交的隨機字符串是否正確StringrandomStr=(String)request.getParameter("randomStr");if(randomStr==null)randomStr="";if(randomStr.equals(request.getSession().getAttribute("randomStr"))){//處理請求}else{//跨站請求攻擊，注銷會話}方法二：受理重要操作請求時，在相應(yīng)的表單頁面增加圖片驗證碼，用戶提交操作請求的同時提交驗證碼，在服務(wù)器端先推斷用戶提交的驗證碼是否正確，驗證碼正確再受理操作請求。方法三：向電信軟件與核心網(wǎng)網(wǎng)絡(luò)安全工程部申請WAFCBB，并部署到應(yīng)用中，啟用AntiCSRF功能，具體方法參考WAFCBB的用戶手冊。規(guī)則4.7.3：使用.innerHtml時，假如只是要顯示文本內(nèi)容，必須在innerHTML取得內(nèi)容后，再用正則表達式去除HTML標簽，以預防跨站腳本。講明：使用.innerHtml會將內(nèi)容以HTML顯示，容易被利用，導致跨站腳本。實施指導：<ahref="javascript:alert(document.getElementById('test').innerHTML.replace(/<.+?>/gim,''))">無HTML,符合W3C標準</a>備注：還能夠使用.innerText代替.innerHtml，.innerText只顯示文本內(nèi)容不顯示HTML標簽，但.innerText不是W3C標準的屬性，不能適用于所有掃瞄器（但適用于IE掃瞄器）。規(guī)則4.7.4：禁止使用