保护应用程序（ ap p ）的安全是安全专家的一项重要任务，但许多专家们正感到这场战斗即将失败。在 F5 实验室的首份年度综合《应用程序保护报告》中，我们提供了一个应用程序复杂性的实践模型，并探索了应用程序是如何遭到攻击的，以及提供了用于赢得这场战斗的实践措施。
执行摘要就像充满了多彩生命的珊瑚礁一样， Web 应用程序是一种“群落生物”。它们由多个独立的组件组成，在具有不同要求的独立环境中运行并且支持跨网络的基础设施（云或传统的基础设施）。在本报告中，我们重点关注了不同的交互层 应用服务、应用访问、传输层服务（ TLS ）、域名服务（ DNS ）还有网络 每一个都可能成为潜在的攻击目标。
为了客观地了解应用程序是如何遭到攻击的， F5 实验室综合审视了不同来源的数据，包括 F5 的内部数据集、 WhiteHat Security （白帽安全）的漏洞数据、 Loryka 的攻击数据以及 F5 委托 Ponemon 对 IT 专家进行的一项安全调查。
此外，我们还与沃特康姆社区大学网络安全中心的教员进行合作，对加利福尼亚州、华盛顿州、爱达荷州和俄勒冈州的数据泄露通知进行了广泛的审查。（在美国的每一个州，都是由州检察长办公室负责监督并执行本州的数据泄露披露法律。由于这一角色的存在，某些州还会公开发布数据泄露通知函。）
在这四个州中，通过分析 2017 年及 2018 年 Q1 的 301 个数据泄露事件，我们发现针对 Web 应用的攻击是造成数据泄露的首要原因，占 30% 。在 F5 实验室之前对横跨 12 年和 26 个国家的 433 个主要数据泄露事件的分析中，我们发现应用程序是 53% 的数据泄露事件的初始攻击目标。
应用程序保护一直以来都是一个关键任务，将来也是继续如此。
那么，哪些相关内容是 CISO 现在需要了解的呢？
应用程序各层分布图
第1个问题：我们使用了哪些App？它们在哪儿呢？F5 及 Ponemon 的调查《全球调研：不断变化的风险环境中的 Web 应用安全》发现，大多数企业对它们跟踪自己的所有 App 的能力缺乏信心。 38% 的受访者表示他们对是否了解企业的全部应用程序的位置 “ 没有信心 ” 。然而，与此同时受访者还表示他们的 34% 的 Web 应用是与关键任务有关的。最常见的 Web 应用是备份和存储应用（ 83% ）、电子邮件等通信应用（ 71% ）、文件管理和协调应用（ 66% ）以及微软 Office 套件中的应用（ 65% ）。
第2个问题：针对App的攻击将如何影响我的企业？App 遭到攻击可能会带来多种不同的影响。后果最为严重的一种是拒绝服务，如果将造成的后果的严重性分为 1 到 10 分（ 10 分为最高）的话， 81% 的受访者将 DoS 造成的损失评为 7 到 10 分。敏感或机密信息的泄露（例如知识产权，还有商业交易秘密）排在第二位， 77% 的受访者将其评为 7 到 10 分。同样， 73% 的受访者将应用程序篡改评为 7 到 10 分。最后， 64% 的受访者将个人身份信息（ PII ）泄露评为 7 到 10 分（可能是客户、消费者或是员工的 PII ）。
DOS 攻击的严重性评分
应用程序攻击的威胁种类地图
第3个问题：存在哪些重大风险？根据各州检察长办公室在 2017 年和 2018 年第一季度发布的数据泄露通知，我们对这些网络攻击进行了仔细的研究。与应用程序有关的泄露事件主要包括 web 注入（ 70% ）、 web 入侵（ 26% ）以及 App 数据库入侵（ 4% ）导致的信用卡信息窃取。我们将之与白帽安全的相关漏洞信息、 Loryka 的攻击监测信息以及 Exploit-DB （一个符合 CVE 标准的公共漏洞及 exploit 库）公布的已知 exploit 进行交叉对比，以了解当前最重大的风险：
针对 App 服务的注入攻击在 2018 年第一季度的数据泄露报告中，占比最高的类别（ 70% ）是试图窃取用户信用卡信息的 web 注入攻击。注入攻击允许攻击者将命令或新的代码直接插入正在运行的应用程序中，以实施其恶意行为（也被称为 App 篡改攻击）。在过去十年中，最臭名昭著的注入攻击是 SQL 注入，占所有数据泄露通知的 23% 。注入漏洞（尚未被利用的漏洞）也很常见。白帽安全报告称 2017 年发现的所有漏洞中有 17% 是注入漏洞。这个问题是如此的严重，以至于 2017 OWASP Top 10 将注入漏洞评为应用程序风险的第一名。由于这个原因，企业应该将寻找、修复和封禁注入漏洞当作高优先级事项来处理。
账户访问劫持分析表明 2017 年和 2018 年第一季度所有的 web app 数据泄露事件中有 13% 与访问劫持有关。细分如下：电子邮件导致的凭据窃取（ 34.29% ）、配置错误的访问控制（ 22.86% ）、暴力密码破解攻击（ 5.71% ）、撞库攻击（ 8.57% ）以及社交工程攻击（ 2.76% ）。同样， Exploit-DB 中将近 25% 的 web app 脚本与访问劫持有关。 F5 与 Ponemon 的调查还表明 75% 的受访者在关键 web 应用中只采用了用户名 + 密码的身份验证方式。
对于重要的应用，强烈建议使用联合验证或多因素验证等强身份验证方案。对于不具有完整控制权限的外部应用，可以采用云安全访问代理（ CASB ）来整合和加固身份验证解决方案。
常见的攻击路径
针对 App 服务的反序列化攻击2017 年，反序列化攻击的数量有所减少，但影响范围变大了。攻击者在入侵 Equifax 窃取 1.48 亿美国公民和 1520 万英国公民的数据时利用的就是 Apache Struts 中的反序列化漏洞。序列化是指 App 将数据转变为传输格式；反序列化则是将数据再转换回来。这种攻击变得越来越普遍是因为应用程序现在都是联网的子系统集群，需要进行序列化的数据通信。攻击者通过在序列化的数据流中植入命令，可以直接将未过滤的恶意代码送入应用程序引擎的心脏。 Exploit-DB 中 30% 的脚本与反序列化漏洞有关。
为了阻止此类攻击，应用程序应该对所有的用户输入进行扫描和过滤，包括序列化的数据流。
针对传输层的攻击虽然 63 ％的受访者表示他们总是将 SSL / TLS 用于他们的 web app 中，但只有 46 ％的受访者表示他们在自己的大多数（ 76-100 ％） app 中使用了 SSL / TLS 加密。尽管许多传输层加密标准已经 “ 退役 ” ，例如 SSL 和 TLS 1.0 ，但它们仍被大量使用，这带来了许多信息窃取或中间人攻击的风险。此外， 47% 的企业称它们使用自签名的证书，这更加减少了其 app 的可信程度。
DDoS 攻击贯穿在应用程序的所有层中，因此企业拥有 DDoS 响应策略至关重要。
针对客户端的脚本攻击（访问劫持）
针对 App 客户端的攻击报告常常较少，因为受到攻击的个人往往并不喜欢被公开的报告提及，而且不同于应用程序泄露事件，在这一方面并没有报告的监管要求。常见的客户端劫持攻击是 XSS 攻击， XSS 是最流行的漏洞之一（根据白帽安全， XSS 占 2017 年所有漏洞的 30% ；并且占 Exploit-DB 脚本的 9.24% ）。 XSS 攻击可能导致用户凭据窃取或访问劫持。另一种常见的客户端劫持攻击是跨站请求伪造（ CSRF ）。这两种攻击都涉及到攻击者在网站上植入恶意脚本代码并最终在 app 客户端上执行的场景。
有一些 web 服务器选项可以帮助减少此类脚本攻击，例如将会话 cookie 设置为 HTTP-only 以及限制域，以及将 X-frame-options 设置成 DENY 。
针对客户端的恶意软件攻击客户端也会直接受到恶意软件的攻击，这些恶意软件可能劫持浏览器以嗅探或拦截应用程序的身份验证凭据。对浏览器和手机客户端而言，针对银行账户登录凭据的恶意软件非常常见。虽然当前对客户端设备的保护很大程度上被忽略了（因为它很难控制），但更加严格的隐私数据保护法案，例如欧盟的 GDPR ，很有可能会对安全性较差的 app 客户端进行惩罚。
某些 Web 应用防火墙可以监测可疑连接、检测受感染的客户端并过滤其访问。
第4个问题：我是否已采取了足够的App保护措施？我怎么与其它人（企业）进行对比呢？F5 与 Ponemon 的调查研究提供了一些关于其它企业是如何对待应用程序的安全性的见解。第一个问题是，负责人应该是谁？ 28% 的受访者表示 CIO 或者 CTO 应该负责应用程序的安全风险管理流程。尽管当数据泄露事件发生时， CISO 往往是那个担责的，但只有 10% 的 CISO 是这一领域的负责人。
实现强应用程序安全性的前三大阻碍分别是：应用程序各层缺乏可见性、缺乏技术人员和专家以及迁移至云环境。第一个问题和第三个问题都与应用程序各层的分析与检测有关，这些都是可解决的问题，但需要与开发团队共同进行扫描、监测和协作。
Web 应用防火墙是应用程序安全解决方案的首选措施（ 26% ）；其次是应用程序扫描（ 20% ）和渗透测试（ 20% ）。令人意外的是， 26% 的企业没有部署应用程序加固流程，虽然这是一种加强应用程序安全性的有效措施。
保护应用程序的四个步骤虽然这些发现看似描绘了一幅暗淡无光的画面，但以下四个步骤将大大有助于增强您的应用程序安全性。最重要的是，这些步骤都很简单。
1. 了解你的环境
了解你拥有的应用程序以及它们可以访问哪些数据库。是的，这不容易，但这是必要的。重点关注企业所需的 app 以及客户依赖的 app 。对于企业所需的 app ，定期对其进行扫描和清点。对于用户依赖的外部 app ，采用云访问安全代理（ CASB ）将有助于统计和跟踪该 app 的使用情况。对于内部 app ，一定要与开发团队保持良好的关系，以便于跟踪 app 的下一步开发计划、部署环境等。
2. 减少攻击面任何直接或非直接暴露在互联网上的应用服务都可能被攻击者所利用。考虑到 app 的层级之多以及 API 接口的越来越多的使用，这个攻击面还是非常大的。所有暴露的部件都应该进行访问控制，并且定期打补丁和加固。一个好的 Web 应用防火墙（ WAF ） 我们的调查中排名第一的安全工具 可以给你带来充足的实施这些措施的时间。某些 WAF 产品还带有“虚拟补丁”功能，可以扫描应用程序的流量并阻止那些已知的 exploit 攻击。它们通过威胁情报源和企业环境漏洞扫描的自动签名更新来获知应该阻止哪些内容。这可以为新 exploit 发布时尽快进行修补减轻时间压力，同时为运营团队提供了测试和推出修复补丁的时间。由于许多安全团队未在其 WAF 上启用必要的安全屏蔽功能，很多安全事件原本是可预防的。您还应该对应用程序进行隔离和分区，以免在较低优先级的应用程序被入侵时，攻击者能够以之为跳板访问更高优先级的系统。这些可以在代码中完成，包括服务器隔离、沙盒、低权限用户甚至防火墙等。
3. 基于风险划分防护优先级
一旦你知道了哪些应用程序是重要的，并且最小化了你的攻击面，你需要找到需求额外资源的应用程序。你的风险分析策略并不一定要是完美的，但要比随机猜测或有偏见的决策要好。所以，可以使用数据来驱动你的风险策略，弄清楚攻击者的目的所在。从安全测试和扫描获取应用程序的关键数据。对内部开发的代码通过内部扫描器、代码审计或第三方（它们可以提供更专业的第三者角度）进行测试。有了这些信息，你就可以正确地评估任何内部开发的应用程序的风险。
4. 选择弹性和集成的防护工具你需要选择一个好用且好管理的解决方案，这个解决方案要兼具弹性和强力，涵盖众多现有威胁及新兴威胁的防护、检测和恢复功能。除了我们已经提到的技术控制之外 Web 应用防火墙、漏扫解决方案和 CASB 应该对应用程序依赖的所有层都进行防护。 DNS 服务器应该用专用的 DNS 防火墙进行防护，并保证其高可用性。传输层通信应该使用兼容现行标准的加密器进行加密， web 服务器应该使用 HTTP 严格传输安全（ HSTS ）来对所有的关键数据流进行加密。安全解决方案应该保持一致性，并且被安全工程师所充分熟悉和使用。许多入侵事件的发生就是因为安全解决方案的错误配置或错误理解所导致的。
基于 DDoS 的潜在危害性，通过本地防护设备或托管解决方案在网络层、应用层以及基础设施层保护您的应用程序至关重要。此外还应该根据应用程序面临的风险和可能的威胁来对安全解决方案进行定制。
在客户端保护方面，请记住您有两类用户：普通客户以及内部用户。要保护内部用户，可以考虑使用联合身份验证或多因素身份验证（ MFA ）。对于只支持用户名和密码验证方式的应用程序（这些用户面临着密码猜测攻击和凭据窃取攻击）， CASB 可以帮助加固外部 app 的身份验证。对于高价值的应用程序，保护客户端的会话也很重要。某些兼具强力和弹性的 WAF 系统可以帮助您保护 app 的客户端会话，包括检测机器人攻击、暴力破解攻击以及来自可疑位置的登录等。这种简单的验证可以为您的客户提供一层额外的防护。
第5个问题：应用程序保护的未来展望 无服务器应用无服务器应用是开发者构建 web 应用的一种新方式，这种方式不再需要考虑服务器，也不再需要考虑 app 的支撑设施。开发者编写的代码和脚本将连接到直接触发服务和功能的 API ，而不是传统的那种代码在服务器上运行，然后再访问其它服务器。无服务器计算使得开发者可以更加注重于快速、线型的 app 开发。从长远来看，无服务器应用在灵活性和可扩展性上更胜一筹。但需要注意的是，无服务器应用仍然与传统 app 一样易受相同类型的攻击，尤其是针对用户登录页面和 API 的攻击。
将应用程序安全进行外包在 F5 和 Ponemon 的安全调查中，缺乏技术人员和安全专家被认为是实施应用程序保护的主要阻碍之一。这一趋势可能会继续恶化。此外，由于每个企业平均使用了 765 个不同的 web 应用，我们预计应用程序安全的外包市场将会增长。这可能包括 DDoS 防护产品、 web 应用安全监测产品或是提供安全服务的托管平台。使用外包服务意味着一个将你的特定安全需求与外包商的能力、关注点以及经验进行匹配的过程。
TLS 协议的发展由于 TLS 1.3 与之前的版本有很大的不同，安全社区还在挣扎是否采用它。从长远来看，量子计算的幽灵同样影响着 TLS 。我们认为 TLS 还会遭到更多的冲击，但目前无从得知这些冲击来自何方。企业应该留意浏览器对 TLS 1.3 的支持，并关注网络加密的主要标准的变化和量子计算的发展。
应用程序保护的层级框架由于现代应用程序是脚本、库、服务和设备的大合集，我们希望安全工具能够赶上这种模式。在未来，开发人员将可以从广泛的安全组件和框架中进行选择，这些组件和框架与今天的脆弱、过度依赖生态系统的组件和框架截然不同。开发者将可以使用“默认安全”的应用程序框架进行开发，这些框架自带以标准格式报告安全状况和事件的功能。防御者将可以找到能够以安全但有效的方式对生产中的 app 组件进行连续测试的安全扫描器。
结论读完这些，你可能会觉得 web 应用的安全性令人生畏。也许确实如此 但仍有一些简单的方法可以用来开始。如果你的公司较小，并且还没有使用 web 应用防火墙（ WAF ），那么建议你从这里开始。请务必接受适当的培训以使用 WAF 的全部功能来保护你的应用。引用我们自己的一句话就是：“第一步可能很小，但重要的是，你踏出了第一步”。
本报告的目的是帮助您回答以下问题：“为了保护我的应用程序，我现在可以做的最重要的事情是什么？”我们通过假设问答的方式模拟了 CISO 在考虑应用程序安全性时可能遇到的问题。衷诚地希望这份报告可以帮助您填补应用程序安全策略中的空缺。
参考链接：2. https://www.exploit-db.com/about-exploit-db/
3. https://support.f5.com/csp/article/K07359270
