安全測試

大類	序號	要素內容	審查結果
口令策略	1	長度要求：口令長度的取值範圍爲：1-32 個字符；默認：最短長度爲 6 個字符，最長長度爲 32 個字符；     一、最短長度能夠根據具體的業務進行配置；     二、最長長度能夠根據具體的業務進行配置，而且最短長度不能大於最長長度。
	2	字符集要求：口令中至少須要包括一個大寫字母（A-Z）、一個小寫字母（a-z）、一個數字字符（0-9）、一個特殊字符；     一、是否至少包含特殊字符要求能夠配置，便是可選的；     二、特殊字符集全集爲：!"#$%&'()*+,-./:;<=>?@[\]^`{_|}~；     三、特殊字符集實際包含哪些字符要求能夠配置。
	3	可重複字符數要求：最多可重複字符數的取值範圍是：1-6；默認爲   3 個；     一、最多可重複字符數要求能夠配置。
	4	弱口令詞典要求：口令不能是出如今指定弱口令詞典中的詞；每一個產品提供並維護各自的弱口令詞典；     一、要求在口令被泄密（或者被猜想到等）須要及時對弱口令詞典進行維護。
	5	口令歷史記錄數要求：口令歷史記錄數的取值範圍爲：0-30；默認：3 個；     一、要求口令歷史記錄數能夠根據具體的業務進行配置。
	6	口令保存期要求：最短保存期的取值範圍：0-1440 分鐘（1 天），默認：5 分鐘；最長保存期的取值範圍：1-1096 天（約 3 年），默認：90 天（約 3 個月）。
	7	管理員能夠修改本身和其餘用戶/操做員的口令。管理員修改其餘用戶/操做員口令時，不須要提供舊口令。管理員/用戶/操做員修改本身的口令時，必須提供舊口令
	8	初始口令爲系統提供的默認口令時、或者是由管理員設定時，則在用戶/操做員在第一次登陸時（或者第一次登陸成功後）強制要求更改口令，並直至更改爲功。用戶/操做員的口令若是是被管理員修改的，那麼在用戶/操做員第一次登陸成功後強制要求修改口令，並直至更改爲功。在口令到期前系統最遲提早 1 天提示，最先提早 99 天提示，即取值範圍：1-99 天，默認：7 天。口令到達最長保存期後，用戶再次登陸時系統強制更改口令，並直至更改爲功後才能登陸成功
	9	口令不能以明文的形式在界面上顯示，要求顯示爲一串星號（*）。口令不能以明文的形式保存，必須加密保存；加密前，用戶口令須要和用戶名關聯，即加密前的數據不只包括口令，還須要包括用戶名
	10	口令策略以公共部件實現。以產品域爲單位，域內各個產品能夠共享，避免重複開發
