渗透思路基础

根据下面所提到的技术问题，每个网站的不同所导致的渗透思路也有所不同

域名和 IP 相关

主站&分站&端口站&子站

对于一个网站，可能一个 IP 地址下有多个网站，也可能一个域名关联多个 IP 地址；主站、分站、端口站（不同端口来代表不同的站）、目录站（对于不同的目录是一个网站或是该目录下的子目录也是一个网站）、子站等。（通过子域名收集，网站目录扫描，端口扫描等方式来进行信息收集）

源码语言&解析相关

• 代码的目录结构不同，前后端、文件、配置文件目录等
• 开发语言和开发框架
• 开源、闭源、编译调用源码和加密问题
• URL 路由&绝对相对路径&格式权限的问题（后门解析格式，代码正常执行，脚本执行权限等）

框架开发中，MVC 模型源码，网站是根据框架的路由决定的，而不是简单的目录解析。所以在渗透网站或代码审计时，MVC 和非 MVC 模型的源码会有所不同，需要对其熟悉。（比如：不同目录下所代表的不同的代码内容）

数据相关

对于一个网站所关联的数据库，可能是本地数据库、分离数据库（数据库和网站不是同一个 IP 地址）、云数据库。数据库连接可以限制只让某些固定的 IP 来连接，比如网站的服务器；这样即使知道数据库的账号密码也无法进行连接，一种渗透思路是：

1. 上传一个数据库连接脚本到网站上，访问脚本去让脚本连接数据库；
2. 利用网站权限上传代理流量工具，做数据中转的操作，去连接数据库；

开发平台相关

开发系统&中间件类型&容器类型（虚拟机、Docker）

Web 架构相关

• 套用已有模版建站：csdn、cnblog 和建站系统等；
• 前后端分离：
  • 思路： https://mp.weixin.qq.com/s/HtLU_EBXWcbq-lt10oPYwA
• 集成软件包：宝塔，phpstudy，xamp 等
• 自主环境镜像：云镜像打包，自行一个个的搭建的网站
• 容器拉取镜像：Docker
• 纯静态页面：其主要在于找资产，域名，客户端等

不同的建站方式其渗透思路，或者本身的权限也有所不同；

例如：在宝塔、自主环境镜像和 Docker 搭建的同一个靶场网站中，上传的 webshell 所连接后得到的权限有所不同；这主要和其本身的防护体系、权限控制不同有关。

再比如：基于一些专门的建站工具，渗透的时候思路主要是寻找该建站工具系统本身的问题。（因为本身用这些建站的中小型企业用的也是这些建站工具系统的东西）

WAF 防护

WAF 为 Web 应用防火墙，常规的 Web 安全测试手段会受到拦截（现阶段一些老的 WAF 逐渐淘汰，新的 WAF 难以绕过）

例如雷池 WAF ： https://docs.waf-ce.chaitin.cn/ ；配置雷池：添加站点-设置域名-上游地址-没真实域名修改本地 host 解析

CDN 加速

内容分发服务，旨在提高访问速度；会隐藏真实 IP，导致对目标 IP 测试错误

OSS 存储

云存储服务，也是为了提高访问速度；静态文件会占用大量的带宽，影响加载速度和空间；

上传的文件或解析的文件均来自 OSS 资源，无法解析，单独存储；这样就修复了文件上传的安全问题，导致文件解析不一样，但存在 AK/SK 隐患

负载均衡

将一个服务分摊到多个操作单元上执行，共同完成工作任务；多个服务器加载服务，测试过程中则会存在多个目标的情况，影响对目标服务器的攻击；

一般在配置文件中配置，示例：Windows2016 + 宝塔面板 + Nginx

# 定义负载设置
upstream fzjh{
	server 120.26.70.72:80 weight=1;
	server 47.75.212.155:80 weight=2;
}

# 定义访问路径 访问策略
location / {
	proxy_pass http://fzjh/;
}

此时访问 http://fzjh/ 后的内容，会依照权重随机的访问上面两个不同的 IP 地址所对应服务器上的内容；

反向代理

• 正向代理为客户端服务，客户端主动建立代理访问目标（不代理不可达）
  • 例如翻墙访问外网
• 反向代理为服务端服务，服务端主动转发数据给可访问地址（不主动不可达）
  • 通过网络反向代理转发真实服务达到访问目的
  • 例如：无法访问外网，但另一台服务器可以访问，则当我访问该服务器上的内容时，该服务器实际上通过自身将我重定向到外网

