Intro And Funny Weakness

介绍和有趣的弱点

What You Need Know - MISC

Cloud（云）

什么是 云计算?

通过付费和互联网, 使得共享的软硬件资源和信息可以按需求提供给计算机各种终端和其他设备, 使用某个或者多个服务商提供的电脑基础建设用作于计算和资源. 这便是我们所看到的 云. (Everything as a Service. [EaaS,aaS])

我们可以把云计算理解为：Everything as a Service（EaaS） —— 你需要的一切基础设施、平台、软件，都可以通过 API 或控制台“即开即用”，无需自建机房、采购服务器、维护网络。

今天，像阿里云（Aliyun）、华为云、Google Cloud（GCP）、Amazon AWS 这样的大厂，为小微企业、个人开发者甚至学生，提供了一整套覆盖软件开发生命周期的“云原生”工具链和服务生态。这，就是我们眼中的“云”。

在本文中我们侧重于 开发 相关内容, 所以下面列出了开发者常用的云服务分类如下：

1. 代码管理

• 代码托管平台：如腾讯 Coding、GitHub（虽非传统云厂商，但常集成）、GitLab 等。

• 支持 CI/CD 集成，实现自动化构建与测试。

2. 数据存储

• 对象存储：如阿里云 OSS、腾讯云 COS，用于存图片、视频、备份等非结构化数据。

• 数据库即服务（DBaaS）：如 RDS（MySQL、PostgreSQL）、Redis、MongoDB 等，开箱即用，自动备份、监控、扩容。

3. 部署与运行环境

• 虚拟机（ECS/EC2）：最基础的计算单元，可自由安装系统和软件。

• 中间件服务：消息队列（RocketMQ、Kafka）、API 网关、配置中心等。

• CDN 与缓存：加速静态资源分发，提升用户体验。

• 安全防护：DDoS 防护、WAF、云防火墙，保障应用安全。

4. 虚拟化与云原生

• 容器编排：直接购买托管 Kubernetes 集群（如 ACK、EKS），省去搭建和维护成本。

• 存储虚拟化：云盘、快照、共享文件系统（NAS）。

• 网络虚拟化：VPC（虚拟私有云）、自定义子网、安全组、弹性 IP、内网 DNS。

• 镜像仓库：私有容器镜像托管（如 ACR、ECR），支持版本管理和安全扫描。

5. 周边高阶服务

• GPU/高性能计算：为 AI 训练、科学计算提供专用实例。

• Serverless：如函数计算（FC、Lambda），无需管理服务器，按调用付费，极致降本。

• 运维可观测性：日志服务（SLS）、应用性能监控（APM）、告警通知。

• 域名与网站托管：一站式完成备案、解析、HTTPS 配置。

• IoT 与通信：设备接入平台、短信服务、语音通知等。

• 可编程云：通过 CLI、SDK 或 Terraform 调用云 API，实现基础设施即代码（IaC）。

Infrastructure-as-Code（IaC）

IaC（基础架构即代码）并非凭空出现，而是源于开发与运维之间那道“看不见却摸得着”的墙。

🧱 背后的痛点

在传统流程中：

• 开发没有服务器权限：出于安全与合规，生产环境对开发者是“黑盒”。想排查一个部署问题？只能靠运维“代劳”，效率低、反馈慢。

• 上线流程冗长：代码要经过 Review → 测试 → 构建 → 发布 → 部署，链条越长，信息失真越严重。

• 文档形同虚设：“部署说明.md”写完就过时，版本一升级，环境一变更，没人更新，也没人敢信。于是，部署变成了一种玄学——“在我机器上是好的”。（伏笔）

💡 IaC 的破局之道

IaC 的核心思想很简单：

把基础设施（服务器、网络、数据库、中间件等）用代码或配置文件来描述，并通过工具自动创建和管理。

通过配置类或者简单脚本类的工具, 定义或者声明一个部署的过程和依赖的资源(依赖库版本, 打包方式, 启动方式, 服务器资源(网络,数据库),日志), 就成为了一种沟通的方式.

比如：

• 用 Terraform 声明“我要一台 4核8G 的 ECS，挂载 100G 云盘，加入 VPC 子网，绑定安全组”；

