OWASP安全编码规范详情

《OWASP安全编码规范详情》由会员分享，可在线阅读，更多相关《OWASP安全编码规范详情（10页珍藏版）》请在金锄头文库上搜索。

1、OWASPOWASP 安全编码规范详情安全编码规范详情0x00 原则 概览开发安全的软件需要对安全原则有基本的了解。虽然对于安全原则的全面评估超出了本指南的范围，但是我们还是提供了一个快速的概览。软件安全的目标是要维护信息资源的 保密性 ， 完整性 ，和 可用性 ，以确保业务的成功运作。该目标通过实施 安全控制 来实现。本指南重点介绍具体的技术控制，以 缓解 常见软件 漏洞 的发生。虽然主要的关注点是 Web 应用程序及其配套的基础设施，但是本指南的大部分内容可应用于任意软件部署平台。为了保护业务免受来自与软件相关的不能接受的风险，了解风险的意义是很有帮助的。风险是一组威胁业务成功因素的集合。

2、它可以被定义为：一个 威胁代理 与一个可能含有 漏洞 的 系统 交互，该漏洞可被 利用 并造成 影响 。虽然这可能看起来象是一个抽象的概念，但可以这样想象它：一个汽车盗窃犯（威胁代理）来到一个停车场（系统）寻找没有锁车门（漏洞）的车，当找到一个时，他们打开门（利用）并拿走里面任何的东西（影响）。所有这些因素在安全软件开发时都扮演了一个角色。开发团队采用的方法和攻击者攻击应用程序所采用的方法之间有一个根本区别。开发团队通常采用的方法是基于应用程序的目的行为。换句话说，开发团队根据功能需求文档和用例设计一个应用程序以执行特定的任务。而另一方面，攻击者，基于“没有具体说明应拒绝的行为，则被认为是可行

3、的”原则，对于应用程序可以做什么更感兴趣。为了解决这个问题，一些额外的元素需要被集成到软件生命周期的早期阶段。这些新元素是 安全需求 和 滥用实例 。本指南旨在帮助明确高等级的安全需求，并解决许多常见的滥用情况。Web 开发团队应当明白，基于客户端的输入验证、隐藏字段和界面控件（例如，下拉键和单选按钮）的客户端控制，所带来的安全性收益是有限的，这一点非常重要。攻击者可以使用工具，比如：客户端的 Web 代理（例如，OWASP WebScarab，Burp）或网络数据包捕获工具（例如，Wireshark），进行应用程序流量分析，提交定制的请求，并绕过所有的接口。另外，Flash，JavaAppl

4、et 和其它客户端对象可以被反编译并进行漏洞分析。软件的安全漏洞可以在软件开发生命周期的任何阶段被引入，包括： 最初没有明确的安全需求； 创建有逻辑错误的概念设计； 使用糟糕的编码规范，从而带来了技术漏洞； 软件部署不当； 在维护或者更新过程中引入缺陷。此外，还有重要的一点需要明白，软件漏洞可以超出软件本身的范围。根据不同的软件、漏洞和配套基础设施的性质，一次成功的攻击会影响下面任何或者所有的方面： 软件和其相关的信息； 相关服务器的操作系统； 后端数据库； 在共享环境中的其它应用程序； 用户的系统； 与用户交互的其它软件。0x010x01 输入验证输入验证 在可信系统（比如：服务器）上执行所

5、有的数据验证。 识别所有的数据源，并将其分为可信的和不可信的。验证所有来自不可信数据源（比如：数据库，文件流，等）的数据。 应当为应用程序应提供一个集中的输入验证规则。 为所有输入明确恰当的字符集，比如：UTF-8。 在输入验证前，将数据按照常用字符进行编码（ 规范化 ）。 丢弃任何没有通过输入验证的数据。 确定系统是否支持 UTF-8 扩展字符集，如果支持，在 UTF-8 解码完成以后进行输入验证。 在处理以前，验证所有来自客户端的数据，包括：所有参数、URL、HTTP 头信息（比如：cookie 名字和数据值）。确定包括了来自 JavaScript、Flash 或其他嵌入代码的 post

