OWASP TOP10

OWASP TOP10

整理和记录OWASP TOP10

1.注入

当不可信的数据作为命令或查询语句的一部分被发送给解释器的时候，会发生注入漏洞，包括SQL、NoSQL、OS以及LDAP注入等。攻击者发送的恶意数据可能会诱使解释器执行计划外的命令，或在没有适当授权的情况下访问数据。

防范

防止注入漏洞需要将数据与命令语句、查询语句分隔开来。

• 最佳选择是使用安全的API，完全避免使用解释器，或提供参数 化界面的接口，或迁移到ORM或实体框架。
• 注意：当参数化时，存储过程仍然可以引入SQL注入，如果 PL/SQL或T-SQL将查询和数据连接在一起，或者执行带有立即 执行或exec()的恶意数据。
• 使用正确的或“白名单”的具有恰当规范化的输入验证方法同样 会有助于防止注入攻击，但这不是一个完整的防御，因为许多应 用程序在输入中需要特殊字符，例如文本区域或移动应用程序的 API。
• 对于任何剩余的动态查询，可以使用该解释器的特定转义语法转 义特殊字符。OWASP的Java Encoder和类似的库提供了这样的 转义例程。
• 注意：SQL结构，比如：表名、列名等无法转义，因此用户提供 的结构名是非常危险的。这是编写软件中的一个常见问题。 • 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入时大量地泄露记录。

攻击案例场景

场景#1：应用程序在下面存在脆弱性的SQL语句的构造中使用不 可信数据： String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'“;

场景#2：同样的，框架应用的盲目信任，仍然可能导致查询语句 的漏洞。（例如：Hibernate查询语言（HQL））： Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

在这两个案例中，攻击者在浏览器中将“id”参数的值修改成： ’ or’1’=’1。例如： http://example.com/app/accountView?id=' or '1'='1 这样查询语句的意义就变成了从accounts表中返回所有的记录。 更危险的攻击可能导致数据被篡改甚至是存储过程被调用。

2.失效的身份认证

与认证和会话管理相关的应用函数经常被错误地实现，从而允许攻击者破坏密码、密钥或是会话令牌，或者利用其他的应用漏洞来暂时或永久地获取用户身份信息。

防范

1.使用内置的会话管理功能

2.通过认证的问候

3.使用单一的入口点

4.确保在一开始登录SSL保护的网页

攻击案例场景

场景#1：凭证填充，使用已知密码的列表，是常见的攻击。如果 应用程序不限制身份验证尝试，则可以将应用程序用作密码oracle， 以确定凭证是否有效。

场景#2：大多数身份验证攻击都是由于使用密码作为唯一的因素。 依据最佳实践，最新的密码轮换和复杂性要求鼓励用户使用、重 用以及重用弱密码。建议组织在NIST-800-63中停止这些实践，并 使用多因素身份验证。

场景#3：应用会话超时设置不正确。用户使用公共计算机访问应 用程序。用户直接关闭浏览器选项卡就离开，而不是选择“注 销”。攻击者一小时后使用同一个浏览器浏览网页，而当前用户 状态仍然是经过身份验证的。

3.敏感信息泄露

许多web应用程序和API不能正确的保护敏感数据，如金融、医疗保健和PII（个人身份信息）等。攻击者可能会窃取或篡改这些弱保护的数据，从而进行信用卡欺诈、身份盗窃或其他犯罪行为。在缺少额外保护（例如，在存放和传输过程中加密，且在与浏览器进行交换时需要特别谨慎）的情况下，敏感数据可能会受到损害。

防范

对一些需要加密的敏感数据，应该起码做到以下几点：

• 对系统处理、存储或传输的数据分类，并根据分类进行访问控制。
• 熟悉与敏感数据保护相关的法律和条例，并根据每项法规要求保 护敏感数据。
• 对于没必要存放的、重要的敏感数据，应当尽快清除，或者通过 PCI DSS标记或拦截。未存储的数据不能被窃取。
• 确保存储的所有敏感数据被加密。
• 确保使用了最新的、强大的标准算法或密码、参数、协议和密匙， 并且密钥管理到位。
• 确保传输过程中的数据被加密，如：使用TLS。确保数据加密被 强制执行，如：使用HTTP严格安全传输协议（HSTS ）。 • 禁止缓存对包含敏感数据的响应。
• 确保使用密码专用算法存储密码，如：Argon2 、 scrypt 、 bcrypt 或者PBKDF2 。将工作因素（延迟因素）设置在可接受 范围。
• 单独验证每个安全配置项的有效性。

