安全編碼實踐清單

　　輸入驗證:

　　Conduct all data validation on a trusted system (e.g., The server)

　　在受信任系統(tǒng)上進行全部數據驗證。(例如服務器)

　　Identify all data sources and classify them into trusted and untrusted. Validate all data from untrusted sources (e.g., Databases, file streams, etc.)

　　確認所有數據源并將其分為受信任和不信任的。驗證所有來自不信任源的數據。(例如數據庫，文件流等等)

　　There should be a centralized input validation routine for the application

　　各類應用應當具有統(tǒng)一的輸入驗證規(guī)則。

　　Specify proper character sets, such as UTF-8, for all sources of input

　　為所有輸入源指定適當的統(tǒng)一字符集，例如UTF-8字符集。

　　Encode data to a common character set before validating (Canonicalize)

　　在驗證前將數據用統(tǒng)一字符集進行編碼。(規(guī)范化) All validation failures should result in input rejection

　　所有驗證失敗的情形應當導致拒絕輸入。

　　Determine if the system supports UTF-8 extended character sets and if so, validate after UTF-8 decoding is completed

　　確認系統(tǒng)是否支持UTF-8擴展字符集，如果支持，則在UTF-8解碼完成后進行驗證。

　　在處理前驗證所有客戶端提供的數據，包括所有參數，URL以及HTTP頭文件(例如Cookie名及數值)。確定其中包含JavaScript, Flash或其他嵌入代碼產生的自動回傳數據。

　　Verify that header values in both requests and responses contain only ASCII characters

　　確認請求和響應的標頭值只包含ASCII字符

　　Validate data from redirects (An attacker may submit malicious content directly to the target of the redirect, thus circumventing application logic and any validation performed before the redirect)

　　驗證重定向數據(攻擊者可能上傳只對重定向目標起作用的惡意代碼，從而繞過重定向前的應用程序邏輯及任何驗證手段)

　　Validate for expected data types 、

　　驗證數據類型是否符合期望

　　Validate data range

　　驗證數據值域

　　Validate data length

　　驗證數據長度

　　Validate all input against a "white" list of allowed characters, whenever possible

　　可能的話，將所有輸入與被允許字符的”白名單”進行對比驗證

　　If any potentially hazardous characters must be allowed as input, be sure that you implement additional controls like output encoding, secure task specific APIs and accounting for the utilization of that data throughout the application . Examples of common hazardous characters include:

　　< > " ’ % ( ) & + \ \’ \"

　　在不得不允許輸入可能危險的字符的情況下，需要實現額外的控制功能如輸出編碼，安全任務專用的應用程序接口，并將使用含危險字符數據的可能性納入全盤考量。常見的危險字符包括< > " ’ % ( ) & + \ \’ \"

　　If your standard validation routine cannot address the following inputs, then they should be checked discretely

　　o Check for null bytes ()

　　o Check for new line characters ( , , \r, \n)

　　o Check for “dot-dot-slash" (../ or ..\) path alterations characters. In cases where UTF-8 extended character set encoding is supported, address alternate representation like: ??/

　　(Utilize canonicalization to address double encoding or other forms of obfuscation attacks)

　　如果標準常規(guī)驗證無法處理以下輸入，那么他們需要被單獨檢查。

　　o 檢查空字節(jié) ()

　　o 檢查換行符 ( , , \r, \n)

　　o 檢查類似”點-點-斜杠" (../ or ..\)的路徑轉換符 在支持UTF-8擴展字符集編碼的情況下檢查路徑轉換符的變體(如??/)

　　(應用規(guī)范化手段解決雙重編碼或者其他類型的混淆攻擊)

　　Output Encoding:

　　輸出編碼

　　Conduct all encoding on a trusted system (e.g., The server)

　　在受信任系統(tǒng)上進行全部編碼程序。(例如服務器)

　　Utilize a standard, tested routine for each type of outbound encoding

　　為每一種出站編碼建立一個經過測試的標準規(guī)范

　　Contextually output encode all data returned to the client that originated outside the application’s trust boundary. HTML entity encoding is one example, but does not work in all cases

　　所有源頭在應用程序信任邊界外的數據在返回客戶端前要進行上下文編碼。HTML實體編碼是一個例子，但并不一定適用于所有情況。

