安全编码实践
快速参考指南
Secure coding practice checklist
安全编码实践清单
输入验证:
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 (%00)
o Check for new line characters (%0d, %0a, \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: %c0%ae%c0%ae/
(Utilize canonicalization to address double encoding or other forms of obfuscation attacks)
如果标准常规验证无法处理以下输入,那么他们需要被单独检查。
o 检查空字节 (%00)
o 检查换行符 (%0d, %0a, \r, \n)
o 检查类似”点-点-斜杠" (../ or ..\)的路径转换符 在支持UTF-8扩展字符集编码的情况下检查路径转换符的变体(如%c0%ae%c0%ae/)
(应用规范化手段解决双重编码或者其他类型的混淆攻击)
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
只使用受信任系统的对象,例如服务器端会话对象,来进行访问授权决定。
Use a single site-wide component to check access authorization. This includes libraries that call external authorization services
使用单个组件为网站全局检查访问授权。包括需求外部授权服务的程序库。
Access controls should fail securely
访问控制应当是失效安全的
Deny all access if the application cannot access its security configuration information
如果应用程序不能访问安全设置信息,则拒绝所有访问。
Enforce authorization controls on every request, including those made by server side scripts, "includes" and requests from rich client-side technologies like AJAX and Flash
对每一次请求强制执行授权控制,包括由服务器端脚本生成的请求,”包含”指令,以及由AJAX或FLASH等丰富客户端生成的请求
Segregate privileged logic from other application code
将特权逻辑与其他应用程序代码隔离
Restrict access to files or other resources, including those outside the application’s direct control, to only authorized users
限制只能由授权用户访问文件及其他资源,包括不在应用程序之间控制下的资源。
Restrict access to protected URLs to only authorized users
限制只有授权用户可以访问被保护的URL
Restrict access to protected functions to only authorized users
限制只有授权用户可以访问被保护的功能
Restrict direct object references to only authorized users
限制只有授权用户可以进行直接对象引用
Restrict access to services to only authorized users
限制只有授权用户可以访问服务
Restrict access to application data to only authorized users
限制只有授权用户可以访问应用程序数据
Restrict access to user and data attributes and policy information used by access controls
通过访问控制限制对用户和数据属性以及策略信息的访问
Restrict access security-relevant configuration information to only authorized users
限制只有授权用户可以访问安全相关的配置信息
Server side implementation and presentation layer representations of access control rules must match
访问控制规则在服务器端的实现必要和表现层的表现一致
If state data must be stored on the client, use encryption and integrity checking on the server side to catch state tampering.
如果状态数据必要保存在客户端,在服务器端需要使用加密和完整性测试来防止篡改状态
Enforce application logic flows to comply with business rules
应用程序逻辑流程必要强制性符合商业规则
Limit the number of transactions a single user or device can perform in a given period of time. The transactions/time should be above the actual business requirement, but low enough to deter automated attacks
限制单一用户或设备在给定时间内可以进行的交易次数。交易数与时间比必要高于现实商业应用的需求,但不能太高以防止自动攻击。
Use the "referer" header as a supplemental check only, it should never be the sole authorization check, as it is can be spoofed
仅将”referer”头文件作为辅助检测,它不能作为独立的授权检测,因为很容易被欺骗。
If long authenticated sessions are allowed, periodically re-validate a user’s authorization to ensure that their privileges have not changed and if they have, log the user out and force them to re-authenticate
如果允许长身份验证会话,定期验证用户授权以确认他们的权限没有发生变化,如果权限有变化,则将用户强制登出并要求身份验证。
Implement account auditing and enforce the disabling of unused accounts (e.g., After no more than 30 days from the expiration of an account’s password.)
实现账户审核并强制禁用未使用的账户(例如密码过期超过30天的账户)
The application must support disabling of accounts and terminating sessions when authorization ceases (e.g., Changes to role, employment status, business process, etc.)
应用程序必要支持在授权消失时禁用账户及终止会话(例如,工作岗位,雇佣状态,商业流程的变更等等)
Service accounts or accounts supporting connections to or from external systems should have the least privilege possible
服务账户或者支持外部系统连接的账户应当被赋予最低级别的权限
Create an Access Control Policy to document an application’s business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled. This includes identifying access requirements for both the data and system resources
创建访问控制策略以记录应用程序的商业规则,数据类型,访问授权材料及/或进程使访问在发生前就可以适当的预防和控制。其中包括分辨对数据和系统资源的不同访问需求
Cryptographic Practices:
加密实践
All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system (e.g., The server)
所有用于防止应用程序用户获取秘密的加密函数必要在受信任系统上实现(例如服务器)
Protect master secrets from unauthorized access
防止主要秘密被未授权访问获取
Cryptographic modules should fail securely
加密模块应当是失效安全的
All random numbers, random file names, random GUIDs, and random strings should be generated using the cryptographic module’s approved random number generator when these random values are intended to be un-guessable
如果需要无法猜测的随机值的话,所有随机数字,随机文件名,随机访客用户名,随机字符串必要使用加密模块认证的随机数生成器生成。
Cryptographic modules used by the application should be compliant to FIPS 140-2 or an equivalent standard. (See http://csrc.nist.gov/groups/STM/cmvp/validation.html)
应用程序使用的加密模块应当符合 FIPS 140-2或同等级别的标准(参见http://csrc.nist.gov/groups/STM/cmvp/validation.html)
Establish and utilize a policy and process for how cryptographic keys will be managed
建立和实现密钥管理的策略和进程。
Error Handling and Logging:
错误处理以及日志记录
Do not disclose sensitive information in error responses, including system details, session identifiers or account information
不要在错误响应内包含任何敏感信息,包括系统细节,会话标识符或账户信息等
Use error handlers that do not display debugging or stack trace information
使用不会显示调试或堆栈跟踪信息的错误处理器
Implement generic error messages and use custom error pages
实现通用错误消息并使用自定义错误页
The application should handle application errors and not rely on the server configuration
应用程序应当可以处理应用程序错误而不必依赖服务器设置
Properly free allocated memory when error conditions occur
错误发生时正确释放已分配内存
Error handling logic associated with security controls should deny access by default
与安全控制相关的错误处理逻辑应当被默认不可访问
All logging controls should be implemented on a trusted system (e.g., The server)
所有的日志记录控制必要在受信任系统上实现(例如服务器)
Logging controls should support both success and failure of specified security events
日志记录控制应当支持对特定安全事件的记录,无论成功失败。
Ensure logs contain important log event data
确保日志中包含重要的记录事件数据
Ensure log entries that include un-trusted data will not execute as code in the intended log viewing interface or software
确保日志中包含不受信任数据的部分条目不会在日志观察界面或软件中被作为代码执行
Restrict access to logs to only authorized individuals
限制只有授权用户可以访问日志
Utilize a master routine for all logging operations
为所有日志记录操作设定一个主程序
Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords
不要再日志中存储敏感信息,如无关的系统细节,会话标识符或密码
Ensure that a mechanism exists to conduct log analysis
确保存在支持日志分析的机制
Log all input validation failures
记录所有失败的输入验证
Log all authentication attempts, especially failures
记录所有身份验证尝试,尤其是失败的
Log all access control failures
记录所有失败的访问控制
Log all apparent tampering events, including unexpected changes to state data
记录所有有篡改可能的事件,包括预期外的对状态数据的修改
Log attempts to connect with invalid or expired session tokens
记录用无效或过期的会话令牌连接的尝试
Log all system exceptions
记录所有系统例外
Log all administrative functions, including changes to the security configuration settings
记录所有管理职能的使用,包括对安全配置设定的修改
Log all backend TLS connection failures
记录所有后端传输层安全连接失败
Log cryptographic module failures
记录加密模块失败
Use a cryptographic hash function to validate log entry integrity
使用加密哈希函数来验证日志条目完整性
Data Protection:
数据保护
Implement least privilege, restrict users to only the functionality, data and system information that is required to perform their tasks
实现最低权限,限制用户只能获取任务所需的功能数据及系统信息
Protect all cached or temporary copies of sensitive data stored on the server from unauthorized access and purge those temporary working files a soon as they are no longer required.
保护所有服务器端敏感数据的缓存或临时副本不被未授权访问获取,并在这些临时文件无用时尽快将它们清理
Encrypt highly sensitive stored information, like authentication verification data, even on the server side. Always use well vetted algorithms, see "Cryptographic Practices" for additional guidance
即使是在服务器端,也要将高敏感度的存储的信息进行类似身份验证的加密。使用经过良好审核的算法。更多的指南参见“加密实践“
Protect server-side source-code from being downloaded by a user
保护服务器端源代码不被用户下载
Do not store passwords, connection strings or other sensitive information in clear text or in any non-cryptographically secure manner on the client side. This includes embedding in insecure formats like: MS viewstate, Adobe flash or compiled code
不要用明文或任何非加密的形式存储密码,连接字符串
Remove comments in user accessible production code that may reveal backend system or other sensitive information
移除用户可访问的产品代码中可能揭示后端系统或其他敏感信息的注释
Remove unnecessary application and system documentation as this can reveal useful information to attackers
移除非必要的应用程序及系统文档,因为它们可能为攻击者提供有用的信息
Do not include sensitive information in HTTP GET request parameters
在HTTP GET请求参数中不要包含敏感信息
Disable auto complete features on forms expected to contain sensitive information, including authentication
在可能包含敏感信息的表格如身份验证中内禁止自动完成功能。
Disable client side caching on pages containing sensitive information. Cache-Control: no-store, may be used in conjunction with the HTTP header control "Pragma: no-cache", which is less effective, but is HTTP/1.0 backward compatible
禁止客户端对包含敏感信息的页面进行缓存。为此目的,可以将”Cache Control: no-store”和效果较差但向后兼容HTTP/1.0的HTTP头控制”Pragma: no-cache”共同使用。
The application should support the removal of sensitive data when that data is no longer required. (e.g. personal information or certain financial data)
应用程序应当支持在不再需要敏感数据的时候将其移除(例如个人信息或特定金融数据)
Implement appropriate access controls for sensitive data stored on the server. This includes cached data, temporary files and data that should be accessible only by specific system users
为存储在服务器上的敏感数据实现适当的访问控制。包括缓存数据,临时文件以及应当只有特定系统用户可以访问的数据
Communication Security:
通信安全
Implement encryption for the transmission of all sensitive information. This should include TLS for protecting the connection and may be supplemented by discrete encryption of sensitive files or non-HTTP based connections
实现所有敏感信息传输的加密传输。包括用于保护连接的TSL(传输层安全协议)以及离散敏感文件加密或非HTTP的网络连接
TLS certificates should be valid and have the correct domain name, not be expired, and be installed with intermediate certificates when required
传输层安全协议证书应当有效并有正确的域名,未过期,并在需求的情况下和中间证明一同安装
Failed TLS connections should not fall back to an insecure connection
失败的传输层安全连接应当不会试图建立不安全的连接
Utilize TLS connections for all content requiring authenticated access and for all other sensitive information
为所有需要身份验证才能访问的内容以及其他敏感信息应用传输层安全连接
Utilize TLS for connections to external systems that involve sensitive information or functions
为涉及敏感信息或功能的外部系统应用传输层安全连接
Utilize a single standard TLS implementation that is configured appropriately
使用一个经过合理配置的单独的标准的应用层安全实现
Specify character encodings for all connections
为所有连接指定字符编码
Filter parameters containing sensitive information from the HTTP referer, when linking to external sites
当链接到外部站点时,过滤HTTP引用中包含敏感信息的参数
System Configuration:
系统配置
Ensure servers, frameworks and system components are running the latest approved version
确保服务器,主机以及系统组件上运行的是最新批准版本的操作系统
Ensure servers, frameworks and system components have all patches issued for the version in use
确保服务器,主机以及系统组件安装了所有当前版本操作系统的补丁
Turn off directory listings
关闭目录列表
Restrict the web server, process and service accounts to the least privileges possible
限制web服务器,进程以及服务账户为最低权限
When exceptions occur, fail securely
例外发生时,确保无效安全
Remove all unnecessary functionality and files
移除所有非必要的功能和文件
Remove test code or any functionality not intended for production, prior to deployment
部署前,移除测试代码或任何并非用于产品的功能
Prevent disclosure of your directory structure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory. Then "Disallow" that entire parent directory in the robots.txt file rather than Disallowing each individual directory
将所有不适合被公共索引的目录置于一个独立的父目录下,以防止在robots.txt文件中泄露你的目录结构。然后在robots.txt文件中”禁止”整个父目录而不是禁止每个单独的目录
Define which HTTP methods, Get or Post, the application will support and whether it will be handled differently in different pages in the application
定义应用程序支持何种HTTP方法,GET或POST,并决定是否在应用程序的不同页面支持不同方法
Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is required, utilize a well-vetted authentication mechanism
禁用不必要的HTTP方法,如WebDAV扩展。如果需要支持文件处理的扩展HTTP方法,那么应用一个良好审阅国的身份验证机制
If the web server handles both HTTP 1.0 and 1.1, ensure that both are configured in a similar manor or insure that you understand any difference that may exist (e.g. handling of extended HTTP methods)
如果web服务器支持HTTP1.0和1.1,确保二者以类似的方式被配置,或者确定你理解其中可能存在的差异(例如如何处理扩展HTTP方法)
Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks
移除HTTP响应头内关于操作系统,web服务器版本及应用框架的无用信息。
The security configuration store for the application should be able to be output in human readable form to support auditing
应用程序的安全配置存储应当可以人类可读的形式输出,以支持审核
Implement an asset management system and register system components and software in it
实现一个资产管理系统并在其中注册系统组件及软件
Isolate development environments from the production network and provide access only to authorized development and test groups. Development environments are often configured less securely than production environments and attackers may use this difference to discover shared weaknesses or as an avenue for exploitation
将开发环境与产品网络分离,只能由被授权的开发组及测试组访问。开发环境的安全性往往被设置的较产品环境低,攻击者可能由此发现二者共享的弱点或以之为攻击大道
Implement a software change control system to manage and record changes to the code both in development and production
实现一个软件变更控制系统,用于管理和记录开发及产品中的代码变更
Database Security:
数据库安全
Use strongly typed parameterized queries
使用强类型的参数化查询
Utilize input validation and output encoding and be sure to address meta characters. If these fail, do not run the database command
利用输入验证和输出编码,并确保能解决元字符。如果验证编码失败,不要运行数据库命令
Ensure that variables are strongly typed
确保变量是强类型
The application should use the lowest possible level of privilege when accessing the database
应用程序访问数据库时应当使用最低级别的权限
Use secure credentials for database access
为数据库访问使用安全证书
Connection strings should not be hard coded within the application. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted.
连接字符串不应当通过应用程序中的硬编码实现。连接字符串应当存储在一个受信任系统上的单独的配置文件内,并且进行加密
Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database
使用存储过程来抽象数据访问,并且允许移除访问数据库中基表的权限
Close the connection as soon as possible
尽快关闭连接
Remove or change all default database administrative passwords. Utilize strong passwords/phrases or implement multi-factor authentication
移除或变更所有数据库的默认管理密码。使用强密码/短语或实现多要素身份验证
Turn off all unnecessary database functionality (e.g., unnecessary stored procedures or services, utility packages, install only the minimum set of features and options required (surface area reduction))
关闭所有非必要的数据库功能(例如,不必要的存储过程或服务,实用工具包,只安装所需功能和选项的最小集合(面积减少))
Remove unnecessary default vendor content (e.g., sample schemas)
移除非必要的供应商默认内容(例如示例模式)
Disable any default accounts that are not required to support business requirements
移除所有商业需求不必要的默认账户
The application should connect to the database with different credentials for every trust distinction (e.g., user, read-only user, guest, administrators)
应用程序在连接到数据库时应当为每种信用等级使用不同的证书(例如,用户,只读用户,访客,管理员)
File Management:
文件管理
Do not pass user supplied data directly to any dynamic include function
不要将用户提供的数据直接发送到任何动态包含函数
Require authentication before allowing a file to be uploaded
在允许文件上传前要求身份验证
Limit the type of files that can be uploaded to only those types that are needed for business purposes
限制只能上传商业用途所需的文件类型
Validate uploaded files are the expected type by checking file headers. Checking for file type by extension alone is not sufficient
检查头文件以验证上传文件的类型。不能仅通过扩展名检查文件类型
Do not save files in the same web context as the application. Files should either go to the content server or in the database.
不要和应用程序在同一个web系统中存储文件。文件应当存储在内容服务器或者数据库中。
Prevent or restrict the uploading of any file that may be interpreted by the web server.
禁止或限制上传任何可能被web服务器解读的文件
Turn off execution privileges on file upload directories
关闭文件上传目录中的执行权限
Implement safe uploading in UNIX by mounting the targeted file directory as a logical drive using the associated path or the chrooted environment
应用相关路径或者chroot环境,将目标文件目录作为逻辑驱动器使用,从而在UNIX系统中实现安全上传
When referencing existing files, use a white list of allowed file names and types. Validate the value of the parameter being passed and if it does not match one of the expected values, either reject it or use a hard coded default file value for the content instead
引用已存在文件时,使用包含被允许的文件名和文件类型的白名单。验证传输参数值,如果不匹配预期值,或者拒绝,或者为该内容使用一个硬编码的默认文件值
Do not pass user supplied data into a dynamic redirect. If this must be allowed, then the redirect should accept only validated, relative path URLs
不要发送用户提供的数据到动态重定向。如果必须实现,那么只能重定向到经验证的,相关路径网址
Do not pass directory or file paths, use index values mapped to pre-defined list of paths
不要发送目录或文件命令,应当使用映射到预定义的路径列表的索引值
Never send the absolute file path to the client
不要将绝对文件路径发送给客户端
Ensure application files and resources are read-only
确保应用程序文件和资源的只读属性
Scan user uploaded files for viruses and malware
对用户上传的文件进行病毒和恶意软件的查杀
Memory Management:
内存管理
Utilize input and output control for un-trusted data
为不受信任的数据应用输入输出控制
Double check that the buffer is as large as specified
仔细检查确认缓冲区大小符合说明
When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string
当使用允许多字符复制的函数,例如strncpy()时,需要注意如果目标缓冲区的大小与源缓冲区大小相等,该函数可能不会将字符串NULL终止
Check buffer boundaries if calling the function in a loop and make sure there is no danger of writing past the allocated space
在循环调用函数时检查缓冲区边界,确认不会出现写入超过分配空间的数据的危险
Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions
在将输入字符串传入复制与串联函数前,先将他们截短到合适的长度。
Specifically close resources, don’t rely on garbage collection. (e.g., connection objects, file handles, etc.)
手动关闭资源,不要依赖垃圾回收机制。(如连接对象,文件处理等)
Use non-executable stacks when available
可能的情况下,使用非可执行堆栈
Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.)
避免使用已知有缺陷的函数(如printf,strcat,strcpy等)
Properly free allocated memory upon the completion of functions and at all exit points
在函数完成时以及所有的退出点,正确释放已分配的内存
General Coding Practices:
通用编程实践
Use tested and approved managed code rather than creating new unmanaged code for common tasks
为普通任务使用经过测试和核准的托管代码,而不是创建新的非托管代码
Utilize task specific built-in APIs to conduct operating system tasks. Do not allow the application to issue commands directly to the Operating System, especially through the use of application initiated command shells
使用任务专用的内置应用程序接口以进行操作系统任务。不要让应用程序直接向操作系统发起命令,尤其是通过使用应用程序生成的命令壳。
Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files
用校验或者哈希来验证解释代码,程序库,可执行文件以及配置文件的完整性
Utilize locking to prevent multiple simultaneous requests or use a synchronization mechanism to prevent race conditions
应用锁定技术来阻止大量同时请求或使用同步机制来阻止争用情况
Protect shared variables and resources from inappropriate concurrent access
保护共享变量和资源免于不恰当的并行访问
Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage
在定义或初次使用前,明确初始化所有变量及其他数据存储
In cases where the application must run with elevated privileges, raise privileges as late as possible, and drop them as soon as possible
如果应用程序必要提升权限才能运行,那么提升权限越晚越好,之后降低权限越快越好。
Avoid calculation errors by understanding your programming language’s underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation
通过理解编程语言的底层表示及其如何操作数字运算来避免运算错误。密切注意字节大小的差异,精度,符号/无符号的区别,截断,数据类型的转化和合并,“非数字“运算,以及编程语言如何处理对于底层表示过大或过小的数字
Do not pass user supplied data to any dynamic execution function
不要将用户提供的数据传输到任何动态执行函数
Restrict users from generating new code or altering existing code
限制用户生成新代码或改变已有代码
Review all secondary applications, third party code and libraries to determine business necessity and validate safe functionality, as these can introduce new vulnerabilities
检查所有二次应用,第三方代码以及程序库的商业必要性并验证安全功能,因为它们可能为应用程序引入新的弱点
Implement safe updating. If the application will utilize automatic updates, then use cryptographic signatures for your code and ensure your download clients verify those signatures. Use encrypted channels to transfer the code from the host server
实现安全升级。如果应用程序使用自动升级功能,那么要为代码使用加密签名并确认下载客户端对签名进行验证。使用加密频道从主机服务器传输代码
|