6、back 信息。 验证在请求和响应的报头信息中只含有 ASCII 字符。 核实来自重定向输入的数据（一个攻击者可能向重定向的目标直接提交恶意代码，从而避开应用程序逻辑以及在重定向前执行的任何验证）。 验证正确的数据类型。 验证数据范围。 验证数据长度。 尽可能采用“白名单”形式，验证所有的输入。 如果任何潜在的 危险字符 必须被作为输入，请确保您执行了额外的控制，比如：输出编码、特定的安全 API、以及在应用程序中使用的原因。部分常见的危险字符包括： “ % ( ) & + “ 。 如果您使用的标准验证规则无法验证下面的输入，那么它们需要被单独验证：o 验证空字节 (%00)；o 验证换行符

7、(%0d, %0a, r, n)；o 验证路径替代字符“点-点-斜杠”（/或 ）。如果支持 UTF-8 扩展字符集编码，验证替代字符： %c0%ae%c0%ae/ (使用 规范化 验证双编码或其他类型的编码攻击)。0x020x02 输出编码输出编码 在可信系统（比如：服务器）上执行所有的编码。 为每一种输出编码方法采用一个标准的、已通过测试的规则。 通过语义输出编码方式，对所有返回到客户端的来自于应用程序信任边界之外的数据进行编码。HTML 实体编码是一个例子，但不是在所有的情况下都可用。 除非对目标编译器是安全的，否则请对所有字符进行编码。 针对 SQL、XML 和 LDAP 查询，语义净化

8、所有不可信数据的输出。 对于操作系统命令，净化所有不可信数据输出。0x030x03 身份验证和密码管理身份验证和密码管理 除了那些特定设为“公开”的内容以外，对所有的网页和资源要求身份验证。 所有的身份验证过程必须在可信系统（比如：服务器）上执行。 在任何可能的情况下，建立并使用标准的、已通过测试的身份验证服务。 为所有身份验证控制使用一个集中实现的方法，其中包括利用库文件请求外部身份验证服务。 将身份验证逻辑从被请求的资源中隔离开，并使用重定向到或来自集中的身份验证控制。 所有的身份验证控制应当安全的处理未成功的身份验证。 所有的管理和账户管理功能至少应当具有和主要身份验证机制一样的安全性。

9、 如果您的应用程序管理着凭证的存储，那么应当保证只保存了通过使用强加密单向 salted 哈希算法得到的密码，并且只有应用程序具有对保存密码和密钥的表/文件的写权限（如果可以避免的话，不要使用 MD5 算法）。 密码哈希必须在可信系统（比如：服务器）上执行。 只有当所有的数据输入以后，才进行身份验证数据的验证，特别是对连续身份验证机制。 身份验证的失败提示信息应当避免过于明确。比如：可以使用“用户名和/或密码错误”，而不要使用“用户名错误”或者“密码错误”。错误提示信息在显示和源代码中应保持一致。 为涉及敏感信息或功能的外部系统连接使用身份验证。 用于访问应用程序以外服务的身份验证凭据信息应当

10、加密，并存储在一个可信系统（比如：服务器）中受到保护的地方。源代码不是一个安全的地方。 只使用 HTTP Post 请求传输身份验证的凭据信息。 非临时密码只在加密连接中发送或作为加密的数据（比如，一封加密的邮件）。通过邮件重设临时密码可以是一个例外。 通过政策或规则加强密码复杂度的要求（比如：要求使用字母、数字和/或特殊符号）。身份验证的凭据信息应当足够复杂以对抗在其所部署环境中的各种威胁攻击。 通过政策和规则加强密码长度要求。常用的是 8 个字符长度，但是 16 个字符长度更好，或者考虑使用多单词密码短语。 输入的密码应当在用户的屏幕上模糊显示（比如：在 Web 表单中使用“passwor

11、d”输入类型）。 当连续多次登录失败后（比如：通常情况下是 5 次），应强制锁定账户。账户锁定的时间必须足够长，以阻止暴力攻击猜测登录信息，但是不能长到允许执行一次拒绝服务攻击。 密码重设和更改操作需要类似于账户创建和身份验证的同样控制等级。 密码重设问题应当支持尽可能随机的提问（比如：“最喜爱的书”是一个坏的问题，因为圣经是最常见的答案）。 如果使用基于邮件的重设，只将临时链接或密码发送到预先注册的邮件地址。 临时密码和链接应当有一个短暂的有效期。 当再次使用临时密码时，强制修改临时密码。 当密码重新设置时，通知用户。 阻止密码重复使用。 密码在被更改前应当至少使用了一天，以阻止密码重用攻击