　　Encode all characters unless they are known to be safe for the intended interpreter

　　對所有字符進行編碼，除非在已知對目標解釋程序安全的情況下。

　　Contextually sanitize all output of un-trusted data to queries for SQL, XML, and LDAP

　　在向SQL,XML,LDAP查詢功能輸出的情況下，對不受信任數據的輸出進行上下文清潔。

　　Sanitize all output of un-trusted data to operating system commands

　　清潔所有不受信任數據對操作系統(tǒng)命令的輸出。

　　Authentication and Password Management:

　　身份驗證以及密碼管理

　　Require authentication for all pages and resources, except those specifically intended to be public

　　除特定的公開頁面和資源外，訪問所有頁面及資源都需要身份驗證。

　　All authentication controls must be enforced on a trusted system (e.g., The server)

　　所有身份驗證控制必要在受信任系統(tǒng)上執(zhí)行(例如服務器)

　　Establish and utilize standard, tested, authentication services whenever possible

　　只要可能，就應當建立并應用標準化并經過測試的的身份驗證服務

　　Use a centralized implementation for all authentication controls, including libraries that call external authentication services

　　為所有身份驗證控制建立集中的身份驗證控制系統(tǒng)，包括需要外部身份驗證服務的程序庫

　　Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control

　　對身份驗證邏輯與被訪問資源進行隔離，使用重定向來訪問集中身份驗證控制系統(tǒng)。

　　All authentication controls should fail securely

　　所有身份驗證控制應當保證失效時仍然安全

　　All administrative and account management functions must be at least as secure as the primary authentication mechanism

　　所有的行政及賬戶管理功能的安全性必要和主身份驗證機制相當或更高。

　　If your application manages a credential store, it should ensure that only cryptographically strong one-way salted hashes of passwords are stored and that the table/file that stores the passwords and keys is write-able only by the application. (Do not use the MD5 algorithm if it can be avoided)

　　如果應用程序應用了存儲憑據機制，那么必要確定只存儲了強加密單向附有隨機值的哈希密碼，并且保存密碼/密鑰的表/文件只對該程序可讀。(如果可能，盡量避免使用MD5算法)

　　Password hashing must be implemented on a trusted system (e.g., The server).

　　密碼哈希只能在被信任的系統(tǒng)上實現(例如服務器)

　　Validate the authentication data only on completion of all data input, especially for sequential authentication implementations

　　只有在數據輸入完成后才能進行身份驗證數據的驗證，尤其是在實現連續(xù)身份驗證的情況下。

　　Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of "Invalid username" or "Invalid password", just use "Invalid username and/or password" for both. Error responses must be truly identical in both display and source code

　　對身份驗證失敗的響應不應該標明驗證數據的哪一部分出錯。例如，不應當顯示”無效的用戶名”或”無效的密碼”，而應當顯示”無效的用戶名或密碼”。源代碼和顯示輸出的錯誤響應必要完全相同。

　　Utilize authentication for connections to external systems that involve sensitive information or functions

　　對外部系統(tǒng)的連接，如果涉及到敏感信息或功能的，需要進行身份驗證。

　　Authentication credentials for accessing services external to the application should be encrypted and stored in a protected location on a trusted system (e.g., The server). The source code is NOT a secure location

　　訪問應用程序外部服務的身份驗證證書需要加密保存在一個受信任系統(tǒng)(例如服務器)中的受保護區(qū)域內。保存在源代碼內不安全

　　Use only HTTP POST requests to transmit authentication credentials

　　只使用HTTP POST請求傳輸身份驗證證書。

　　Only send non-temporary passwords over an encrypted connection or as encrypted data, such as in an encrypted email. Temporary passwords associated with email resets may be an exception

　　只通過加密連接或作為加密數據傳輸非臨時密碼，例如通過加密的電子郵件。通過電子郵件重置密碼產生的臨時密碼可能是個例外

　　Enforce password complexity requirements established by policy or regulation. Authentication credentials should be sufficient to withstand attacks that are typical of the threats in the deployed environment. (e.g., requiring the use of alphabetic as well as numeric and/or special characters)