攻击案例场景

场景 #1：一个应用程序使用自动化的数据加密系统加密信用卡信 息，并存储在数据库中。但是，当数据被检索时被自动解密，这 就使得SQL注入漏洞能够以明文形式获得所有信用卡卡号。

场景 #2：一个网站上对所有网页没有使用或强制使用TLS，或者使 用弱加密。攻击者通过监测网络流量（如：不安全的无线网络）， 将网络连接从HTTPS降级到HTTP，就可以截取请求并窃取用户会话 cookie。 之后，攻击者可以复制用户cookie并成功劫持经过认证 的用户会话、访问或修改用户个人信息。除此之外，攻击者还可 以更改所有传输过程中的数据，例如：转款的接接收者。

场景 #3：密码数据库使用未加盐的哈希算法或弱哈希算法去存储 每个人的密码。一个文件上传漏洞使黑客能够获取密码文件。所 有这些未加盐哈希的密码通过彩虹表暴力破解方式破解。 由简单 或快速散列函数生成加盐的哈希，也可以通过GPU破解。

4.XML外部实体攻击(XXE)

许多过时的或配置不当的XML处理器在XML文档内进行外部实体引用。外部实体可用于泄露内部文件，通过使用文件URI处理器、内部文件共享、内部端口扫描、远程代码执行以及拒绝服务攻击等手段。

防范

• 尽可能使用简单的数据格式（如：JSON），避免对敏感数据进行序列化。
• 及时修复或更新应用程序或底层操作系统使用的所有XML处理器 和库。同时，通过依赖项检测，将SOAP更新到1.2版本或更高 版本。
• 参考《 OWASP Cheat Sheet ‘XXE Prevention‘ 》，在应用程序 的所有XML解析器中禁用XML外部实体和DTD进程。
• 在服务器端实施积极的（“白名单”）输入验证、过滤和清理， 以防止在XML文档、标题或节点中出现恶意数据。 • 验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证 方法来验证上传的XML文件。
• 尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的 最佳选择，但是SAST 工具可以检测源代码中的XXE漏洞。

攻击案例场景

大量XXE缺陷已经被发现并被公开，这些缺陷包括嵌入式设备的 XXE缺陷。 XXE缺陷存在于许多意想不到的地方，这些地方包括 深嵌套的依赖项。最简单的方法是上传可被接受的恶意XML文件：

场景 #1：攻击者尝试从服务端提取数据： ]> &xxe;

场景 #2：攻击者通过将上面的实体行更改为以下内容来探测服务 器的专用网络： ]>

场景 #3：攻击者通过恶意文件执行拒绝服务攻击： ]>

5.失效的访问控制

限制“认证的用户可以实现哪些操作”的命令没有得到正确的执行。攻击者可以利用这些漏洞访问未经授权的功能和数据，例如访问其他用户的账户，查看敏感文件，篡改其他用户的数据，更改访问权限等。

防范

• 除公有资源外，默认情况下拒绝访问。
• 使用一次性的访问控制机制，并在整个应用程序中不断重用它们， 包括最小化CORS使用。
• 建立访问控制模型以强制执行所有权记录，而不是接受用户创建、 读取、更新或删除的任何记录。
• 域访问控制对每个应用程序都是唯一的，但业务限制要求应由域 模型强制执行。
• 禁用 Web服务器目录列表，并确保文件元数据（如：git）不存 在于 Web的根目录中。
• 记录失败的访问控制，并在适当时向管理员告警（如：重复故 障）。
• 对API和控制器的访问进行速率限制，以最大限度地降低自动化 攻击工具的危害。
• 当用户注销后，服务器上的JWT令牌应失效。

攻击案例场景