認證及會話控制	11	基於 HTTP 協議：HTTP 是無狀態協議，即意味着 WEB 服務器將每一個 HTTP 請求都看成相互無關的請求進行處理，所以，在處理瀏覽器（客戶端）的認證請求和受權操做時，則必需要提供會話支持。會話是由服務器端開發環境構建的抽象層，不一樣的會話狀態管理機制以及會話狀態的內部實現方式取決於平臺的基礎結構。實際實現時應知足以下要求：     一、儘可能採用 WEB 平臺環境提供的會話支持功能，例如：JSP、ASP.net 等程序都提供了相應的會話管理模塊或接口；     二、提供一個公共的認證模塊用於保持和跟蹤用戶的會話狀態，一旦跟蹤到非法會話，則出錯或返回到認證界面；     三、每個用於處理受權操做的 WEB 服務程序文件都必須調用該認證模塊，且需在程序文件的開頭調用；     四、當瀏覽器（客戶端）執行回退操做時，歷史頁面將失效。
	12	基於 TCP/IP 協議：     一、不容許服務端僅僅依靠源   IP 地址來認證客戶端，必須使用用戶名/口令、動態口令等安全認證方式；     二、要求鏈接成功後客戶端發送的第一個數據包老是認證請求包。若是服務端認證失敗，返回認證失敗的應答包後將鏈接當即斷開。
	13	基於 UDP/IP 協議：在發送方發送的任何有須要認證要求的數據包中附加認證信息，接收方在接收到信息包後首先根據認證信息進行認證，若是認證經過，則繼續數據處理，不然終止數據的處理
	14	認證失敗等狀況發生後，不能提示給用戶詳細以及明確的錯誤緣由，只能給出通常性提示。如：     一、能夠提示：「用戶名或者口令錯誤，登陸失敗」；     二、不能提示：「用戶名不存在」、「口令必須是 6 位」等等。
	15	鎖定要求：客戶端在屢次連續嘗試登陸失敗後，服務端須要將用戶賬號或者是客戶端所在機器的 IP 地址鎖定，在鎖按期間不容許該用戶賬號（或者該 IP 上的全部客戶端）登陸；     一、容許連續失敗的次數（指從最後一次成功以來失敗次數的累計值）取值範圍爲：1-10 次，默認：5 次。鎖定時長的取值範圍爲：0-1440 分鐘（1 天），默認：30   分鐘，當取值爲 0 時，表示無限期鎖定；     二、若是服務端將用戶賬號或者是客戶端所在機器的 IP 地址鎖定了，那麼在鎖定時間事後，須要自動解鎖鎖定的用戶賬號（IP）；     三、須要提供管理員對服務器鎖定其它用戶賬號（IP）進行解鎖的功能界面，即須要實現管理員能夠解鎖服務器鎖定的用戶賬號（IP）的功能；     四、當鎖定時長的取值爲 0   而且用戶賬號或者是客戶端所在機器的 IP 地址被鎖定，此時用戶賬號（IP）處於無限期鎖定狀態，用戶賬號（IP）不會自動解鎖，只能經過管理員手動解鎖。     五、超級用戶賬號不能被鎖定，只能鎖定操做的客戶端所在的 IP。
	16	服務器可以經過客戶端地址、或者是當前總會話數、或者是容許時間段登陸等條件限制客戶端的登陸
	17	具備操做界面的應用程序/客戶端須要在用戶長時間（1-60 分鐘，默認：10 分鐘）沒有操做時自動鎖定界面；鎖定後，界面上不能繼續顯示敏感信息，只能顯示解鎖的相關信息；用戶解鎖時，須要用戶提供同認證時同樣的認證信息，若是客戶端具備本地認證的功能，認證在本地完成，若是客戶端沒有本地認證的功能，那麼此時的認證必須是在服務端完成的
	18	一次會話成功創建以後，須要給當前用戶顯示有關的訪問歷史記錄數據，包括：     一、上一次會話成功創建的日期、時間和位置等信息；     二、上一次會話創建不成功的日期、時間和位置等信息；     三、自從最後一次成功的會話創建以來不成功的嘗試次數；     四、口令將到期的天數。