　　強制執(zhí)行策略或監(jiān)管要求的密碼復雜度規(guī)定。身份驗證證書應當足以抵御部署環(huán)境中常見的攻擊模式。(例如，要求密碼中包括字母和數字及/或特殊字符)

　　Enforce password length requirements established by policy or regulation. Eight characters is commonly used, but 16 is better or consider the use of multi-word pass phrases

　　強制執(zhí)行策略或監(jiān)管要求的密碼長度規(guī)定。通常使用的是8個字符的密碼，但16個字符的安全性更好，或者可以考慮使用多字密碼短語。

　　Password entry should be obscured on the user’s screen. (e.g., on web forms use the input type "password")

　　在用戶屏幕上應當對密碼輸入進行遮擋顯示(例如在web表格中使用輸入類型”password”)

　　Enforce account disabling after an established number of invalid login attempts (e.g., five attempts is common). The account must be disabled for a period of time sufficient to discourage brute force guessing of credentials, but not so long as to allow for a denial-of-service attack to be performed

　　在多次無效的登錄嘗試后對賬戶強制停用(通常是5次嘗試)。賬戶停用的時間要足夠長以阻礙對密碼的暴力破解，但不能太長以至于暴露在停止服務攻擊下。

　　Password reset and changing operations require the same level of controls as account creation and authentication.

　　修改和重置密碼的操作需要與創(chuàng)建賬戶及身份驗證同等級別的控制。

　　Password reset questions should support sufficiently random answers. (e.g., "favorite book" is a bad question because “The Bible” is a very common answer)

　　重置密碼的問題應當能是答案具有多樣性。(例如，”最喜愛的書”不是一個好問題，因為”圣經”是一個非常常見的答案)

　　If using email based resets, only send email to a pre-registered address with a temporary link/password

　　使用基于電子郵件的密碼重置功能時，只發(fā)送包含臨時鏈接/密碼的郵件到預先注冊的地址。

　　Temporary passwords and links should have a short expiration time

　　臨時密碼和鏈接的有效期應當較短

　　Enforce the changing of temporary passwords on the next use

　　在下次使用時強制更改臨時密碼

　　Notify users when a password reset occurs

　　當密碼重置時通知用戶

　　Prevent password re-use

　　防止密碼復用

　　Passwords should be at least one day old before they can be changed, to prevent attacks on password re-use

　　密碼使用超過一天后才可進行更改，以防止基于密碼復用的攻擊。

　　Enforce password changes based on requirements established in policy or regulation. Critical systems may require more frequent changes. The time between resets must be administratively controlled

　　強制執(zhí)行策略或監(jiān)管要求的密碼更改。關鍵系統(tǒng)可能需要更頻繁的更改。密碼更改的時間間隔需要由管理員人工控制。

　　Disable "remember me" functionality for password fields

　　禁用”記住密碼”的功能

　　The last use (successful or unsuccessful) of a user account should be reported to the user at their next successful login

　　用戶成功登錄時，應當向其報告上一次登錄賬戶的情形，無論上次成功與否。

　　Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. This attack pattern is used to bypass standard lockouts, when user IDs can be harvested or guessed

　　實現監(jiān)視識別對多個用戶賬戶使用相同密碼進行攻擊的功能。這種攻擊模式可以規(guī)避賬戶因多次登錄失敗而停用的時間，前提是用戶名被大量竊取或猜測，。

　　Change all vendor-supplied default passwords and user IDs or disable the associated accounts

　　修改所有銷售商提供的默認用戶名和密碼，或者禁用相關賬戶。

　　Re-authenticate users prior to performing critical operations

　　在進行關鍵操作時再次對用戶進行身份驗證

　　Use Multi-Factor Authentication for highly sensitive or high value transactional accounts

　　對高敏感度或高價值交易賬戶使用多要素身份驗證

　　If using third party code for authentication, inspect the code carefully to ensure it is not affected by any malicious code

　　如果使用第三方代碼進行身份驗證，仔細檢查代碼以確認其中不包含任何惡意代碼。

　　Session Management:

　　會話管理

　　Use the server or framework’s session management controls. The application should only recognize these session identifiers as valid

　　使用服務器或主機的會話管理控制。應用程序應當只將服務器或主機的會話標識符視為有效。