场景 #1：应用程序在访问帐户信息的 SQL调用中使用了未经验证 的数据：
pstmt.setString(1，request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
攻击者只需修改浏览器中的“acct”参数即可发送他们想要的任何 帐号信息。如果没有正确验证，攻击者可以访问任何用户的帐户。
http://example.com/app/accountInfo?acct=notmyacct

场景 #2：攻击者仅强制浏览目标URL。管理员权限是访问管理页 面所必需的。

http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo

如果一个未经身份验证的用户可以访问任何页面，那么这是一个 缺陷。如果一个非管理员权限的用户可以访问管理页面，那么这 同样也是一个缺陷。

6.安全配置错误

安全配置错误是最常见的问题。这通常是由不安全的默认配置，不完整或ad hoc配置，开放云存储，错误配置的HTTP标头，以及包含敏感信息的详细错误信息造成的。所有的操作系统、框架、库、应用程序都需要进行安全配置外，还必须要及时进行系统更新和升级。

防范

• 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。 开发、质量保证和生产环境都应该进行相同配置，并且，在每个 环境中使用不同的密码。这个过程应该是自动化的，以尽量减少 安装一个新安全环境的耗费。 • 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档 和示例。移除或不安装不适用的功能和框架。
• 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并 将其作为更新管理过程的一部分。在检查过程中，应特别注意云存储权限（如： S3桶权限）。
• 一个能在组件和用户间提供有效的分离和安全性的分段应用程 序架构，包括：分段、容器化和云安全组。
• 向客户端发送安全指令，如：安全标头。
• 在所有环境中能够进行正确安全配置和设置的自动化过程。

攻击案例场景

场景#1：应用程序服务器附带了未从产品服务器中删除的应用程 序样例。这些样例应用程序具有已知的安全漏洞，攻击者利用这 些漏洞来攻击服务器。如果其中一个应用程序是管理员控制台， 并且没有更改默认账户，攻击者就可以通过默认密码登录，从而 接管服务器。

场景#2：目录列表在服务器端未被禁用。攻击者发现他们很容易 就能列出目录列表。攻击者找到并下载所有已编译的Java类，他 们通过反编译来查看代码。然后，攻击者在应用程序中找到一个 严重的访问控制漏洞。

场景#3：应用服务器配置允许将详细的错误信（如：堆栈跟踪信 息）返回给用户，这可能会暴露敏感信息或潜在的漏洞，如：已 知含有漏洞的组件的版本信息。

场景#4：云服务向其他CSP用户提供默认的网络共享权限。这允 许攻击者访问存储在云端的敏感数据。

7.跨站脚本(XSS)

如果应用程序在未经适当验证或转义的情况下，能够在新网页中包含不受信任的数据，或是使用可以创建HTML或者JavaScript的浏览器API更新包含用户提供的数据的现有网页，就会出现XSS漏洞。XSS允许攻击者在受害者的浏览器中执行脚本，这些脚本可以劫持用户会话、破坏网站或将用户重定向到恶意网站中。

防范

• 使用设计上就会自动编码来解决XSS问题的框架，如：Ruby 3.0 或 React JS。了解每个框架的XSS保护的局限性，并适当地处 理未覆盖的用例。
• 为了避免反射式或存储式的XSS漏洞，最好的办法是根据HTML 输出的上下文（包括：主体、属性、JavaScript、CSS或URL） 对所有不可信的HTTP请求数据进行恰当的转义 。
• 在客户端修改浏览器文档时，为了避免DOM XSS攻击，最好的 选择是实施上下文敏感数据编码。
• 使用内容安全策略（CSP）是对抗XSS的深度防御策略。如果 不存在可以通过本地文件放置恶意代码的其他漏洞（例如：路径 遍历覆盖和允许在网络中传输的易受攻击的库），则该策略是有效的。

攻击案例场景

场景#1：应用程序在下面HTML代码段的构造中使用未经验证或转 义的不可信的数据： (String) page += ""; 攻击者在浏览器中修改“CC” 参数为如下值： '>'. 这个攻击导致受害者的会话ID被发送到攻击者的网站，使得攻击 者能够劫持用户当前会话。

注意：攻击者同样能使用跨站脚本攻破应用程序可能使用的任何 跨站请求伪造（CSRF）防御机制。CSRF的详细情况见2013年版中 的A8项。

8.使用含有已知漏洞的组件

组件（如库、框架和其他软件模块）是以与应用程序相同的权限运行的。如果存在漏洞的组件被利用，这种攻击可能会导致严重的数据丢失或服务器接管危机。使用已知漏洞组件的应用程序和API可能会破坏应用程序的防御系统，从而启动各种形式的攻击，造成更为严重的影响。

防范

• 移除不使用的依赖、不需要的功能、组件、文件和文档。
• 利用如 versions、DependencyCheck 、retire.js等工具来持续的 记录客户端和服务器端以及它们的依赖库的版本信息。持续监控 如CVE 和 NVD等是否发布已使用组件的漏洞信息，可以使用软 件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警 告邮件。
• 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡 改或加入恶意漏洞的风险
• 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打 补丁，可以考虑部署虚拟补丁来监控、检测或保护。

攻击案例场景

场景 #1：很多时候组件都是以与应用相同的权限运行的，这使得 组件里的缺陷可能导致各式各样的问题。这些缺陷可能是偶然的 （如：编码错误），也可能是蓄意的（如：组件里的后门）。下 面是一些已被利用的漏洞：
• CVE-2017-5638，一个Struts2远程执行漏洞。 可在服务端远程 执行代码，并已造成巨大的影响。
• 虽然物联网（IoT）设备一般难以通过打补丁来修复。但对之打 补丁非常重要（如：医疗设备）。
有些自动化工具能帮助攻击者发现未打补丁的或配置不正确的系 统。例如 ：Shodan IOT搜索引擎能帮助你发现从2014年四月至 今仍存在心脏出血漏洞 的设备。

9.不安全的反序列化

不安全的反序列化漏洞通常会导致远程代码执行问题。即使反序列化错误不会导致远程代码执行，也可以被用来执行攻击，包括重放攻击、注入攻击以及权限提升攻击等。

防范

•执行完整性检查，如：任何序列化对象的数字签名，以防止恶 意对象创建或数据篡改。
• 在创建对象之前强制执行严格的类型约束，因为代码通常被期 望成一组可定义的类。绕过这种技术的方法已经被证明，所以 完全依赖于它是不可取的。
• 如果可能，隔离运行那些在低特权环境中反序列化的代码。
• 记录反序列化的例外情况和失败信息，如：传入的类型不是预 期的类型，或者反序列处理引发的例外情况。
• 限制或监视来自于容器或服务器传入和传出的反序列化网络连 接。
• 监控反序列化，当用户持续进行反序列化时，对用户进行警告。

攻击案例场景

场景 #1：一个React应用程序调用了一组Spring Boot微服务。作 为功能性程序员，他们试图确保他们的代码是不可变的。他们提 出的解决方法是序列化用户状态，并在每次请求时来回传递。攻 击者注意到了“R00”Java对象签名，并使用Java Serial Killer工 具在应用服务器上获得远程代码执行。

场景 #2：一个PHP论坛使用PHP对象序列化来保存一个“超 级”cookie。该cookie包含了用户的用户ID、角色、密码哈希和其 他状态： a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} 攻击者更改序列化对象以授予自己为admin权限： a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

10.不足的日志记录和监控

不足的记录和监控漏洞，再加上事件响应能力欠缺以及缺少有效的整合，使得攻击者可以进一步攻击系统，维持其持久性，转而攻击更多的系统，并篡改、提取或销毁数据。大部分的数据泄露研究显示，检测出发生数据泄漏的时间通常需要超过200天，而且通常是外部机构率先发现数据泄漏的事实，而不是通过内部的审计流程或监控发现的。

防范

• 确保所有登录、访问控制失败、输入验证失败能够被记录到日 志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间。
• 确保日志以一种能被集中日志管理解决方案使用的形式生成
• 确保高额交易有完整性控制的审计信息，以防止篡改或删除， 例如审计信息保存在只能进行记录增加的数据库表中。
• 建立有效的监控和告警机制，使可疑活动在可接受的时间内被 发现和应对。
• 建立或采取一个应急响应机制和恢复计划，例如：NIST 800- 61 rev 2或更新版本。

攻击案例场景

场景#1：一个由小团队运营的开源项目论坛软件被攻击者利用其 内在漏洞攻陷了。 攻击者设法删除了包含下一个版本的内部源代 码仓库以及所有论坛内容。 虽然代码可以恢复，但由于缺乏监控、 日志记录和告警导致了更糟糕的结果。 由于此问题，该论坛软件 项目不再活跃。
场景#2：攻击者使用通用密码进行用户扫描并能获取所有使用此 密码的账户。对于其他账户而言，将仅有一次失败的登陆尝试记 录。一段时间以后，攻击者可以用另一个密码再次进行此活动。
场景#3：美国的一家大型零售商据内部使用恶意软件分析沙箱做 分析。 沙箱软件检测到了一些可能不需要的软件，但没有人响应 此次检测。 在一个境外银行不正当的信用卡交易被检测到之前， 该沙箱软件一直在产生告警信息。

参考：[OWASP TOP 10-2017][http://www.owasp.org.cn/owasp-project/OWASPTop102017v1.3.pdf]