驗證碼	19	驗證碼字符串要求是隨機生成，其中生成隨機數的函數要求是安全的。建議：     一、Windows 環境下是使用 CryptGenRandom 來生成隨機數；     二、Unix、Linux 環境下是從名爲 /dev/random 或者 /dev/urandom 的設備中讀取從而獲得隨機數；     三、Java 中是使用類 java.security.SecureRandom 來生成隨機數。
	20	長度要求：驗證碼長度的取值範圍：1-8 個字符，默認：4 個字符。     一、要求驗證碼長度能夠根據業務需求進行配置；     二、對於安全要求更高的狀況，則要求連續屢次生成的驗證碼的長度隨機變化。
	21	字符集要求：驗證碼字符串字符集，建議只由數字組成；     一、對於安全要求更高的狀況，則要求同時存在數字、小寫英文字母，大寫英文字母，甚至還要求同時存在標點符號等特殊字符、同時存在本地語言字符（如：漢字）；     二、對於字符集是否包含英文字母、大小寫、特殊字符等要求能夠配置。
	22	字符字體要求：建議驗證碼字符的字體爲一種字形，字號大小同樣；     一、對於安全要求更高的狀況，則要求驗證碼的每一個字符的字形都不同，每一個字符的字號大小也不全同樣；     二、要求能夠配置字形、字號是否同樣；     三、要求能夠配置有哪些字形、字號。
	23	字符串位置要求：建議每次生成的驗證碼字符串位置同樣。     一、對於安全要求更高的狀況，則要求連續屢次生成的驗證碼字符串位置隨機變化；     二、要求能夠配置位置是否同樣；     三、要求能夠配置有哪些位置。
	24	格式要求：圖片格式能夠採用 JPEG、PNG、GIF；默認：採用 JPEG 格式；     一、不能使用 XBM 格式，由於 XBM 存在漏洞。
	25	顏色要求：建議圖片中字符串的顏色和背景顏色很接近便可；     一、對於安全要求更高的狀況，則要求爲黑白圖片，即字符和干擾象素都是黑色，背景是白色；     二、要求是否爲黑白圖片是能夠配置的。
	26	背景干擾要求：背景干擾象素點覆蓋率至少要達到 20％，最大爲   90％；     一、建議：背景干擾象素點覆蓋率至少要達到 50％，每次生成驗證碼圖片的背景干擾是同樣的；     二、對於安全要求更高的狀況，則要求連續屢次生成的驗證碼圖片的背景干擾隨機變化；     三、要求可配背景干擾是否同樣；     四、背景干擾象素點覆蓋率可配。
	27	驗證碼在一次使用後要求當即失效，即該驗證碼在後續的應用中不能再使用，新的應用須要從新生成驗證碼；     一、驗證碼在必定時間（1-60   分鐘，默認：3 分鐘）後，不管客戶端是否進行過驗證，都應當即失效。
	28	圖片驗證碼的關鍵是不能在客戶端留下圖片的真實URL，或可對應反推源地址的信息。建議：     一、在 PHP 中，經過調用 GD 庫等方式生成 JPG/GIF 等圖形格式的註冊驗證碼；     二、ASP 採用如下兩種種方式實現圖形驗證碼：     三、若是是購買的虛擬主機，那麼能夠採用將 JPG/GIF 圖片放到數據庫，而後用 SESSION 傳值的方式，最後利用 ASP直接從數據庫中輸出圖片；     四、若是是有管理員控制權限的用戶，能夠考慮採用第三方組件來實現。
加解密算法	29	對於同一類別的算法要求經過配置能夠改變具體的算法；     一、採用不可逆算法時，要求經過配置能夠選擇是：MD五、SHA-256 等；     二、採用對稱加密算法時，要求經過配置能夠選擇是：RC四、DES、AES 等；     三、採用非對稱加密算法時，要求經過配置能夠選擇是：ECC、RSA 等。
	30	對於某一種對稱加解密算法，若是它支持多個密鑰長度，則要求密鑰的長度可配
	31	對於某一種非對稱加解密算法，若是它支持多個模長，則要求模長可配
加密協議	32	對於傳輸數據的加密策略，能夠根據實際狀況，靈活採用：     一、若是通訊數據量大、可是其中的敏感數據又不多的狀況，能夠採用非對稱算法（公鑰加密、私鑰解密）並只對其中的敏感數據加密；     二、對於須要加密的數據的量比較大時，能夠採用數字信封的方式；     三、對於數據量大、同時還有性能要求時，能夠先採用非對稱加密算法完成對稱密鑰的共享（公鑰加密、私鑰解密），而後通訊雙方使用共享的對稱密鑰採用對稱算法進行加解密。     四、基於 SSL 實現數據的傳輸。
	33	若是數據的傳輸是在內部安全網內，能夠繼續使用明文的應用層協議，若是數據的傳輸通過了不安全的網絡（如：Internet   等），則須要使用加密的協議替代明文的應用層協議
	34	對因而使用明文協議仍是使用加密協議，要求作到能夠配置
