安全编码实践清单
输入验证:
Conduct all data validation on a trusted system (e.g., The server)
在受信任系统上进行全部数据验证。(例如服务器)
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
各类应用应当具有统一的输入验证规则。
Specify proper character sets, such as UTF-8, for all sources of input
为所有输入源指定适当的统一字符集，例如UTF-8字符集。
Encode data to a common character set before validating (Canonicalize)
在验证前将数据用统一字符集进行编码。(规范化) 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
确认系统是否支持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)
如果标准常规验证无法处理以下输入，那么他们需要被单独检查。
o 检查空字节 ()
o 检查换行符 ( , , \r, \n)
o 检查类似”点-点-斜杠" (../ or ..\)的路径转换符 在支持UTF-8扩展字符集编码的情况下检查路径转换符的变体(如��/)
(应用规范化手段解决双重编码或者其他类型的混淆攻击)
Output Encoding:
输出编码
Conduct all encoding on a trusted system (e.g., The server)
在受信任系统上进行全部编码程序。(例如服务器)
Utilize a standard, tested routine for each type of outbound encoding
为每一种出站编码建立一个经过测试的标准规范
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
清洁所有不受信任数据对操作系统命令的输出。
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)
所有身份验证控制必要在受信任系统上执行(例如服务器)
Establish and utilize standard, tested, authentication services whenever possible
只要可能，就应当建立并应用标准化并经过测试的的身份验证服务
Use a centralized implementation for all authentication controls, including libraries that call external authentication services
为所有身份验证控制建立集中的身份验证控制系统，包括需要外部身份验证服务的程序库
Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control
对身份验证逻辑与被访问资源进行隔离，使用重定向来访问集中身份验证控制系统。
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).
密码哈希只能在被信任的系统上实现(例如服务器)
Validate the authentication data only on completion of all data input, especially for sequential authentication implementations
只有在数据输入完成后才能进行身份验证数据的验证，尤其是在实现连续身份验证的情况下。
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
对外部系统的连接，如果涉及到敏感信息或功能的，需要进行身份验证。
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
访问应用程序外部服务的身份验证证书需要加密保存在一个受信任系统(例如服务器)中的受保护区域内。保存在源代码内不安全
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)
强制执行策略或监管要求的密码复杂度规定。身份验证证书应当足以抵御部署环境中常见的攻击模式。(例如，要求密码中包括字母和数字及/或特殊字符)
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
强制执行策略或监管要求的密码长度规定。通常使用的是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.
修改和重置密码的操作需要与创建账户及身份验证同等级别的控制。
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
使用基于电子邮件的密码重置功能时，只发送包含临时链接/密码的邮件到预先注册的地址。
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
强制执行策略或监管要求的密码更改。关键系统可能需要更频繁的更改。密码更改的时间间隔需要由管理员人工控制。
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
实现监视识别对多个用户账户使用相同密码进行攻击的功能。这种攻击模式可以规避账户因多次登录失败而停用的时间，前提是用户名被大量窃取或猜测，。
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)
会话标识符必要在被信任的系统上创建(例如服务器)
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
在平衡风险和商业功能需求的基础上，会话闲置超时的时间越短越好。大多数情况下不应多于几个小时
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
禁止长期登录，即使在会话激活的情况下，也要强制定期终结会话。尤其是支持丰富网络连接或者连接到关键系统的应用程序。
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的时候——在身份验证中可能发生——生成新的会话标识符。在应用程序内部，建议完全应用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
只使用受信任系统的对象，例如服务器端会话对象，来进行访问授权决定。