• 用 Ansible 或 Puppet 定义“安装 Python 3.10，拉取 Git 代码，用 Gunicorn 启动 Flask 应用”；

• 用 Dockerfile + Kubernetes YAML 描述整个应用的运行时依赖与调度策略。

这些配置文件：

• 是可读的文本，不是口头约定；

• 可以提交到 Git，享受完整的版本控制、Code Review、分支管理；

• 能被 CI/CD 流水线自动执行，实现 “一次定义，处处部署”。

这就引出了一个更现代的理念：GitOps —— 以 Git 仓库作为系统真实状态的唯一来源，任何变更都通过 Pull Request 触发自动化同步。

🔄 开发即运维（Dev = Ops）

随着云、自动集成-自动部署 ( CICD ) 、IaC 和云原生工具链的成熟，“开发不碰生产”的旧范式正在瓦解：

• 开发者可以直接通过代码声明自己需要的资源；

• 通过监控告警（如 Prometheus + Grafana）、日志平台（如 ELK、SLS）直接观测线上行为；

• 借助 CI/CD（如 GitHub Actions、Jenkins、Argo CD）自助完成从提交到上线的全流程。

沟通成本消失了，迭代速度提升了，责任边界也更清晰了——谁写的代码，谁负责它在线上跑得好不好。

Wrap up

需要注意的是这一切的一切, 本质目的是 解决开发相关的其他困难, 即解决部署的困难(普通开发者不能直接买服务器放家里吧), 维护和配置的困难(要公网 IP 要配网吧), 也是为了让大多数的程序员更专心于业务代码的实现, 忽略其他的不必要的内容. 也使得企业或者组织的分工更为精细化, 权限更为的分散易控. (当然身为企业 还有其他的利弊, 但是这已经超过本文的主题了.)

How Attack Vector Included in DEV

攻击向量如何包含在DEV中

Intro

介绍

这里简单的以开发视角进行开发者开发周期作为基础的路线和视角, 简单总结一下, 一个产品或者一个服务脆弱点的引入位置.

Access Company

访问公司

Accessing and Authorization

访问和授权

当你作为新员工加入公司，通常会获得以下接入方式：

• 物理内网访问（如办公室 Wi-Fi）

• 远程接入通道：如 SSL VPN、Zero Trust 网络代理、云厂商提供的私有连接（如阿里云 PrivateLink、AWS Client VPN）

• 有时还会配合 SwitchHosts! 等工具手动修改本地 DNS，指向测试或内网环境

这些机制是合法员工进入企业内网的“正门”——看似受控，实则高危。
因为对攻击者而言，伪装成合法身份远比暴力突破防火墙高效得多。

“没人会去炸城墙，如果城门开着。”

现实印证了这一点：每年在 HVV中，总有企业因 SSLVPN 存在未修复漏洞（0day/Nday）而被批量沦陷。一旦攻破 VPN，等于直接站在内网核心区。

认证 ≠ 安全

当然，大门不会无人看守：

• 多数公司部署 统一身份认证系统（如 CAS、OAuth2、SAML）

• 提供 SSO（单点登录），集成办公、Git、CI/CD 等平台

• 高安全场景还会启用 MFA（多因素认证）

但问题在于：

• 员工账号可能因钓鱼、弱密码、凭证复用而泄露

• SSO 配置错误可能导致权限越界（如 ID Token 泄露、Scope 过宽）

• 一旦身份被冒用，内网横向移动几乎畅通无阻

因此，身份与接入层，是攻击者最优先尝试的入口之一。

inner or external Publisher

内部或外部发布者

很多公司对外提供官网或内容平台，常见形式包括：

• 静态资源托管（如 OSS + CDN，风险较低）

• 动态 CMS 系统：如 WordPress、DedeCMS、WebPlus 站群系统，用于新闻发布、文档展示等

这类系统常被当作“非核心业务”，不过也是暗藏风险：

• 若未及时更新，极易存在已知漏洞（如文件上传、SQL 注入、后台爆破）

• 有些 CMS 后台意外暴露在公网（如 /admin.php 未设 IP 白名单或强认证）

• 一旦攻破，可作为 初始立足点（Initial Foothold），进而探测内网资产