密鑰管理	35	若是使用用戶輸入的口令做爲加密的密鑰時，不直接使用口令做爲密鑰，而是把口令通過密鑰導出算法（如：PKCS5）處理後的結果做爲加密的密鑰，這樣才具備更好的密碼學特性
	36	對稱密鑰：     一、對稱密鑰在程序啓動時，由操做員手工輸入口令，通過密鑰導出算法（如：PKCS5）處理獲得；     二、對於程序是被帶起的、操做員沒法干預的狀況，口令使用對稱密鑰加密保存，使用時再使用對稱密鑰解密出來。在公共的密鑰管理模塊未開發出來以前，對稱密鑰暫時寫死到代碼中，並遵循如下原則：       a、變換原則：寫死到代碼中的串並非最終的密鑰串，而是一個初始串，將該初始串通過密鑰導出算法（如：PKCS5）處理後獲得的結果纔是最終的密鑰串；       b、不可見原則：寫死到代碼中的初始串使用不可見字符（不包括字符串結束符：0x00）；       c、不重複原則：初始串中任意兩個連續的字符不能是相同的；       d、不連續原則：初始串中任意兩個連續的字符不能是兩個連續的值（如：0x9九、0x98 是連續的兩個值）；       e、分散保存原則：初始串不能保存到一個數組或者一個整串中。須要按字節拆分，將初始串保存到字節變量中，而且各個字節變量不能連續定義，須要在不一樣的代碼位置定義，即：將初始串按字節分散保存；       f、賦值原則：不採用初始化賦值，而採用賦值語句給每一個字節賦值。
	37	口令修改功能和應用程序集成在一塊兒，不能以工具形式單獨提供。其中：windows 界面程序的口令修改功能以界面方式提供；無界面的進程的口令修改功能以命令行方式提供，命令名就是進程名，以不一樣參數選項與運行區別，如：啓動進程爲：aaa.exe -r，修改口令爲：aaa.exe -p oldpwd newpwd；unix 程序同 windows 下的無界面進程。     一、應用程序若是實現了口令修改功能，那麼同時還須要提供修改口令的接口，即外部程序能夠經過該接口修改口令。
	38	私鑰使用口令加密（口令須要通過密鑰導出算法的處理）。應用程序加載私鑰時須要操做員輸入口令，應用程序使用操做員輸入的口令對私鑰解密；     一、開發一個公私鑰密鑰對生成工具（Windows 界面程序），用來產生密鑰對；       a、密鑰對生成工具要求可以輸入一個口令用來加密私鑰（口令須要通過密鑰導出算法的處理）。     二、私鑰口令的修改功能和應用程序集成在一塊兒，不能以工具形式單獨提供。其中：windows 界面程序的私鑰口令修改功能以界面方式提供；無界面的進程的私鑰口令修改功能以命令行方式提供，命令名就是進程名，以不一樣參數選項與運行區別，如：啓動進程爲：aaa.exe -r，修改私鑰口令爲：aaa.exe -k oldpwd   newpwd；unix 程序同 windows 下的無界面進程。       a、應用程序若是實現了私鑰口令的修改功能，那麼同時還須要提供修改私鑰口令的接口，即外部程序能夠經過該接口修改私鑰的口令。
最小受權原則	39	一個賬號只能擁有必需的角色和必需的權限
	40	一個組只能擁有必需的角色和必需的權限
	41	一個角色只能擁有必需的權限
	42	操做系統賬號：     一、對於運行應用系統的操做系統賬號，不該使用「root」、「administrator」、「supervisor」等特權賬號或高級別權限賬號，應該儘量地使用低級別權限的操做系統賬號       a、根據業務系統要求，建立相應的系統組和賬號       b、若是有部分代碼須要很高的權限（如：root 權限），則請將這部分代碼分離出來並單獨以高權限的系統賬號環境運行
	43	數據庫賬號：     一、對於鏈接數據庫服務器的數據庫賬號，不該使用「sa」、「sysman」等管理賬號或高級別權限賬號，應該儘量地使用低級別權限的數據庫賬號       a、根據業務系統要求，建立相應的數據庫賬號，並授予必需的數據庫權限
	44	業務系統賬號：     一、應用賬號應與管理賬號相分離；應用賬號不該具備任何的管理功能，也不該具備任何未應受權就能使用的功能；每一個應用賬號只應具備能完成與其任務（或身份）相適應的權限
