本文目录一览：
什么是K8S？
k8s是什么?
Kubernetes 是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。
为什么现在流行使用容器?
早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.
后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.
现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.
为什么需要使用k8s容器?
若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.
k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理
名词解释
secret
Secret有三种类型：
Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的目录中；
/run/secrets/kubernetes.io/serviceaccount
Opaque：base64编码格式的Secret，用来存储密码、密钥等；
kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。
k8s的组成
k8s是由组件,API,对象等组成.
包含所有相互关联组件的 Kubernetes 集群图如下:
组件
控制平面组件
kube-apiserver: 为k8s的api服务器,公开了所有Kubernetes API, 其他所有组件都必须通过它提供的API来操作资源数据.
保证集群状态访问的安全
隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。
etcd: 为k8s的键值数据库,保存了k8s所有集群数据的后台数据库。
kube-scheduler: 收集和分析当前Kubernetes集群中所有Node节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。 kube-controller-manager: 在主节点上运行 控制器 的组件。
cloud-controller-manager: 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件
Node 组件
kubelet: 一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。
kube-proxy: kube-proxy是集群中每个节点上运行的网络代理,维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
容器运行时: 负责运行容器的软件。
插件(Addons)
DNS: 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。
Web 界面（仪表盘）: Dashboard 是Kubernetes 集群的通用的、基于 Web 的用户界面。
容器资源监控: 容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
集群层面日志: 集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。
API
Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。
对象
Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态.
具体来说，他们可以描述：
容器化应用正在运行(以及在哪些节点上)
这些应用可用的资源
关于这些应用如何运行的策略，如重新策略，升级和容错
Kubernetes 架构
Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成.
master 流程图
Kubecfg将特定的请求，比如创建Pod，发送给Kubernetes Client。
Kubernetes Client将请求发送给API server。
API Server根据请求的类型，比如创建Pod时storage类型是pods，然后依此选择何种REST Storage API对请求作出处理。
REST Storage API对的请求作相应的处理。
将处理的结果存入高可用键值存储系统Etcd中。
在API Server响应Kubecfg的请求后，Scheduler会根据Kubernetes Client获取集群中运行Pod及Minion/Node信息。
依据从Kubernetes Client获取的信息，Scheduler将未分发的Pod分发到可用的Minion/Node节点上。
节点
节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务， 这些 Pods 由 控制面 负责管理.
节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。
节点状态
可以使用 kubectl 来查看节点状态和其他细节信息：
kubectl describe node �节点名称
一个节点包含以下信息:
地址
HostName：由节点的内核设置。可以通过 kubelet 的 —hostname-override 参数覆盖。
ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。
InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。
状况(conditions 字段描述了所有 Running 节点的状态)
Ready 如节点是健康的并已经准备好接收 Pod 则为 True；False 表示节点不健康而且不能接收 Pod；Unknown 表示节点控制器在最近 node-monitor-grace-period 期间（默认 40 秒）没有收到节点的消息
DiskPressure为True则表示节点的空闲空间不足以用于添加新 Pod, 否则为 False
MemoryPressure为True则表示节点存在内存压力，即节点内存可用量低，否则为 False
PIDPressure为True则表示节点存在进程压力，即节点上进程过多；否则为 False
NetworkUnavailable为True则表示节点网络配置不正确；否则为 False
容量与可分配描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。
信息关于节点的一般性信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。
控制面到节点通信
节点到控制面
apiserver在安全的 HTTPS 端口（443）上监听远程连接请求
以客户端证书的形式将客户端凭据提供给 kubelet
控制面到节点
API 服务器到 kubelet连接用于
获取 Pod 日志
挂接（通过 kubectl）到运行中的 Pod
提供 kubelet 的端口转发功能。
(注: 在连接状态下, 默认apiserver 不检查 kubelet 的服务证书。容易受到中间人攻击，不安全.)
apiserver 到节点、Pod 和服务
SSH 隧道(目前已经废弃)
产生原因: 若无服务证书, 又要求避免在非受信网络或公共网络上进行连接,则可以在apiserver 和 kubelet 之间使用ssh隧道.
Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。
Konnectivity 服务为ssh隧道的替代品, Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。
控制器
在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。
举个例子: 当前室内温度为20度, 我们通过调节遥控器,使其温度上升至24度, 这20度到24度的变化即为让其从当前状态接近期望状态。
控制器模式分为直接控制和通过API服务器来控制.
云控制器管理器
云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中， 并分离出相互作用的组件与您的集群交互的组件。
云控制器管理器中的控制器包括：
节点控制器
节点控制器负责在云基础设施中创建了新服务器时为之 创建 节点（Node）对象。 节点控制器从云提供商获取当前租户中主机的信息。
执行功能:
针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象
利用特定云平台的信息为 Node 对象添加注解和标签
获取节点的网络地址和主机名
检查节点的健康状况。
路由控制器Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的 容器之间可以相互通信。
服务控制器服务（Service）与受控的负载均衡器、 IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。
Kubernetes 安全性
云原生安全
云原生安全4个C: 云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)
云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。我们无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。
基础设施安全
Kubetnetes 基础架构关注领域
建议
通过网络访问 API 服务（控制平面)
所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。
通过网络访问 Node（节点)
节点应配置为 仅能 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。
Kubernetes 云访问提供商的 API
每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。
访问 etcd
对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 etcd 文档中找到。
etcd 加密
在所有可能的情况下，最好对所有驱动器进行静态数据加密，但是由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。
集群组件安全
运行的应用程序的安全性关注领域
访问控制授权(访问 Kubernetes API)
认证方式
应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密)
Pod 安全策略
服务质量（和集群资源管理）
网络策略
Kubernetes Ingress 的 TLS 支持
容器安全
容器安全性关注领域
容器搭建配置(配置不当,危险挂载, 特权用户)
容器服务自身缺陷
Linux内核漏洞
镜像签名和执行
代码安全
代码安全关注领域
仅通过 TLS 访问(流量加密)
限制通信端口范围
第三方依赖性安全
静态代码分析
动态探测攻击(黑盒)
Kubernetes架构常见问题
Kubernetes ATTACK 矩阵
信息泄露
云账号AK泄露
API凭证（即阿里云AccessKey）是用户访问内部资源最重要的身份凭证。用户调用API时的通信加密和身份认证会使用API凭证.
API凭证是云上用户调用云服务API、访问云上资源的唯一身份凭证。
API凭证相当于登录密码，用于程序方式调用云服务API.
k8s configfile泄露
kubeconfig文件所在的位置:
$HOME/.kube/config
Kubeconfig文件包含有关Kubernetes集群的详细信息，包括它们的位置和凭据。
云厂商会给用户提供该文件,以便于用户可以通过kubectl对集群进行管理. 如果攻击者能够访问到此文件（如办公网员工机器入侵、泄露到Github的代码等），就可以直接通过API Server接管K8s集群，带来风险隐患。
Master节点SSH登录泄露
常见的容器集群管理方式是通过登录Master节点或运维跳板机，然后再通过kubectl命令工具来控制k8s。
云服务器提供了通过ssh登陆的形式进行登陆master节点.
若Master节点SSH连接地址泄露,攻击者可对ssh登陆进行爆破,从而登陆上ssh,控制集群.
容器组件未鉴权服务
Kubernetes架构下常见的开放服务指纹如下:
kube-apiserver: 6443, 8080
kubectl proxy: 8080, 8081
kubelet: 10250, 10255, 4149
dashboard: 30000
docker api: 2375
etcd: 2379, 2380
kube-controller-manager: 10252
kube-proxy: 10256, 31442
kube-scheduler: 10251
weave: 6781, 6782, 6783
kubeflow-dashboard: 8080
注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务
了解各个组件被攻击时所造成的影响
组件分工图:
假如用户想在集群里面新建一个容器集合单元, 流程如下:
用户与 kubectl进行交互,提出需求(例: kubectl create -f pod.yaml)
kubectl 会读取 ~/.kube/config 配置，并与 apiserver 进行交互，协议：http/https
apiserver 会协同 ETCD, kube-controller-manager, scheduler 等组件准备下发新建容器的配置给到节点，协议：http/https
apiserver 与 kubelet 进行交互，告知其容器创建的需求，协议：http/https；
kubelet 与Docker等容器引擎进行交互，创建容器，协议：http/unix socket.
容器已然在集群节点上创建成功
攻击apiserver
apiserver介绍:
在Kubernetes中,对于未鉴权对apiserver, 能访问到 apiserver 一般情况下就能获取了集群的权限.
在攻击者眼中Kubernetes APIServer
容器编排K8S总控组件
pods, services, secrets, serviceaccounts, bindings, componentstatuses, configmaps,
endpoints, events, limitranges, namespaces, nodes, persistentvolumeclaims,
persistentvolumes, podtemplates, replicationcontrollers, resourcequotas …
可控以上所有k8s资源
可获取几乎所有容器的交互式shell
利用一定技巧可获取所有容器母机的交互式shell
默认情况下apiserver都有鉴权:
未鉴权配置如下:
对于这类的未鉴权的设置来说，访问到 apiserver 一般情况下就获取了集群的权限：
如何通过apiserver来进行渗透,可参考:
攻击kubelet
每一个Node节点都有一个kubelet(每个节点上运行的代理)服务，kubelet监听了10250，10248，10255等端口。
10250端口,是kubelet与apiserver进行通信对主要端口, 通过该端口,kubelet可以知道当前应该处理的任务.该端口在最新版Kubernetes是有鉴权的, 但在开启了接受匿名请求的情况下，不带鉴权信息的请求也可以使用10250提供的能力, 在Kubernetes早期,很多挖矿木马基于该端口进行传播.
在配置文件中,若进行如下配置,则可能存在未授权访问漏洞.
/var/bin/kubulet/config/yaml
若10250端口存在未授权访问漏洞,我们可以直接访问/pods进行查看
根据在pods中获取的信息,我们可以在容器中执行命令
curl -Gks {namespace}/{podname}/{containername} \-d 'input=1' -d 'output=1' -d 'tty=1' \-d 'command=whoami'
上述命令得到websocket地址，连接websocket得到命令结果：
使用wscat工具连接websocket
wscat -c “{websocket}” --no-check
即可得到我们执行命令的结果.
获取token
/var/run/secrets/kubernetes.io/serviceaccount
然后即可访问kube-api server,获取集群权限
curl -ks -H "Authorization: Bearer \ ttps://master:6443/api/v1/namespaces/{namespace}/secrets
"
攻击kubelet总体步骤如下:
访问pods获取信息
获取namespace、podsname、containername
执行exec获取token
/var/run/secrets/kubernetes.io/serviceaccount
利用Token访问API Server进行对pods操作。
攻击dashboard
dashboard登陆链接如下:
dashboard界面如下:
dashboard是Kubernetes官方推出的控制Kubernetes的图形化界面.在Kubernetes配置不当导致dashboard未授权访问漏洞的情况下，通过dashboard我们可以控制整个集群。
默认情况下, dashboard是需要进行鉴权操作的,当用户开启了enable-skip-login时可以在登录界面点击Skip跳过登录进入dashboard.
通过skip登陆的dashboard默认是没有操作集群的权限,因为Kubernetes使用RBAC(Role-based access control)机制进行身份认证和权限管理，不同的serviceaccount拥有不同的集群权限。
但有些开发者为了方便或者在测试环境中会为Kubernetes-dashboard绑定cluster-admin这个ClusterRole（cluster-admin拥有管理集群的最高权限）.
为Kubernetes-dashboard绑定cluster-admin 设置如下:
新建dashboard-admin.yaml内容
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard
kubectl create -f dashboard-admin.yaml
后通过skip登陆dashboard便有了管理集群的权限.
创建Pod控制node节点,该pod主要是将宿主机根目录挂载到容器tmp目录下。
新建一个Pod如下:
通过该容器的tmp目录管理node节点的文件
攻击etcd
Kubernetes默认使用了etcd v3来存储数据, 若能na
etcd对内暴露2379端口，本地127.0.0.1可免认证访问. 其他地址要带—endpoint参数和cert进行认证。
未授权访问流程:
检查是否正常链接
etcdctl endpoint health
读取service account token
etcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterrole
通过token认访问API-Server端口6443，接管集群：
kubectl --insecure-skip-tls-verify -s --token="[ey...]" -n kube-system get pods
攻击docker remote api(Docker daemon公网暴露)
2375是docker远程操控的默认端口，通过这个端口可以直接对远程的docker 守护进程进行操作。Docker 守护进程默认监听2375端口且未鉴权.
当机器以方式启动daemon时，可以在外部机器对该机器的docker daemon进行直接操作：
docker daemon -H=0.0.0.0:2375
之后依次执行systemctl daemon-reload、systemctl restart docker
外部主机使用 即可操作暴露2375端口的主机.
-H
因此当你有访问到目标Docker API 的网络能力或主机能力的时候，你就拥有了控制当前服务器的能力。我们可以利用Docker API在远程主机上创建一个特权容器，并且挂载主机根目录到容器.
检测目标是否存在docker api未授权访问漏洞的方式也很简单，访问http://[host]:[port]/info路径是否含有ContainersRunning、DockerRootDir等关键字。
攻击kubectl proxy
二次开发所产生的问题
管理Kubernetes无论是使用 kubectl 或 Kubernetes dashboard 的UI功能，其实都是间接在和 APIServer 做交互.
如果有需求对k8s进行二次开发的话,大部分的开发功能请求了 APIServer 的 Rest API 从而使功能实现的。
例如:
给用户销毁自己POD的能力
DELETE
类似于这样去调用apiserver, 攻击者若修改namespace、pod和容器名, 那么即可造成越权.
推荐工具
Kube-Hunter扫描漏洞
kube-hunter是一款用于寻找Kubernetes集群中的安全漏洞扫描器
下载地址:
CDK(强推)
CDK是一款为容器环境定制的渗透测试工具，在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。
下载地址:
参考链接
渗透测试应该怎么做呢？
01、信息收集
1、域名、IP、端口
域名信息查询：信息可用于后续渗透
IP信息查询：确认域名对应IP，确认IP是否真实，确认通信是否正常
端口信息查询：NMap扫描，确认开放端口
发现：一共开放两个端口，80为web访问端口，3389为windows远程登陆端口，嘿嘿嘿，试一下
发现：是Windows Server 2003系统，OK，到此为止。
2、指纹识别
其实就是网站的信息。比如通过可以访问的资源，如网站首页，查看源代码:
看看是否存在文件遍历的漏洞（如图片路径，再通过…/遍历文件）
是否使用了存在漏洞的框架（如果没有现成的就自己挖）
02、漏洞扫描
1、主机扫描
Nessus
经典主机漏扫工具，看看有没有CVE漏洞：
2、Web扫描
AWVS（Acunetix | Website Security Scanner）扫描器
PS：扫描器可能会对网站构成伤害，小心谨慎使用。
03、渗透测试
1、弱口令漏洞
漏洞描述
目标网站管理入口（或数据库等组件的外部连接）使用了容易被猜测的简单字符口令、或者是默认系统账号口令。
渗透测试
① 如果不存在验证码，则直接使用相对应的弱口令字典使用burpsuite 进行爆破
② 如果存在验证码，则看验证码是否存在绕过、以及看验证码是否容易识别
风险评级：高风险
安全建议
① 默认口令以及修改口令都应保证复杂度，比如：大小写字母与数字或特殊字符的组合，口令长度不小于8位等
② 定期检查和更换网站管理口令
2、文件下载（目录浏览）漏洞
漏洞描述
一些网站由于业务需求，可能提供文件查看或下载的功能，如果对用户查看或下载的文件不做限制，则恶意用户就能够查看或下载任意的文件，可以是源代码文件、敏感文件等。
渗透测试
① 查找可能存在文件包含的漏洞点，比如js，css等页面代码路径
② 看看有没有文件上传访问的功能
③ 采用…/来测试能否夸目录访问文件
风险评级：高风险
安全建议
① 采用白名单机制限制服务器目录的访问，以及可以访问的文件类型(小心被绕过)
② 过滤【./】等特殊字符
③ 采用文件流的访问返回上传文件（如用户头像），不要通过真实的网站路径。
示例：tomcat，默认关闭路径浏览的功能：
param-namelistings/param-name
param-valuefalse/param-value
3、任意文件上传漏洞
漏洞描述
目标网站允许用户向网站直接上传文件，但未对所上传文件的类型和内容进行严格的过滤。
渗透测试
① 收集网站信息，判断使用的语言（PHP，ASP，JSP）
② 过滤规则绕过方法：文件上传绕过技巧
风险评级：高风险
安全建议
① 对上传文件做有效文件类型判断，采用白名单控制的方法，开放只允许上传的文件型式；
② 文件类型判断，应对上传文件的后缀、文件头、图片类的预览图等做检测来判断文件类型，同时注意重命名（Md5加密）上传文件的文件名避免攻击者利用WEB服务的缺陷构造畸形文件名实现攻击目的；
③ 禁止上传目录有执行权限；
④ 使用随机数改写文件名和文件路径，使得用户不能轻易访问自己上传的文件。
4、命令注入漏洞
漏洞描述
目标网站未对用户输入的字符进行特殊字符过滤或合法性校验，允许用户输入特殊语句，导致各种调用系统命令的web应用，会被攻击者通过命令拼接、绕过黑名单等方式，在服务端运行恶意的系统命令。
渗透测试
风险评级：高风险
安全建议
① 拒绝使用拼接语句的方式进行参数传递；
② 尽量使用白名单的方式（首选方式）；
③ 过滤危险方法、特殊字符，如：【|】【】【；】【’】【"】等
5、SQL注入漏洞
漏洞描述
目标网站未对用户输入的字符进行特殊字符过滤或合法性校验，允许用户输入特殊语句查询后台数据库相关信息
渗透测试
① 手动测试：判断是否存在SQL注入，判断是字符型还是数字型，是否需要盲注
② 工具测试：使用sqlmap等工具进行辅助测试
风险评级：高风险
安全建议
① 防范SQL注入攻击的最佳方式就是将查询的逻辑与其数据分隔，如Java的预处理，PHP的PDO
② 拒绝使用拼接SQL的方式
6、跨站脚本漏洞
漏洞描述
当应用程序的网页中包含不受信任的、未经恰当验证或转义的数据时，或者使用可以创建 HTML或JavaScript 的浏览器 API 更新现有的网页时，就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。
三种XSS漏洞：
① 存储型：用户输入的信息被持久化，并能够在页面显示的功能，都可能存在存储型XSS，例如用户留言、个人信息修改等。
② 反射型：URL参数需要在页面显示的功能都可能存在反射型跨站脚本攻击，例如站内搜索、查询功能。
③ DOM型：涉及DOM对象的页面程序，包括：document.URL、document.location、document.referrer、window.location等
渗透测试
存储型，反射型，DOM型
风险评级：高风险
安全建议
① 不信任用户提交的任何内容，对用户输入的内容，在后台都需要进行长度检查，并且对【】【】【"】【’】【】等字符做过滤
② 任何内容返回到页面显示之前都必须加以html编码，即将【】【】【"】【’】【】进行转义。
7、跨站请求伪造漏洞
漏洞描述
CSRF，全称为Cross-Site Request Forgery，跨站请求伪造，是一种网络攻击方式，它可以在用户毫不知情的情况下，以用户的名义伪造请求发送给被攻击站点，从而在未授权的情况下进行权限保护内的操作，如修改密码，转账等。
渗透测试
风险评级：中风险（如果相关业务极其重要，则为高风险）
安全建议
① 使用一次性令牌：用户登录后产生随机token并赋值给页面中的某个Hidden标签，提交表单时候，同时提交这个Hidden标签并验证，验证后重新产生新的token，并赋值给hidden标签；
② 适当场景添加验证码输入：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串；
③ 请求头Referer效验，url请求是否前部匹配Http(s)😕/ServerHost
④ 关键信息输入确认提交信息的用户身份是否合法，比如修改密码一定要提供原密码输入
⑤ 用户自身可以通过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie；
8、内部后台地址暴露
漏洞描述
一些仅被内部访问的地址，对外部暴露了，如：管理员登陆页面；系统监控页面；API接口描述页面等，这些会导致信息泄露，后台登陆等地址还可能被爆破。
渗透测试
① 通过常用的地址进行探测，如login.html，manager.html，api.html等；
② 可以借用burpsuite和常规页面地址字典，进行扫描探测
风险评级：中风险
安全建议
① 禁止外网访问后台地址
② 使用非常规路径（如对md5加密）
9、信息泄露漏洞
漏洞描述
① 备份信息泄露：目标网站未及时删除编辑器或者人员在编辑文件时，产生的临时文件，或者相关备份信息未及时删除导致信息泄露。
② 测试页面信息泄露：测试界面未及时删除，导致测试界面暴露，被他人访问。
③ 源码信息泄露：目标网站文件访问控制设置不当，WEB服务器开启源码下载功能，允许用户访问网站源码。
④ 错误信息泄露：目标网站WEB程序和服务器未屏蔽错误信息回显，页面含有CGI处理错误的代码级别的详细信息，例如SQL语句执行错误原因，PHP的错误行数等。
⑤ 接口信息泄露：目标网站接口访问控制不严，导致网站内部敏感信息泄露。
渗透测试
① 备份信息泄露、测试页面信息泄露、源码信息泄露，测试方法：使用字典，爆破相关目录，看是否存在相关敏感文件
② 错误信息泄露，测试方法：发送畸形的数据报文、非正常的报文进行探测，看是否对错误参数处理妥当。
③ 接口信息泄露漏洞，测试方法：使用爬虫或者扫描器爬取获取接口相关信息，看目标网站对接口权限是否合理
风险评级：一般为中风险，如果源码大量泄漏或大量客户敏感信息泄露。
安全建议
① 备份信息泄露漏洞：删除相关备份信息，做好权限控制
② 测试页面信息泄露漏洞：删除相关测试界面，做好权限控制
③ 源码信息泄露漏洞：做好权限控制
④ 错误信息泄露漏洞：将错误信息对用户透明化，在CGI处理错误后可以返回友好的提示语以及返回码。但是不可以提示用户出错的代码级别的详细原因
⑤ 接口信息泄露漏洞：对接口访问权限严格控制
10、失效的身份认证
漏洞描述
通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌， 或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。
渗透测试
① 在登陆前后观察，前端提交信息中，随机变化的数据，总有与当前已登陆用户进行绑定的会话唯一标识，常见如cookie
② 一般现在网站没有那种简单可破解的标识，但是如果是跨站认证，单点登录场景中，可能为了开发方便而简化了身份认证
风险评级：高风险
安全建议
① 使用强身份识别，不使用简单弱加密方式进行身份识别；
② 服务器端使用安全的会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储，在登出、闲置超时后使其失效。
11、失效的访问控制
漏洞描述
未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。
渗透测试
① 登入后，通过burpsuite 抓取相关url 链接，获取到url 链接之后，在另一个浏览器打开相关链接，看能够通过另一个未登入的浏览器直接访问该功能点。
② 使用A用户登陆，然后在另一个浏览器使用B用户登陆，使用B访问A独有的功能，看能否访问。
风险评级：高风险
安全建议
① 除公有资源外，默认情况下拒绝访问非本人所有的私有资源；
② 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害；
③ 当用户注销后，服务器上的Cookie，JWT等令牌应失效；
④ 对每一个业务请求，都进行权限校验。
12、安全配置错误
漏洞描述
应用程序缺少适当的安全加固，或者云服务的权限配置错误。
① 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。
② 默认帐户的密码仍然可用且没有更改。
③ 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
④ 对于更新的系统，禁用或不安全地配置最新的安全功能。
⑤ 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进行相关安全配置。
渗透测试
先对应用指纹等进行信息搜集，然后针对搜集的信息，看相关应用默认配置是否有更改，是否有加固过；端口开放情况，是否开放了多余的端口；
风险评级：中风险
安全建议
搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。在所有环境中按照标准的加固流程进行正确安全配置。
13、使用含有已知漏洞的组件
漏洞描述
使用了不再支持或者过时的组件。这包括：OS、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库。
渗透测试
① 根据前期信息搜集的信息，查看相关组件的版本，看是否使用了不在支持或者过时的组件。一般来说，信息搜集，可通过http返回头、相关错误信息、应用指纹、端口探测（Nmap）等手段搜集。
② Nmap等工具也可以用于获取操作系统版本信息
③ 通过CVE，CNVD等平台可以获取当前组件版本是否存在漏洞
风险评级：按照存在漏洞的组件的安全风险值判定当前风险。
安全建议
① 移除不使用的依赖、不需要的功能、组件、文件和文档；
② 仅从官方渠道安全的获取组件(尽量保证是最新版本)，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险；
③ 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。
详细学习可参考：
Python渗透测试工具都有哪些
网络
Scapy, Scapy3k: 发送，嗅探，分析和伪造网络数据包。可用作交互式包处理程序或单独作为一个库
pypcap, Pcapy, pylibpcap: 几个不同 libpcap 捆绑的python库
libdnet: 低级网络路由，包括端口查看和以太网帧的转发
dpkt: 快速，轻量数据包创建和分析，面向基本的 TCP/IP 协议
Impacket: 伪造和解码网络数据包，支持高级协议如 NMB 和 SMB
pynids: libnids 封装提供网络嗅探，IP 包碎片重组，TCP 流重组和端口扫描侦查
Dirtbags py-pcap: 无需 libpcap 库支持读取 pcap 文件
flowgrep: 通过正则表达式查找数据包中的 Payloads
Knock Subdomain Scan: 通过字典枚举目标子域名
SubBrute: 快速的子域名枚举工具
Mallory: 可扩展的 TCP/UDP 中间人代理工具，可以实时修改非标准协议
Pytbull: 灵活的 IDS/IPS 测试框架（附带超过300个测试样例）
调试和逆向工程
Paimei: 逆向工程框架，包含PyDBG, PIDA , pGRAPH
Immunity Debugger: 脚本 GUI 和命令行调试器
mona.py: Immunity Debugger 中的扩展，用于代替 pvefindaddr
IDAPython: IDA pro 中的插件，集成 Python 编程语言，允许脚本在 IDA Pro 中执行
PyEMU: 全脚本实现的英特尔32位仿真器，用于恶意软件分析
pefile: 读取并处理 PE 文件
pydasm: Python 封装的libdasm
PyDbgEng: Python 封装的微软 Windows 调试引擎
uhooker: 截获 DLL 或内存中任意地址可执行文件的 API 调用
diStorm: AMD64 下的反汇编库
python-ptrace: Python 写的使用 ptrace 的调试器
vdb/vtrace: vtrace 是用 Python 实现的跨平台调试 API, vdb 是使用它的调试器
Androguard: 安卓应用程序的逆向分析工具
Capstone: 一个轻量级的多平台多架构支持的反汇编框架。支持包括ARM,ARM64,MIPS和x86/x64平台
PyBFD: GNU 二进制文件描述(BFD)库的 Python 接口
Fuzzing
Sulley: 一个模糊器开发和模糊测试的框架，由多个可扩展的构件组成的
Peach Fuzzing Platform: 可扩展的模糊测试框架(v2版本 是用 Python 语言编写的)
antiparser: 模糊测试和故障注入的 API
TAOF: (The Art of Fuzzing, 模糊的艺术)包含 ProxyFuzz, 一个中间人网络模糊测试工具
untidy: 针对 XML 模糊测试工具
Powerfuzzer: 高度自动化和可完全定制的 Web 模糊测试工具
SMUDGE: 纯 Python 实现的网络协议模糊测试
Mistress: 基于预设模式，侦测实时文件格式和侦测畸形数据中的协议
Fuzzbox: 媒体多编码器的模糊测试
Forensic Fuzzing Tools: 通过生成模糊测试用的文件，文件系统和包含模糊测试文件的文件系统，来测试取证工具的鲁棒性
Windows IPC Fuzzing Tools: 使用 Windows 进程间通信机制进行模糊测试的工具
WSBang: 基于 Web 服务自动化测试 SOAP 安全性
Construct: 用于解析和构建数据格式(二进制或文本)的库
fuzzer.py(feliam): 由 Felipe Andres Manzano 编写的简单模糊测试工具
Fusil: 用于编写模糊测试程序的 Python 库
Web
Requests: 优雅，简单，人性化的 HTTP 库
HTTPie: 人性化的类似 cURL 命令行的 HTTP 客户端
ProxMon: 处理代理日志和报告发现的问题
WSMap: 寻找 Web 服务器和发现文件
Twill: 从命令行界面浏览网页。支持自动化网络测试
Ghost.py: Python 写的 WebKit Web 客户端
Windmill: Web 测试工具帮助你轻松实现自动化调试 Web 应用
FunkLoad: Web 功能和负载测试
spynner: Python 写的 Web浏览模块支持 Javascript/AJAX
python-spidermonkey: 是 Mozilla JS 引擎在 Python 上的移植，允许调用 Javascript 脚本和函数
mitmproxy: 支持 SSL 的 HTTP 代理。可以在控制台接口实时检查和编辑网络流量
pathod/pathoc: 变态的 HTTP/S 守护进程，用于测试和折磨 HTTP 客户端