📌 典型案例：比如 前两年的 b 站 dedecms 暴露. 可能可以看到敏感信息, 打下来也是一个 foothold.

这类系统往往由市场、运营或外包团队维护，不在核心研发流程中，因此：

• 缺乏安全左移（Shift Left Security）

• 无自动化漏洞扫描

• 补丁管理滞后

但它们却是连接内外网络的桥梁。

💡 注：虽然 CMS 攻击面偏运维侧，但它常由开发流程中的“快速上线需求”催生，属于开发文化间接引入的风险，故仍值得警惕。

Before Code

代码之前

Project management

项目管理

真正的编码开始前，开发人员通常会收到一系列“启动材料”：

• 入职指南

• 业务需求文档（PRD）

• 系统设计图（架构图、接口定义）

• 测试用例与 Bug 清单

• 临时测试账号

这些内容往往存放在 项目管理平台（如禅道、Jira、TAPD）、企业邮箱、Confluence 或内部 Wiki 中。
对渗透测试者而言，一旦能访问这些信息，就等于拿到了项目的“施工蓝图”。

🗂️ 泄露致失守

如果攻击者通过钓鱼、凭证复用、子域名爆破等方式，获取了项目管理系统的只读权限，就能看到：

• 当前迭代的功能细节

• 已知漏洞列表（甚至包含 PoC）

• 内部测试账号（含用户名/密码）

• 接口文档（Swagger/YAPI 地址）

• 第三方服务密钥（AK/SK、Webhook URL）

💡 某些团队甚至会在 Jira 中直接写：“此处存在 SQL 注入，待修复”——这简直是给攻击者指路。

如果公司有定期安全测试的习惯，相关渗透报告、风险评级、修复建议也可能被归档在内部系统中。对攻击者来说，这就是捡到宝了。

当然我们可以进行一个"中间人", 监听甚至是伪造相关的信息, 来获得更大的权限和内容.

测试账号 + SSO

许多公司在开发/测试环境中，为了“省事”，会创建高权限测试账号，并接入 统一身份认证（SSO）。
这带来了两个致命问题：

🔓 问题一：绕过 MFA

• 测试账号通常不强制开启 2FA（如短信、OTP）

• 一旦密码泄露（或弱口令爆破成功），即可直接登录 SSO

• 通过 SSO 无缝跳转到生产环境的其他服务（如 GitLab、数据库控制台、监控平台）

👑 问题二：权限膨胀

• 测试账号常被赋予 VIP、管理员、内部员工 等特殊角色

• 在 SSO 体系下，这些权限会被透传到所有集成应用

• 攻击者可借此调用高危 API、导出用户数据、甚至修改线上配置

📌 这种脆弱点, 常常发生在具有开发较为大型程序或者网站的公司中. 接着我们可以着眼于文件服务, 共享服务一类的服务进行更多的信息探查和收集. 在渗透的闲暇时刻, 翻看这些内容总能有意想不到的收获.

这些信息对于获取一个公司的组织架构, 公司的成员信息, 高权限用户或者管理员具有很好的指示性作用和钓鱼价值. 为下一步行动提供一定的方向.

Office

这里主要想说的是相关 政务系统 OA 财务系统 邮件系统 Exchange 等等办公系统.

• OA / 政务系统：流程审批、组织架构

• 邮件系统（Exchange / 阿里云邮箱）：含大量通信记录、附件、会议纪要

• 财务系统：供应商信息、付款记录、银行账号

虽然与程序员日常编码关系不大，但以下系统往往是高价值目标：

这些系统通常：

• 由非技术部门维护

• 安全更新滞后

• 存在老旧组件（如 Struts2、ThinkPHP）

一旦攻破，不仅能获取高管邮箱、组织架构图，还可用于精准钓鱼（Spear Phishing），为后续攻击铺路。

当然只是简答一提. 也和程序员基本没太大关系 和开发也是扯远了.

Ignorable Access

可忽略访问

当然意外的暴露是也是非常致命的。最危险的暴露，往往源于开发/运维人员的“临时操作”：

包括但不限于易受攻击的内网服务, 匿名 Samba, FTP, git 等，不过这些已经是老生常谈了。

