常见的容器安全威胁都有哪些？
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了常见的容器安全威胁都有哪些？相关的知识，希望对你有一定的参考价值。
以Docker 容器的安全问题为例
(1) Docker 自身安全
Docker 作为一款容器引擎，本身也会存在一些安全漏洞，CVE 目前已经记录了多项与 Docker 相关的安全漏洞，主要有权限提升、信息泄露等几类安全问题。
(2) 镜像安全
由于Docker 容器是基于镜像创建并启动，因此镜像的安全直接影响到容器的安全。具体影响镜像安全的总结如下。
镜像软件存在安全漏洞：由于容器需要安装基础的软件包，如果软件包存在漏洞，则可能会被不法分子利用并且侵入容器，影响其他容器或主机安全。
仓库漏洞：无论是Docker 官方的镜像仓库还是我们私有的镜像仓库，都有可能被攻击，然后篡改镜像，当我们使用镜像时，就可能成为攻击者的目标对象。
用户程序漏洞：用户自己构建的软件包可能存在漏洞或者被植入恶意脚本，这样会导致运行时提权影响其他容器或主机安全。
(3) Linux 内核隔离性不够
尽管目前Namespace 已经提供了非常多的资源隔离类型，但是仍有部分关键内容没有被完全隔离，其中包括一些系统的关键性目录（如 /sys、/proc 等），这些关键性的目录可能会泄露主机上一些关键性的信息，让攻击者利用这些信息对整个主机甚至云计算中心发起攻击。
而且仅仅依靠Namespace 的隔离是远远不够的，因为一旦内核的 Namespace 被突破，使用者就有可能直接提权获取到主机的超级权限，从而影响主机安全。
(4) 所有容器共享主机内核
由于同一宿主机上所有容器共享主机内核，所以攻击者可以利用一些特殊手段导致内核崩溃，进而导致主机宕机影响主机上其他服务。
既然容器有这么多安全上的问题，那么我们应该如何做才能够既享受到容器的便利性同时也可以保障容器安全呢？下面我带你来逐步了解下如何解决容器的安全问题。
如何解决容器的安全问题？
(1) Docker 自身安全性改进
事实上，Docker 从 2013 年诞生到现在，在安全性上面已经做了非常多的努力。目前 Docker 在默认配置和默认行为下是足够安全的。
Docker 自身是基于 Linux 的多种 Namespace 实现的，其中有一个很重要的 Namespace 叫作 User Namespace，User Namespace 主要是用来做容器内用户和主机的用户隔离的。在过去容器里的 root 用户就是主机上的 root 用户，如果容器受到攻击，或者容器本身含有恶意程序，在容器内就可以直接获取到主机 root 权限。Docker 从 1.10 版本开始，使用 User Namespace 做用户隔离，实现了容器中的 root 用户映射到主机上的非 root 用户，从而大大减轻了容器被突破的风险。
因此，我们尽可能地使用Docker 最新版本就可以得到更好的安全保障。
(2) 保障镜像安全
为保障镜像安全，我们可以在私有镜像仓库安装镜像安全扫描组件，对上传的镜像进行检查，通过与CVE 数据库对比，一旦发现有漏洞的镜像及时通知用户或阻止非安全镜像继续构建和分发。同时为了确保我们使用的镜像足够安全，在拉取镜像时，要确保只从受信任的镜像仓库拉取，并且与镜像仓库通信一定要使用 HTTPS 协议。
(3) 加强内核安全和管理
由于仅仅依赖内核的隔离可能会引发安全问题，因此我们对于内核的安全应该更加重视。可以从以下几个方面进行加强。
宿主机及时升级内核漏洞
宿主机内核应该尽量安装最新补丁，因为更新的内核补丁往往有着更好的安全性和稳定性。
使用Capabilities 划分权限
Capabilities 是 Linux 内核的概念，Linux 将系统权限分为了多个 Capabilities，它们都可以单独地开启或关闭，Capabilities 实现了系统更细粒度的访问控制。
容器和虚拟机在权限控制上还是有一些区别的，在虚拟机内我们可以赋予用户所有的权限，例如设置cron 定时任务、操作内核模块、配置网络等权限。而容器则需要针对每一项 Capabilities 更细粒度的去控制权限，例如：
cron 定时任务可以在容器内运行，设置定时任务的权限也仅限于容器内部；
由于容器是共享主机内核的，因此在容器内部一般不允许直接操作主机内核；
容器的网络管理在容器外部，这就意味着一般情况下，我们在容器内部是不需要执行ifconfig、route等命令的 。
由于容器可以按照需求逐项添加Capabilities 权限，因此在大多数情况下，容器并不需要主机的 root 权限，Docker 默认情况下也是不开启额外特权的。
最后，在执行docker run命令启动容器时，如非特殊可控情况，–privileged 参数不允许设置为 true，其他特殊权限可以使用 --cap-add 参数，根据使用场景适当添加相应的权限。
使用安全加固组件
Linux 的 SELinux、AppArmor、GRSecurity 组件都是 Docker 官方推荐的安全加固组件。下面我对这三个组件做简单介绍。
SELinux (Secure Enhanced Linux): 是 Linux 的一个内核安全模块，提供了安全访问的策略机制，通过设置 SELinux 策略可以实现某些进程允许访问某些文件。
AppArmor: 类似于 SELinux，也是一个 Linux 的内核安全模块，普通的访问控制仅能控制到用户的访问权限，而 AppArmor 可以控制到用户程序的访问权限。
GRSecurity: 是一个对内核的安全扩展，可通过智能访问控制，提供内存破坏防御，文件系统增强等多种防御形式。
这三个组件可以限制一个容器对主机的内核或其他资源的访问控制。目前，容器报告的一些安全漏洞中，很多都是通过对内核进行加强访问和隔离来实现的。
资源限制
在生产环境中，建议每个容器都添加相应的资源限制。下面给出一些执行docker run命令启动容器时可以传递的资源限制参数：
1 --cpus 限制 CPU 配额
2 -m, --memory 限制内存配额
3 --pids-limit 限制容器的 PID 个数
例如我想要启动一个1 核 2G 的容器，并且限制在容器内最多只能创建 1000 个 PID，启动命令如下：
1 $ docker run -it --cpus=1 -m=2048m --pids-limit=1000 busybox sh
推荐在生产环境中限制CPU、内存、PID 等资源，这样即便应用程序有漏洞，也不会导致主机的资源完全耗尽，最大限度降低安全风险。
(4) 使用安全容器
容器有着轻便快速启动的优点，虚拟机有着安全隔离的优点，有没有一种技术可以兼顾两者的优点，做到既轻量又安全呢？
答案是有，那就是安全容器。安全容器是相较于普通容器的，安全容器与普通容器的主要区别在于，安全容器中的每个容器都运行在一个单独的微型虚拟机中，拥有独立的操作系统和内核，并且有虚拟化层的安全隔离。
安全容器目前推荐的技术方案是Kata Containers，Kata Container 并不包含一个完整的操作系统，只有一个精简版的 Guest Kernel 运行着容器本身的应用，并且通过减少不必要的内存，尽量共享可以共享的内存来进一步减少内存的开销。另外，Kata Container 实现了 OCI 规范，可以直接使用 Docker 的镜像启动 Kata 容器，具有开销更小、秒级启动、安全隔离等许多优点。
参考技术A网络安全威胁
相比传统的云平台，容器云平台在网络方面一般会有比较大的差异，伴随着这些差异的引入，也引入了一些网络方面的安全问题。比如因为网络隔离模型的变化、资源共享方式的变化而出现的新的安全隐患，针对这两点变化我们分别看下他们带来的安全问题。
1. 网络模型
容器云平台中网络隔离大多使用逻辑隔离代替物理隔离。
物理隔离一般不会直接或者间接的连接公共网络，企业采用物理隔离网络一般是为了保护自己的各种各样的硬件设备和通信链路不被攻击，常见的攻击来自自然灾害、人为破坏等，被保护的硬件实体设备常见的有企业的路由器、工作站和其他的各种网络服务器等。从实际情况来看，一般只有使用了内网和公共网进行的物理隔离才能真正保证内部信息网络不被来自外界的攻击影响，比如来自黑客的攻击。
网络的逻辑隔离一般需要借助逻辑隔离设备来实现，从名称即可看出逻辑隔离器是不同网络间的一种中间件，用于连接不同的网络，常见的网络逻辑设备主要有防火墙、网关等。需要注意的是被隔离的网络之间仍然有物理的数据链路进行联通，被联通的两个网络之间不能直接的进行数据交换。
相比逻辑隔离物理隔离的安全性更高，企业网络多采用物理隔离代替逻辑隔离，以此来保证不同级别的组织或者部门的信息安全。容器云平台网络上采用逻辑隔离，来隔离不同的租户或者项目，一定程度上增加了云平台在网络方面的安全隐患。
2. 资源共享
容器云在网络方面的安全问题，除了上面我们讲到的网络逻辑隔离引入的问题，还有资源共享方面的问题。和传统的云平台一样，容器云平台一般也会有多租户的需求(公有云肯定会有多租户的存在，即使是私有云一般也会有多租户的需求，比如不同的子公司、同公司不同的部门一般都会有多个租户的需求)。
相比传统的云平台，容器云的多租户资源共享引入了更多的风险，在容器云中多个租户共享计算资源，很可能会因为隔离措施不当导致不同租户的逻辑网络被意外打通(国内某知名云厂商曾经发生过类似的问题)，导致用户的资源被其他的用户意外的访问到，这种情况下用户可能会被其他的用户恶意攻击，导致数据泄露等严重的问题。容器云平台中通常借助网络防火墙/IPS来进行虚拟化，这种方式也是很常用的方式但是进入云平台之后，尤其是在用户众多的公有云场景中，网络防火墙这种虚拟化方式就不会暴露出虚拟化能力不足的问题，这个问题会导致已经建立的静态网络分区与隔离模型不能满足容器云中动态资源的共享需求。
主机安全威胁
容器云平台目前基本以Docker 容器和kubernetes 容器编排(kubernetes为主流，当然也有支持多种编排工具的厂商)。了解Docker 的同学应该都知道Docker 容器是通过命名空间(namespace)的方式将文件系统、进程、各种设备、网络等资源进行了隔离。除了对资源的隔离，Docker容器还对容器具有的权限进行了限制，对CPU、内存等资源的使用也进行了相应的限制。对Docker 容器资源的限制、隔离的目的是为了让容器之间互不影响。
容器与容器所在的宿主机共享内核、文件系统、各种硬件等资源。容器可以部署在物理机上，也可以选择部署在虚拟主机上。
由于Docker 容器与宿主机共享内核、文件系统等资源，Docker 本身的隔离性不如虚拟机主机完善，因此如果Docker 自身出现漏洞，可能会波及问题Docker 容器所在的宿主机，由于Docker 容器所在的宿主机上可能存在当前租户的其他容器，也可能存在其他租户的容器，所以问题最终可能会影响到其他的容器，并可能会破坏容器云平台上的宿主机。
常见的漏洞类型都有哪些
一、SQL 注入漏洞
SQL 注入攻击（ SQL Injection ），简称注入攻击、SQL 注入，被广泛用于非法获取网站控制权， 是发生在应用程序的数据库层上的安全漏洞。在设计程序，忽略了对输入字符串中夹带的SQL 指令的检查，被数据库误认为是正常的SQL 指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。
通常情况下， SQL 注入的位置包括：
（1）表单提交，主要是POST 请求，也包括GET 请求；
（2）URL 参数提交，主要为GET 请求参数；
（3）Cookie 参数提交；
（4）HTTP 请求头部的一些可修改的值，比如Referer 、User_Agent 等；
（5）一些边缘的输入点，比如.mp3 文件的一些文件信息等。
SQL 注入的危害不仅体现在数据库层面上， 还有可能危及承载数据库的操作系统；如果SQL 注入被用来挂马，还可能用来传播恶意软件等，这些危害包括但不局限于：
（1）数据库信息泄漏：数据库中存放的用户的隐私信息的泄露。作为数据的存储中心，数据库里往往保存着各类的隐私信息， SQL 注入攻击能导致这些隐私信息透明于攻击者。
（2）网页篡改：通过操作数据库对特定网页进行篡改。
（3）网站被挂马，传播恶意软件：修改数据库一些字段的值，嵌入网马链接，进行挂马攻击。
（4）数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员帐户被篡改。
（5）服务器被远程控制，被安装后门。经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统。
（6）破坏硬盘数据，瘫痪全系统。
解决SQL 注入问题的关键是对所有可能来自用户输入的数据进行严格的检查、对数据库配置使用最小权限原则。通常使用的方案有：
（1 ）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL 语句中。当前几乎所有的数据库系统都提供了参数化SQL 语句执行接口，使用此接口可以非常有效的防止SQL 注入攻击。
（2 ）对进入数据库的特殊字符（ '"\\<>&*; 等）进行转义处理，或编码转换。
（3 ）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int 型。
（4）数据长度应该严格规定，能在一定程度上防止比较长的SQL 注入语句无法正确执行。
（5）网站每个数据层的编码统一，建议全部使用UTF-8 编码，上下层编码不一致有可能导致一些过滤模型被绕过。
（6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
（7）避免网站显示SQL 错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
（8）在网站发布之前建议使用一些专业的SQL 注入检测工具进行检测，及时修补这些SQL 注入漏洞。
二、跨站脚本漏洞
跨站脚本攻击（ Cross-site scripting ，通常简称为XSS）发生在客户端，可被用于进行窃取隐私、钓鱼欺骗、窃取密码、传播恶意代码等攻击。XSS 攻击使用到的技术主要为HTML 和Javascript ，也包括VBScript和ActionScript 等。XSS 攻击对WEB 服务器虽无直接危害，但是它借助网站进行传播，使网站的使用用户受到攻击，导致网站用户帐号被窃取，从而对网站也产生了较严重的危害。
XSS 类型包括：
（1）非持久型跨站： 即反射型跨站脚本漏洞， 是目前最普遍的跨站类型。跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码不存储到服务端（比如数据库中）。上面章节所举的例子就是这类情况。
（2）持久型跨站：这是危害最直接的跨站类型，跨站代码存储于服务端（比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的Javascript 代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript 代码。
（3）DOM 跨站（DOM XSS ）：是一种发生在客户端DOM （Document Object Model 文档对象模型）中的跨站漏洞，很大原因是因为客户端脚本处理逻辑导致的安全问题。
XSS 的危害包括：
（1）钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，或者注入钓鱼JavaScript 以监控目标网站的表单输入，甚至发起基于DHTML 更高级的钓鱼攻击方式。
（2 ）网站挂马：跨站时利用IFrame 嵌入隐藏的恶意网站或者将被攻击者定向到恶意网站上，或者弹出恶意网站窗口等方式都可以进行挂马攻击。
（3）身份盗用： Cookie 是用户对于特定网站的身份验证标志， XSS 可以盗取到用户的Cookie ，从而利用该Cookie 盗取用户对该网站的操作权限。如果一个网站管理员用户Cookie 被窃取，将会对网站引发巨大的危害。
（4）盗取网站用户信息：当能够窃取到用户Cookie 从而获取到用户身份使，攻击者可以获取到用户对网站的操作权限，从而查看用户隐私信息。
（5）垃圾信息发送：比如在SNS 社区中，利用XSS 漏洞借用被攻击者的身份发送大量的垃圾信息给特定的目标群。
（6）劫持用户Web 行为：一些高级的XSS 攻击甚至可以劫持用户的Web 行为，监视用户的浏览历史，发送与接收的数据等等。
（7）XSS 蠕虫：XSS 蠕虫可以用来打广告、刷流量、挂马、恶作剧、破坏网上数据、实施DDoS 攻击等。
常用的防止XSS 技术包括：
（1）与SQL 注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script 、iframe 等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP 请求中的Cookie 中的变量， HTTP 请求头部中的变量等。
（2 ）不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
（3）不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
（ 4）对输出的数据也要检查， 数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
（5）在发布应用程序之前测试所有已知的威胁。
三、弱口令漏洞
弱口令(weak password) 没有严格和准确的定义，通常认为容易被别人（他们有可能对你很了解）猜测到或被破解工具破解的口令均为弱口令。设置密码通常遵循以下原则：
（1）不使用空口令或系统缺省的口令，这些口令众所周之，为典型的弱口令。
（2）口令长度不小于8 个字符。
（3）口令不应该为连续的某个字符（例如： AAAAAAAA ）或重复某些字符的组合（例如： tzf.tzf. ）。
（4）口令应该为以下四类字符的组合，大写字母(A-Z) 、小写字母(a-z) 、数字(0-9) 和特殊字符。每类字符至少包含一个。如果某类字符只包含一个，那么该字符不应为首字符或尾字符。
（5）口令中不应包含本人、父母、子女和配偶的姓名和出生日期、纪念日期、登录名、E-mail 地址等等与本人有关的信息，以及字典中的单词。
（6）口令不应该为用数字或符号代替某些字母的单词。
（7）口令应该易记且可以快速输入，防止他人从你身后很容易看到你的输入。
（8）至少90 天内更换一次口令，防止未被发现的入侵者继续使用该口令。
四、HTTP 报头追踪漏洞
HTTP/1.1 （RFC2616 ）规范定义了HTTP TRACE 方法，主要是用于客户端通过向Web 服务器提交TRACE 请求来进行测试或获得诊断信息。当Web 服务器启用TRACE 时，提交的请求头会在服务器响应的内容（Body ）中完整的返回，其中HTTP 头很可能包括Session Token 、Cookies 或其它认证信息。攻击者可以利用此漏洞来欺骗合法用户并得到他们的私人信息。该漏洞往往与其它方式配合来进行有效攻击，由于HTTP TRACE 请求可以通过客户浏览器脚本发起（如XMLHttpRequest ），并可以通过DOM 接口来访问，因此很容易被攻击者利用。防御HTTP 报头追踪漏洞的方法通常禁用HTTP TRACE 方法。
五、Struts2 远程命令执行漏洞
Apache Struts 是一款建立Java web 应用程序的开放源代码架构。Apache Struts 存在一个输入过滤错误，如果遇到转换错误可被利用注入和执行任意Java 代码。网站存在远程代码执行漏洞的大部分原因是由于网站采用了Apache Struts Xwork 作为网站应用框架，由于该软件存在远程代码执高危漏洞，导致网站面临安全风险。CNVD 处置过诸多此类漏洞，例如：“ GPS 车载卫星定位系统”网站存在远程命令执行漏洞(CNVD-2012-13934) ；Aspcms 留言本远程代码执行漏洞（ CNVD-2012-11590 ）等。
修复此类漏洞，只需到Apache 官网升级Apache Struts 到最新版本
六、框架钓鱼漏洞（框架注入漏洞）
框架注入攻击是针对Internet Explorer 5 、Internet Explorer 6 、与Internet Explorer 7 攻击的一种。这种攻击导致Internet Explorer 不检查结果框架的目的网站，因而允许任意代码像Javascript 或者VBScript 跨框架存取。这种攻击也发生在代码透过多框架注入，肇因于脚本并不确认来自多框架的输入。这种其他形式的框架注入会影响所有的不确认不受信任输入的各厂商浏览器和脚本。如果应用程序不要求不同的框架互相通信，就可以通过完全删除框架名称、使用匿名框架防止框架注入。但是，因为应用程序通常都要求框架之间相互通信，因此这种方法并不可行。因此，通常使用命名框架，但在每个会话中使用不同的框架，并且使用无法预测的名称。一种可行的方法是在每个基本的框架名称后附加用户的会话令牌，如main_display 。
七、文件上传漏洞
文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过Web 访问的目录上传任意文件，包括网站后门文件（ webshell ），进而远程控制网站服务器。因此，在开发网站及应用程序过程中，需严格限制和校验上传的文件，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell 攻击。
八、应用程序测试脚本泄露
由于测试脚本对提交的参数数据缺少充分过滤，远程攻击者可以利用洞以WEB 进程权限在系统上查看任意文件内容。防御此类漏洞通常需严格过滤提交的数据，有效检测攻击。
九、私有IP 地址泄露漏洞
IP 地址是网络用户的重要标示，是攻击者进行攻击前需要了解的。获取的方法较多，攻击者也会因不同的网络情况采取不同的方法，如：在局域网内使用Ping 指令， Ping 对方在网络中的名称而获得IP；在Internet 上使用IP 版的QQ直接显示。最有效的办法是截获并分析对方的网络数据包。攻击者可以找到并直接通过软件解析截获后的数据包的IP 包头信息，再根据这些信息了解具体的IP。针对最有效的“数据包分析方法”而言，就可以安装能够自动去掉发送数据包包头IP 信息的一些软件。不过使用这些软件有些缺点， 譬如：耗费资源严重，降低计算机性能；访问一些论坛或者网站时会受影响；不适合网吧用户使用等等。现在的个人用户采用最普及隐藏IP 的方法应该是使用代理，由于使用代理服务器后，“转址服务”会对发送出去的数据包有所修改，致使“数据包分析”的方法失效。一些容易泄漏用户IP 的网络软件(QQ 、MSN 、IE 等)都支持使用代理方式连接Internet ，特别是QQ 使用“ ezProxy ”等代理软件连接后， IP 版的QQ 都无法显示该IP 地址。虽然代理可以有效地隐藏用户IP，但攻击者亦可以绕过代理， 查找到对方的真实IP 地址，用户在何种情况下使用何种方法隐藏IP，也要因情况而论。
十、未加密登录请求
由于Web 配置不安全， 登陆请求把诸如用户名和密码等敏感字段未加密进行传输， 攻击者可以窃听网络以劫获这些敏感信息。建议进行例如SSH 等的加密后再传输。
十一、敏感信息泄露漏洞
SQL 注入、XSS、目录遍历、弱口令等均可导致敏感信息泄露，攻击者可以通过漏洞获得敏感信息。针对不同成因，防御方式不同。
参考技术A 第一：注入漏洞由于其普遍性和严重性，注入漏洞位居漏洞排名第一位。常见的注入漏洞包括SQL、LDAP、OS命令、ORM和OGML。用户可以通过任何输入点输入构建的恶意代码，如果应用程序没有严格过滤用户的输入，一旦输入的恶意代码作为命令或者查询的一部分被发送到解析器，就可能导致注入漏洞。
第二：跨站脚本漏洞
XSS漏洞的全称是跨站点脚本漏洞。XSS漏洞是网络应用程序中常见的安全漏洞，它允许用户将恶意代码植入网页，当其他用户访问此页面时，植入的恶意脚本将在其他用户的客户端执行。危害有很多，客户端用户的信息可以通过XSS漏洞获取，比如用户登录的Cookie信息;信息可以通过XSS蜗牛传播;木马可以植入客户端;可以结合其他漏洞攻击服务器，并在服务器中植入特洛伊木马。
第三、文件上传漏洞
造成文件上传漏洞的主要原因是应用程序中有上传功能，但上传的文件没有通过严格的合法性检查或者检查功能有缺陷，导致木马文件上传到服务器。文件上传漏洞危害极大，因为恶意代码可以直接上传到服务器，可能造成服务器网页修改、网站暂停、服务器远程控制、后门安装等严重后果。
第四、文件包含漏洞
文件包含漏洞中包含的文件参数没有过滤或严格定义，参数可以由用户控制，可能包含意外文件。如果文件中存在恶意代码，无论文件是什么后缀类型，文件中的恶意代码都会被解析执行，导致文件包含漏洞。
第五、命令执行漏洞
应用程序的某些函数需要调用可以执行系统命令的函数。如果这些功能或者功能的参数可以被用户控制，那么恶意的命令就有可能通过命令连接器拼接成正常的功能，从而可以随意执行系统命令。这就是命令执行漏洞，属于高风险漏洞之一。
以上是关于常见的容器安全威胁都有哪些？的主要内容，如果未能解决你的问题，请参考以下文章