12、。 根据政策或规则的要求，强制定期更改密码。关键系统可能会要求更频繁的更改。更改时间周期必须进行明确。移动电玩城 http:/ 为密码填写框禁用“记住密码”功能。 用户账号的上一次使用信息（成功或失败）应当在下一次成功登录时向用户报告。 执行监控以确定针对使用相同密码的多用户帐户攻击。当用户 ID 可以被得到或被猜到时，该攻击模式用来绕开标准的锁死功能。 更改所有厂商提供的默认用户 ID 和密码，或者禁用相关帐号。 在执行关键操作以前，对用户再次进行身份验证。 为高度敏感或重要的交易账户使用多因子身份验证机制。 如果使用了第三方身份验证的代码，仔细检查代码以保证其不会受到任何恶意代码的影响。0

13、x040x04 会话管理会话管理 使用服务器或者框架的会话管理控制。应用程序应当只识别有效的会话标识符。 会话标识符必须总是在一个可信系统（比如：服务器）上创建。 会话管理控制应当使用通过审查的算法以保证足够的随机会话标识符。 为包含已验证的会话标识符的 cookie 设置域和路径，以为站点设置一个恰当的限制值。 注销功能应当完全终止相关的会话或连接。 注销功能应当可用于所有受身份验证保护的网页。 在平衡的风险和业务功能需求的基础上，设置一个尽量短的会话超时时间。通常情况下，应当不超过几个小时。 禁止连续的登录并强制执行周期性的会话终止，即使是活动的会话。特别是对于支持富网络连接或连接到关键系

14、统的应用程序。终止时机应当可以根据业务需求调整，并且用户应当收到足够的通知已减少带来的负面影响。 如果一个会话在登录以前就建立，在成功登录以后，关闭该会话并创建一个新的会话。 在任何重新身份验证过程中建立一个新的会话标识符。 不允许同一用户 ID 的并发登录。 不要在 URL、错误信息或日志中暴露会话标识符。会话标识符应当只出现在 HTTP cookie 头信息中。比如，不要将会话标识符以 GET 参数进行传递。 通过在服务器上使用恰当的访问控制，保护服务器端会话数据免受来自服务器其他用户的未授权访问。 生成一个新的会话标识符并周期性地使旧会话标识符失效（这可以缓解那些原标识符被获得的特定会话

15、劫持情况）。 在身份验证的时候，如果连接从 HTTP 变为 HTTPS，则生成一个新的会话标识符。在应用程序中，推荐持续使用 HTTPS，而非在 HTTP 和 HTTPS 之间转换。 为服务器端的操作执行标准的会话管理，比如，通过在每个会话中使用强随机令牌或参数来管理账户。该方法可以用来防止跨站点请求伪造攻击。 通过在每个请求或每个会话中使用强随机令牌或参数，为高度敏感或关键的操作提供标准的会话管理。 为在 TLS 连接上传输的 cookie 设置“安全”属性。 将 cookie 设置为 HttpOnly 属性，除非在应用程序中明确要求了客户端脚本程序读取或者设置 cookie 的值。0x05

16、0x05 访问控制访问控制 只使用可信系统对象（比如：服务器端会话对象）以做出访问授权的决定。 使用一个单独的全站点部件以检查访问授权。这包括调用外部授权服务的库文件。 安全的处理访问控制失败的操作。 如果应用程序无法访问其安全配置信息，则拒绝所有的访问。 在每个请求中加强授权控制，包括：服务器端脚本产生的请求，“includes”和来自象 AJAX 和 FLASH 那样的富客户端技术的请求。 将有特权的逻辑从其他应用程序代码中隔离开。 限制只有授权的用户才能访问文件或其他资源，包括那些应用程序外部的直接控制。 限制只有授权的用户才能访问受保护的 URL。 限制只有授权的用户才能访问受保护的功能。 限制只有授权的用户才能访问直接对象引用。 限制只有授权的用户才能访问服务。 限制只有授权的用户才能访问应用程序数据。 限制通过使用