绕过OA前端限制，强制替换已提交单据的PDF附件

📝 背景与痛点
在日常办公中，我们经常遇到这样的尴尬：OA系统中的表单已经“提交”或“归档”，状态被锁定为只读（Readonly）。此时如果发现附件（PDF/Word）有误，常规操作只能是“撤回 -> 修改 -> 重新提交”，流程繁琐且可能留痕。

本次实战的目标是：在不改变单据状态（保持已提交/已审核）的前提下，直接替换服务器上的PDF附件。

🚧 遇到的阻碍
1、前端限制：修改URL参数（reportLook -> reportEdit）无效，页面源码中根本不存在“保存”按钮，且输入框被禁用。
2、接口拦截：尝试通过浏览器控制台（Console）发送修改请求，遭遇 401 认证失败，因为跨域或缺少关键凭证。
3、文件存储：文件存储于云对象存储（COS），链接为随机字符，无法直接覆盖。

🛡️ 核心思路与技术原理
核心逻辑：**“前后端分离”带来的漏洞利用。
现在的系统通常将“界面展示”与“数据存储”分离。只要后端API接口没有严格的业务逻辑校验（例如：只允许草稿状态修改），我们就可以通过构造数据包，直接修改数据库内容。
关键点分析：

• 前端（浏览器）：只是个“遥控器”，坏了/被锁了没关系。
• 后端（API）：是“机器本体”，只要给它正确的指令（JSON），它就会执行。
• 文件（COS）：文件链接是“身份证号”，只要把数据库里的“身份证号”换掉，展示的内容就变了。

🚀 解决方案：中间人重放攻击（实战步骤）
本次成功的关键在于使用了 HTTP Debugger Pro 这类抓包工具，实现了对HTTPS请求的拦截与修改。

🔑 第一步：寻找“万能接口”
通过浏览器开发者工具抓包，定位到核心编辑接口：
接口地址：PUT /report/info/edit
请求体（Body）：标准的JSON格式，包含了单据的所有信息。

📂 第二步：准备“替身”文件
由于系统使用腾讯云COS存储，直接修改本地文件无效。
操作：在系统其他地方上传一个新的正确PDF，或者获取一个合法的COS直链。
关键参数：拿到新的 fileUrl（随机字符链接）和 fileName。
⚙️ 第三步：拦截与修改（决胜点）

这是最关键的一步，也是绕过前端限制的核心。
1、抓包：在HTTP Debugger Pro中捕获原本的 PUT /report/info/edit 请求。
2、修改：在请求发送给服务器之前，拦截它。修改JSON中的附件字段：
json：
{
"id": "123456",
"accessory": "1999999",
"xxoaFileList": [
{
"id": 1999999,
"fileName": "新文件名.pdf",
"fileUrl": "https://xxoa-pro-.../新随机字符.pdf",
"fileExt": ".pdf"
}
]
}
3、重放：将修改后的请求重新提交给服务器。

✅ 第四步：服务端响应
服务器收到请求后，执行了简单的“更新”操作：
结果：{code: 200, msg: '操作成功'}
效果：数据库中的附件链接被更新，刷新页面后，PDF已变为新文件，且单据状态依然保持“已提交”。

💡 经验总结与避坑指南
1、工具选择：浏览器控制台（Fetch）容易受CORS跨域限制；抓包工具（HTTP Debugger/Fiddler） 更底层，成功率更高。
2、状态保持：修改数据时，一定要带上关键的业务状态字段（如 approveStatus: 1），防止服务器误以为你要“撤回”单据。
3、ID保留：替换附件时，尽量保留原有的 fileId（如 1999999），这样系统会执行“更新”而非“新增”，避免出现两个附件。
4、风险提示：此方法仅限于技术探索或紧急修复。操作前最好备份原始数据，防止误操作导致数据丢失。

🧩 说明
这套方法不仅适用于PDF替换，同样适用于：

• 修改已归档单据的金额、日期等文本字段。
• 修复因系统Bug导致的错误数据。
• 任何基于Web API的前后端分离系统的数据修正。