注意：正向代理和反向代理都是解决访问不可达的问题，但由于反向代理中多出一个可以重定向解析的功能操作，导致反代理出的站点指向和真实应用毫无关系！

蜜罐-钓鱼诱使

主要是用来钓鱼或诱惑测试人员的防护系统；

可用测试示例： https://hfish.net/ bash <(curl -sS -L https://hfish.net/webinstall.sh) 可一键安装

堡垒机-突破口

堡垒机主要是方便运维人员对当前网络环境下的资产进行登记管理等操作；这也给攻击测试人员提供了一个获取大量有价值信息的入口；

可用测试示例： https://www.jumpserver.org/ curl -sSL https://resource.fit2cloud.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash 可一键安装

API 接口-突破口

API 接口方便不同软件应用程序之间进行通信和数据交换的接口；通过定义一组规则和协议，软件开发者使用这些规则和协议来访问操作系统、库、服务或其他应用程序功能。

攻击者可以借助服务所提供的 API 来获取当前网站不想让你获取的一些信息；通过分析 API 的目录结构、接口命名规则、参数命名规则、功能和业务逻辑等，根据这些信息可以进行接口枚举和参数枚举，进而可以进行相关的漏洞测试。

其他架构-突破口

例如：防火墙、消息队列、分布式等

网站的搭建用到越多的应用来方便运维的同时也给测试人员更多的机会；

Web 架构演变简单总结介绍： https://mp.weixin.qq.com/s/SEjxrUgiIIK2bveSBz6mTg

一个漏洞库： https://www.yuque.com/u25571586/dyaqbugs?# 密码：xnzx【密码可能会更新，在公众号 道一安全 更新】

APP 应用开发框架

• 原生开发：安卓一般使用 java 语言开发，现也有 kotlin 语言开发；
  • 和 Web 端类似，可通过反编译&流量抓包&常规 Web 测试等操作；逆向角度分析逻辑设计安全；
• 使用 H5 语言开发：可多端复用；（但相比原生开发体验较差）
  • H5&Vue-HBuilderX；API&JS 框架安全问题&JS 前端测试；
• 使用 flutter 开发：谷歌退出的 UI 框架，使用 dart 语言开发，支持快平台，weight 渲染直接操作硬件层，体验也较好，技术较新，生态不完善；
• 常规 Web 开发：开发一个网站，再加入 app 的壳，体验较差；
  • Web 封装 - 封装平台可实现；和常规的 Web 安全测试一样；
• 小程序开发

  • https://mp.weixin.qq.com/s/dXTb0wk57-bLA3tUuvOFSw 【小程序开发模式的简单介绍】

  • https://mp.weixin.qq.com/s/SIWBZv_vZ6AGtHrl3hpR9A 【GitHub 上的一些小程序源码】

通用手段：反编译->源码->提取资产（泄露的配置信息）->安全测试 / 抓包->资产->安全测试

对于 APP ，有些会有一些防护，eg：检测模拟器，检测代理抓包等；可通过真机绕过&更改内核&证书绕过&代理绕过等方式解决；

数据不回显

以 RCE 为例；原因是代码层面函数调用问题，没有输出测试等；

• 过程：

  • 判断是不是数据不回显并且有漏洞；
  • 有漏洞，思考如何获取到执行后得到的数据；

• 常用的一些操作：

  • 反弹权限；
  • 数据外带（利用 DNSlog、TCP-Portlog、ICMP-Sizelog 得到的回显反应来判断是否存在漏洞）；

• 延迟判断，例如 ping 发包查看回显时间来判断；

• 写访问文件，写入可访问的文件来判断；

数据不出网

• 判断出入限制的端口和协议
• 分析原因用正向还是反向还是隧道

主要原因还是主机或应用防火墙对出入站的限制

• 正向连接：攻击机主动连接靶机
  • 靶机监听端口，攻击机访问（连接）对应端口
• 反向连接：靶机主动出网连接攻击机
  • 攻击机监听端口，靶机链接对应端口
• 采用其他协议隧道
  • ICMP、DNS 等隧道技术

反弹 Shell 相关

• 正向/反向；
• 目标主机的操作系统；
• 支持的语言/shell 脚本（以及版本）；

eg：目标主机有 rce 漏洞，执行下载文件命令使其可以运行 nc，进行反向连接；若命令执行过程中失败，一种可能是命令太长超过限制，或是命令和原本文件中的一些字符进行的拼接等冲突导致，可将命令封装成一个可执行文件，或是简化命令，使目标进行下载再执行。

数据传输格式及编码相关

JSON、XML、WebSockets、HTML、二进制、自定义等数据传输格式；