文件權限管理	45	Unix、Linux 系統：     一、必須給每種類型的文件指定特定的權限，不容許使用系統的缺省權限（如：umask）；     二、需注意在業務系統運行期間新產生的文件的權限，不容許使用系統的缺省權限（如：umask）；     三、不一樣類型的文件應位於不一樣的目錄內，避免目錄權限上的混淆，如程序文件、日誌文件、配置文件及相關業務文件應位於不一樣的目錄內；     四、文件的權限須要事先在安裝程序中設置好，不須要安裝後手工一個一個來改。       a、程序文件（含腳本文件、庫文件等）：550（r-xr-x---）       b、程序文件目錄：                    550（r-xr-x---）       c、配置文件：                        640（rw-r-----）       d、配置文件目錄：                    750（rwxr-x---）       e、日誌文件（記錄完畢或者已經歸檔）：440（r--r-----）       f、日誌文件（正在記錄）：            640（rw-r-----）       g、日誌文件目錄：                    750（rwxr-x---）       h、Debug 文件：                      640（rw-r-----）       i、Debug 文件目錄：                  750（rwxr-x---）       j、業務數據文件：                    640（rw-r-----）       k、業務數據文件目錄：                750（rwxr-x---）
	46	Windows 系統：     一、爲業務運行建立新的用戶和用戶組，業務運行的用戶僅屬於業務運行的用戶組；     二、業務安裝目錄僅給業務運行的用戶組和本地 Administraors 組開放徹底控制的權限；     三、對於業務安裝目錄下的文件或者子目錄須要對用戶組限制權限時經過設置「拒絕」權限完成；     四、業務運行的用戶和用戶組的建立、以及安裝目錄權限的設置在業務安裝包中完成。
安全日誌	47	應用系統至少須要記錄下列事件到日誌文件：     一、安全事件（包括成功和失敗）：       a、登陸；       b、註銷；       c、添加、刪除、修改用戶；       d、給用戶受權（給用戶分配/取消一個或者多個權限）；       e、鑑權（鑑別用戶是否有某項或者某幾項權限）；       f、修改用戶口令。     二、操做事件（包括成功和失敗）：       a、對系統配置參數的修改；       b、對系統進行啓動、關閉、重啓、暫停、恢復、倒換；       c、對業務的加載、卸載；       d、對重要業務數據（特別是與財務相關的數據，包括：卡號、餘額、話單、費率、費用、訂單、出貨、賬單等）的建立、刪除、修改、查詢。     三、運行事件：       a、系統處理出錯；       b、系統處理失敗；       c、系統異常倒換；       d、系統異常退出；       e、進程吊死；       f、關鍵線程異常退出；       g、關鍵線程吊死。     四、資源告警事件：       a、內存使用太高；       b、CPU 使用太高；       c、磁盤空間不足；       d、網絡擁塞。
賬號可審計要求	48	用戶賬號：     一、應用系統中除超級用戶外的其餘用戶是經過配置維護添加的，同時經過配置維護能夠修改、刪除，不能是系統固定的；     二、一個操做員須要配置一個用戶賬號，不容許多個操做員共享一個用戶賬號。
	49	應用程序賬號：    一、若是應用程序賬號同時是操做系統賬號：      a、在   Unix/Linux 系統下：該賬號不能是 root 用戶；須要關閉該用戶的遠程登陸功能，即不容許該賬號進行 Telnet 登陸；若是業務不須要 FTP 功能，同時須要取消該用戶的 FTP 功能，即不容許該賬號進行 FTP 操做；      b、在 Windows   系統下，該用戶不能屬於操做系統提供的任何組，只能屬於爲業務新建的用戶組；而且只能分配最小的目錄權限。    二、若是應用程序賬號同時是數據庫系統賬號：      a、不能是數據庫管理員賬號，也不能擁有數據庫管理員權限，只能分配最小的操做權限。    三、應用程序使用的賬號必須和操做員使用的賬號分開；    四、應用程序的賬號須要限制能夠登陸的 IP，即登陸服務端時，該賬號只有在指定 IP 的機器上發起請求，服務器端驗證時才能經過；    五、當不爲操做系統賬號時，不一樣的應用程序實例須要配置不一樣的賬號，不容許多個應用程序實例共享一個賬號（例外：同一個操做系統用戶啓動的同一應用程序的多個實例可使用同一個賬號和口令）；    六、應用程序的賬號不是操做系統賬號和數據庫系統賬號時，口令須要由應用程序隨機生成，並符合口令策略。