　　Session identifier creation must always be done on a trusted system (e.g., The server)

　　會話標識符必要在被信任的系統(tǒng)上創(chuàng)建(例如服務器)

　　Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers

　　會話管理控制應當使用經過有效審核的算法以保證算法標識符的隨機性

　　Set the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for the site

　　為包含經身份驗證的會話標識符的cookie的域和路徑設置一個適合站點，合理受限的值。

　　Logout functionality should fully terminate the associated session or connection

　　登出功能應當完全終止相關的會話或連接

　　Logout functionality should be available from all pages protected by authorization

　　所有授權保護的頁面都應當包含登出功能

　　Establish a session inactivity timeout that is as short as possible, based on balancing risk and business functional requirements. In most cases it should be no more than several hours

　　在平衡風險和商業(yè)功能需求的基礎上，會話閑置超時的時間越短越好。大多數情況下不應多于幾個小時

　　Disallow persistent logins and enforce periodic session terminations, even when the session is active. Especially for applications supporting rich network connections or connecting to critical systems. Termination times should support business requirements and the user should receive sufficient notification to mitigate negative impacts

　　禁止長期登錄，即使在會話激活的情況下，也要強制定期終結會話。尤其是支持豐富網絡連接或者連接到關鍵系統(tǒng)的應用程序。

　　If a session was established before login, close that session and establish a new session after a successful login

　　如果會話在登錄前已建立，那么在成功登陸后關閉那個會話并重新建立新會話

　　Generate a new session identifier on any re-authentication

　　在重新身份驗證的時候生成新會話標識符

　　Do not allow concurrent logins with the same user ID

　　禁止同一用戶名同時重復登錄

　　Do not expose session identifiers in URLs, error messages or logs. Session identifiers should only be located in the HTTP cookie header. For example, do not pass session identifiers as GET parameters

　　在URL，錯誤信息或者日志中不要暴露會話標識符。會話標識符應當只存在于HTTP cookie頭文件中。例如，不要將會話標識符用于GET參數。

　　Protect server side session data from unauthorized access, by other users of the server, by implementing appropriate access controls on the server

　　通過在服務器端實現適當的訪問控制，保護服務器端的會話數據不被其他同服務器的用戶非法獲取。

　　Generate a new session identifier and deactivate the old one periodically. (This can mitigate certain session hijacking scenarios where the original identifier was compromised)

　　定期生成新會話標識符并停用舊標識符(這有助于減少某些通過舊標識符劫持會話的情形)

　　Generate a new session identifier if the connection security changes from HTTP to HTTPS, as can occur during authentication. Within an application, it is recommended to consistently utilize HTTPS rather than switching between HTTP to HTTPS.

　　在連接安全由HTTP轉到HTTPS的時候——在身份驗證中可能發(fā)生——生成新的會話標識符。在應用程序內部，建議完全應用HTTPS而不是在HTTP和HTTPS間轉換

　　Supplement standard session management for sensitive server-side operations, like account management, by utilizing per-session strong random tokens or parameters. This method can be used to prevent Cross Site Request Forgery attacks

　　通過為每個進程應用強隨機令牌或參數，對敏感的服務器端操作——如賬戶管理——的標準會話管理進行補充。這種手段可以用于防止跨站偽造請求攻擊

　　Supplement standard session management for highly sensitive or critical operations by utilizing per-request, as opposed to per-session, strong random tokens or parameters

　　對高敏感度或關鍵操作，可以對每個請求，而不是每個會話，應用強隨機令牌或參數。

　　Set the "secure" attribute for cookies transmitted over an TLS connection

　　為通過傳輸層安全連接傳播的cookie設置”secure”屬性

　　Set cookies with the HttpOnly attribute, unless you specifically require client-side scripts within your application to read or set a cookie’s value

　　為cookie設置”HttpOnly”屬性，除非你的應用程序內的客戶端腳本需要讀取或設置cookie的值。

　　Access Control:

　　訪問控制

　　Use only trusted system objects, e.g. server side session objects, for making access authorization decisions

　　只使用受信任系統(tǒng)的對象，例如服務器端會話對象，來進行訪問授權決定。