对数据进行编码，eg：MD5、Base64、自定义编码等；

不同得到传输格式：

https://zhuanlan.zhihu.com/p/712032652

https://cloud.tencent.com/developer/article/1917215

https://www.cnblogs.com/wanglei1900/p/17177303.html

主要影响：测试时需要统一的格式及编码进行发送，不然无法得到原本正常的响应；

密码算法解密，混淆自定义式的加密等，可能需要代码审计，逆向破解；

密码编码总结：

https://blog.csdn.net/qq_41638851/article/details/100526839

https://blog.csdn.net/qq_40837276/article/details/83080460

30余种加密编码类型的密文特征分析

应用场景：

1. 发送数据自动将数据加密发送；
   • 需要将 Payload 也加密发送，需要寻找加密逻辑；通过源代码审计或是调用应用的 JS 加密逻辑进行提交测试；
2. 假如要得到数据的明文；
   • 则必须要得到解密算法；由于解密条件不同，需要秘钥、偏移量、私钥等；

对后续测试的影响：

1. 目标：API 接口、前后端分离应用居多；
2. 漏洞发现：未授权、各类漏洞测试、爆破等；

数据包协议相关

对数据包进行分析：

• Request：请求方法、路径、请求头等；
• Response：状态码等；

部分需要注意的点：

对于响应包状态为 3XX ，网页并不一定存在再做了跳转，可能是网站做了容错处理，一旦访问错误页面就跳转到固定的地址；这种情况下，请求的路径或文件则是不存在的。200 和 404 同样会存在这样的容错处理；这样则会导致检测扫描工具出现误报问题。

数据包中各个参数都可能存在不同的漏洞点，例如：

• 网站有 UA 收集整理功能，如果将 UA 信息记录到数据库的话，这个过程有接受 UA 信息及写入数据库的操作，这个地方可能存在 SQL 注入
• 渗透测试习惯：部分网站做了限制设备访问的需求，手机或电脑只能访问一个，如果我们自己要电脑测试需要更改成手机访问才可以继续
• Cookie-用户身份
• Post 数据-登录爆破
• 返回状态码-文件探针

网站身份鉴权相关

• HTTP：明文传输；80 端口；
• HTTPS：SSL/TLS 对数据进行加密，，需要通过数字证书和 SSL/TLS 协议验证服务器身份；443 端口；

针对网卡上的嗅探等攻击，有 HTTPS 就很难实现。

身份鉴权技术：Cookie、Session、Token、JWT、oauth2 等

https://mp.weixin.qq.com/s/Z6rt_ggCA8dNVJPgELZ44w

https://juejin.cn/post/7300812626279251987

根据不同的身份鉴别方式采用不同的攻击方式。

eg：oauth 方式中的授权码模式，扫码后会有 URL ：/oauth/authorize?client_id=baidu&response-type=code&scope=all&redirect_url=http://www.baidu.com，client_id客户端 id ，scope权限范围，redirect_url重定向 URL 授权后跳转；可以通过修改redirect_url来让用户扫码后跳转到攻击者指定的网站。

可能存在的安全漏洞问题：

1. redirect_url 校验不严格导致 code 被劫持到恶意网站（fuzz 各种 bypass 方式）；
2. client_id 与 redirect_url 不一致造成滥用劫持；
3. A 应用生成的 code 可以用在 B 应用上；
4. state 未设置 csrf 防护，导致 csrf 风险；
5. scope 提权，将低 scope 权限的 code 用于高权限场景；
6. HTTP 劫持，网络层中间人攻击；
7. 点击劫持：通过点击劫持，恶意网站会在以下位置加载目标网站： 透明 iFrame 覆盖在一组虚拟的顶部精心构造的按钮直接放置在目标站点上的重要按钮。当用户单击可见的按钮，他们实际上是在单击一个按钮（例如“授权” 按钮）在隐藏页面上。

Shell 脚本&用户权限&用户组等

• Windows -> .vbs或.bat；
• Linux -> .sh；

例如 Windows 中当 exe 文件无法运行被杀软杀掉时，Shell 脚本文件则不会受到这种影响；这在拿到系统后执行脚本很有作用。

用户/用户组等权限的不同对系统的控制能力不同；

https://mp.weixin.qq.com/s/qXZkKrF1vYtJv07L0-hkAA

利用 AI 工具操作

https://github.com/anyofai/anyofai.github.io

https://github.com/taranjeet/awesome-GPTs

https://github.com/fr0gger/Awesome-GPT-Agents

https://mp.weixin.qq.com/s/crfqpa_KqK6wR62N5gnVgQ