• 为调试方便，用 frp / ngrok 将本地服务反向代理到公网

• 临时在 Nginx 中加一条 location /debug { proxy_pass http://internal; }

• 误将 .env、config.yaml、id_rsa 上传到公开 Git 仓库

• 忘记关闭 Swagger UI、Grafana、Prometheus、Redis WebUI 等面板

这些服务：

• 监听非标准端口（如 8080、9090、3000）

• 无认证或弱认证

• 不在常规资产扫描范围内

结果就是：一个本该只在内网可见的监控面板，被搜索引擎收录，成为攻击者的后门。

📊 现实情况：看过部分渗透测试报告，许多安全团队专注于 OWASP Top 10（如 SQLi、XSS），却忽略了配置错误、服务暴露、权限滥用这类“低级但高危”的问题。

cloud era

现代云平台（如阿里云、AWS）提供了：

• 云防火墙

• 负载均衡 ACL

• 安全组策略

这些确实能过滤部分外部扫描和攻击流量，形成一定屏障。但它们无法防御“合法身份”的恶意操作：

• 如果攻击者已拿到管理员凭证

• 或通过测试账号+SSO获得权限

• 那么所有操作看起来都是“正常维护”

DevSecOps 的第一课，不是怎么写安全代码，而是：不要把“临时”变成“永久”，不要让“便利”压倒“边界”。

Code itself

代码本身

Code init - framework/template oriented

代码初始化-框架/模板导向

作为开发人员, 接下来应该是 IDE, 然后创建项目, 初始化版本控制, (引入模版) 并且创建代码仓库.

虽然现代 IDE（如 VS Code、JetBrains 系列）本身相对安全，但攻击者仍可通过：

• 传播植入后门的破解版 IDE

• 污染启动脚本（如 .vscode/tasks.json、.idea/runConfigurations）

• 利用插件供应链（恶意 VSIX / JetBrains 插件）

不过这类攻击成本高、目标分散，真正的主战场，始终在业务代码本身。

框架与模板

在这里就引入了模版和框架本身的问题. 当然模板和框架本身的目的是用来更加方便的创建其他的项目, 然后运用到业务中的.

项目初始化常依赖成熟框架（Spring Boot、Django、Express）或企业模板。
这些模板本意是加速开发，但如果：

• 使用了过时版本（含已知 CVE）

• 模板中默认开启调试模式

• 集成了不安全的中间件

光光一个初始的框架基本不足以引起毁灭性的问题. 其利用也是相当困难的. 如果真的引起了, 只能说恭喜, 咱们安全员又有饭吃了, 这必将是一个威胁大量系统的漏洞.

真正引入漏洞的位置应该是在代码编写的过程中, 开发人员在不经意间, 引入一些 BUG 或者 更为严重的漏洞.

💥 经典案例：Java MyBatis 的 ${} vs #{}

• #{key} → 参数化查询（安全）

• ${key} → 字符串拼接（直接导致 SQL 注入）

这种错误看似低级，却在赶工、交接、复制粘贴中高频出现。
安全不是“有没有用框架”，而是“怎么用框架”。

✅ 建议：在 CI 流程中加入 SAST 工具（如 Semgrep、SonarQube），自动检测此类模式。

当然, 反过来思考, 如果我们想要测试一个框架的问题或者漏洞, 我们其实应该在项目开发的早期代码中进行寻找. 前期为了便于开发测试, 不会引入过多的内容, 更多是关注核心业务逻辑. 代码在安全上做的努力往往并不是非常的严密. 不过可测试的点位也不是很多. 当搭好了一个程序的基本的结构和一部分内容的时候, 测有可测, 也很容易发现框架实现上的问题和 BUG. 开发或许并不是很注意, 但是很容易成为安全人员入手的点.

Hacking API - weak authorization

黑客API-弱授权

现代应用多采用 前端（Vue/React） + 后端 API 架构。这种解耦提升了开发效率，却也带来了API 鉴权薄弱的普遍问题。

🔐 弱鉴权的典型表现：

• 有登录校验，无权限校验
  → 普通用户可访问 /admin/deleteUser

• 水平越权
  → 用户 A 可通过修改 user_id=123 访问用户 B 的数据

• 垂直越权
  → 普通员工调用 HR 系统的薪资接口

根本原因？

API 不像网页 URL 那样容易被人工遍历，隐蔽性强，测试覆盖不足。

而开发者的心理往往是：

“前端没暴露这个按钮，后端就不用校验了吧？”——殊不知，攻击者根本不走前端。

这里的弱鉴权是指, 其实是有鉴权但是鉴权逻辑不完善, 比如说 校验了是否为登陆用户, 但是没有对权限做良好分离 (可以导致垂直或者水平越权), 这种垂直越权在管理的接口中可以很容易被发现.

API Exposure

API暴露

当然 凡事是有例外的, 比如:

• 不完备的前端代码混淆或泄漏 尤其是 Webpack:// sourcemap 导致的 意外泄漏.

• 对外暴露了 Swagger api document 或者其他可能导致泄漏的 api 文档和 调试工具(被 Hacked YAPI (这种存在 RCE 可能)等).

• 被入侵的开发人员之间的通讯工具, 比如 项目管理评论等.

• 开启了 Debug Mode 导致的接口意外暴露, 这些往往会伴随着更为严重的部分代码泄漏,(这部分代码泄漏可以参考本章节上面一部分.) 比如 Django Debug mode.

• 报错提示. (服务器对于有些请求 不存在的时候返回 404 存在的时候 参数不足或者方法不对是 40X 或者 50X 在提示信息中可能存在参数的名称或者类型, 甚至是错误的暴露了栈)

这里说说发现.

根据上面两点(Debug+报错) 我们可以用上一种特殊的技巧. 我称之为 反向调试 某些开启 Debug mode 的 Django 程序, 可以通过控制报错的位置, 定制对应的 payload 使得可以控制 Python 在不同的地方进行报错, 使得 Debug 更多地暴露出运行的代码. 调试是为了确定 Bug 在哪里, 而我们是反过来通过 Bug 来进行源码的暴露.

Weakness

弱点

鉴权实现缺陷

常见的操作有: HACK APIs In 2021

说回 API 鉴权. API 因为是公开对外让 Client 进行调用的东西, 而对应的来源并不是很能确定. 常常可能有多种不同的 Client (Client 也可以是 Browser). 确定具体的调用对象难度就非常的高, 通常采用多创建一个 Token 来对本 Server 单独验证.

这里具体的方案应该按照实际情况而定.

很多开发为了方便测试功能或者纯纯觉得没关系无所谓(警惕恶意摆烂)

很多时候会忽略这里相关的鉴权, 可能是交给 Auth 的(抽象出来的 Server 中间件) 或者干脆不鉴权了.

这里会导致很严重的 未授权访问 + 信息泄露 或者 注入问题 , 当然更为常见的是导致水平越权和垂直越权(通常在 3 个以上的权限级别的情况下就很容易出现这种问题. RBAC 不在讨论范围内.)

脆弱的鉴权还有一个 问题是不正确的验证实现

这里上面 SSO 不算是这种问题 因为设计出来本来就是这样的

在我举一个 OAuth 的例子 在验证的时候 Redirect 没有严格限制 也没有参数：

🌐 OAuth 跳转劫持（Open Redirect + Token 泄露）

• 若 redirect_uri 未严格校验（如允许 https://attacker.com）

• 攻击者可诱导用户授权，截获 Access Token

• 进而冒充用户调用 API，甚至伪装成“可信第三方服务”

📌 尤其危险的是：某些“强制使用”的打卡、认证类服务，一旦被滥用，可实现大规模账号接管。

⚠️ 其他常见错误：

• Token 未绑定 IP / User-Agent

• JWT 未验证签名（alg: none 攻击）

• RBAC 权限模型未落地，仅靠前端隐藏按钮

比如允许你任意跳转 这样我们可以写入一个我们自己可控的服务 然后获取到平台的 Token. 接下来我们可以对用户伪装成第三方服务提供一些服务等 伪装用户从可信任平台获取用户信息 伪装用户请求第三方服务

尤其是有些服务是你必须完成的 ”打卡“ 服务, 这种滥用往往会导致致命的效果.