你的网站部署后会遭遇哪些攻击？专业测试工程师应该如何应对

# 你的网站部署后会遭遇哪些攻击？专业测试工程师应该如何应对

网站一旦部署到公网，就不是“功能点完了就万事大吉”。页面、接口、上传入口都摆在不可信网络面前，谁都能来访问、试探，甚至故意捣乱。安全测试不是教人去攻击网站，而是在授权的测试环境里先替团队多想一步：要是真有人这么干，系统扛不扛得住？

很多项目上线前，大家最关心的是“页面有没有白屏”“下单能不能成功”。这当然没错，但线上出事故时，往往不是正常用户按正常流程点出来的：有人把请求参数改了，有人拿着另一个账号的 ID 去试，有人反复点验证码接口。测试工程师多问一句、多挡一次，开发和运营后面就能少熬很多夜。

一、先看全貌：攻击者想得到什么

公网攻击看起来很多，目标其实集中在五件事：

攻击目标	攻击者想造成的结果
让服务不可用	网站变慢、超时或完全无法访问
偷走或篡改数据	读取用户资料、订单、合同、数据库内容
冒充用户	接管账号、盗用登录状态、绕过身份校验
越过业务规则	低价下单、重复领券、跳过支付或审批
找到部署缺口	利用开放端口、错误配置或过期组件进入系统

测试人员要做的，就是把每一个功能换成攻击者视角来问：这个请求能不能被伪造？参数能不能被改？换一个用户或角色还能不能成功？重复调用会怎样？

二、常见攻击与测试应对

1. DDoS：用大量请求拖垮网站

攻击方式：大量设备同时访问网站，耗尽带宽、连接数、CPU 或数据库资源，正常用户无法访问。

通俗理解：平时一间店只接待几十位顾客，突然有成千上万人同时挤进门、反复问同一个问题，真正想买东西的人就进不来了。攻击者不一定要攻破系统，只要让系统忙到无法服务正常用户，目的就达到了。

你可以把它理解成“有人故意把客服电话打爆”。客服没坏，电话也没坏，但真正有急事的人就是打不进来。网站也是一样，很多时候最先倒下的不是首页，而是验证码、搜索、导出这种看上去不起眼、背后却很费资源的功能。

测试怎么做：在隔离压测环境验证首页、登录、搜索、下单、验证码、导出等关键接口的并发能力；特别关注一次请求就会触发昂贵操作的接口，如发短信、生成报表、大文件处理。

测试时不要只盯着“接口报没报错”，还应记录响应时间、成功率、CPU/内存、数据库连接数和队列积压。可以逐步增加并发，观察系统在压力升高时是平稳变慢、主动限流，还是直接超时、雪崩。验证码发送、密码找回、OCR 解析等接口还要验证：同一账号、IP 或设备短时间内连续请求时，是否会被限制，是否会留下告警记录。

系统应对：CDN/WAF、限流、验证码、IP 或账号频控、缓存、服务降级与告警。测试不能只看“压到多少并发”，还要看触发限流后是否保护住核心服务、是否给正常用户合理提示。

常见误区：把压测直接打到生产环境，或只测首页而不测短信、导出、搜索等高消耗接口。前者可能影响真实用户，后者则容易漏掉最先被滥用的入口。

2. SQL 注入：把输入变成数据库指令

攻击方式：攻击者在登录、搜索、筛选等输入点提交异常内容，诱使后端把它当作 SQL 的一部分执行。

通俗理解：用户本来应该输入“要查什么”，但程序没有把这句话和数据库命令分开，于是用户输入被误当成了“让数据库做什么”。问题的本质不是某个符号，而是程序把外部输入直接拼进了查询语句。

这类问题最容易发生在“图省事”的地方。比如开发觉得搜索框就查个关键词、后台筛选就传个 ID，于是少写了一层安全处理。平时大家都老老实实输入姓名和订单号，根本看不出来；可一旦有人故意提交异常内容，系统就可能把家底都亮出来。

测试怎么做：对所有用户可控的输入及查询参数做异常输入测试，观察是否出现数据库报错、登录绕过或异常数据返回；重点覆盖搜索、排序、筛选、ID 参数和后台接口。

除了页面输入框，也要测 URL 参数、JSON 请求体、分页条件、排序字段和历史接口。测试结果至少应满足三点：异常输入不会返回数据库结构或堆栈；不会影响其他数据；接口仍给出统一、可理解的错误响应。发现疑似问题时，记录接口、参数、返回现象和影响范围，由开发确认查询是否采用参数化方式。

系统应对：参数化 SQL 或安全 ORM、服务端输入校验、最小数据库权限、统一错误响应。只靠“过滤特殊字符”并不可靠。

常见误区：认为“前端已经限制了输入格式”就够了。攻击者可以绕过页面直接调用接口，所以真正的校验和参数化处理必须在服务端完成。

3. XSS：让其他用户的浏览器执行恶意脚本

攻击方式：攻击者把恶意内容放进评论、昵称、富文本、搜索词或 URL；其他用户打开页面时，浏览器错误地把内容当作脚本执行。

通俗理解：网站本来要展示一段文字，却把它当成了浏览器要执行的指令。受影响的往往不是提交内容的攻击者本人，而是之后打开这条评论、工单或搜索结果的普通用户。

这事有点像小区公告栏：本来是贴通知的，结果有人夹了一张“谁看谁替我办事”的纸条。更麻烦的是，管理员后台也常常会看这些评论、工单和反馈，所以别以为“只有普通用户页面才要测”，后台展示页反而经常是容易漏掉的地方。

测试怎么做：检查用户输入在页面上是“文本显示”还是“作为 HTML 渲染”；分别覆盖保存后再访问的内容、搜索结果页和前端读取 URL 的场景。

可以把测试分成三问：内容提交后再次打开是否安全（存储型）；通过搜索或链接带入页面时是否安全（反射型）；前端脚本读取地址栏或页面内容后是否安全（DOM 型）。还要检查管理员后台、通知中心、邮件预览等容易被忽略的展示页面，因为这些页面常会直接展示来自用户的内容。

系统应对：默认转义输出；富文本使用白名单净化；Cookie 设置 HttpOnly、Secure、合理的 SameSite；逐步配置 CSP 限制脚本来源。

常见误区：只在提交页面做过滤，却不检查最终展示位置。XSS 是否成立，关键取决于内容最终以何种方式被浏览器渲染。

4. CSRF：借用已登录用户的身份发请求

攻击方式：用户已登录目标网站时，攻击者诱导其打开另一个页面；浏览器自动携带登录 Cookie，导致转账、改密码等请求在用户不知情时被提交。

通俗理解：用户的浏览器像带着一张“已登录通行证”。攻击者无法直接拿走通行证，却可能诱导浏览器替他把请求送到目标网站。网站若只看到 Cookie、没有继续确认请求来源，就可能误以为这真是用户本人发起的操作。

说白了，就是你已经刷脸进了小区，坏人不抢你的门禁卡，而是想办法让你“顺手”替他把门打开。很多人听到 CSRF 觉得名字拗口，其实只要记住一句话：凡是会改数据、花钱、改账号的请求，都不能只凭“浏览器带来了 Cookie”就放行。

测试怎么做：对修改资料、提交订单、支付、绑定账号等 Cookie 会话的敏感操作，验证请求是否必须带有系统生成的校验信息，跨站来源是否会被拒绝。

测试时尤其要区分“查看数据”和“改变数据”。对改密码、绑定手机号、转账、删除、下单等改变状态的操作，检查请求缺少校验 Token、校验 Token 过期或请求来自非本站页面时是否被拒绝；也要确认拒绝后不会产生部分成功、重复扣费等副作用。

系统应对：CSRF Token、SameSite Cookie、Origin/Referer 校验，以及高风险操作的二次确认或二次验证。

常见误区：以为只要使用 HTTPS 就不会有 CSRF。HTTPS 保护传输过程不被窃听或篡改，但不会阻止浏览器自动携带已有 Cookie；是否抵御 CSRF，仍取决于服务端对请求来源和校验信息的判断。

5. 身份认证攻击：猜密码、撞库、盗用 Token

攻击方式：攻击者使用弱密码、泄露密码库或大量尝试登录；也可能利用未过期、泄露或权限过大的 Token 冒充用户。

测试怎么做：验证登录失败次数限制、验证码或 MFA 的触发、改密码后的旧会话失效、Token 的过期与刷新，以及 Token 是否会出现在 URL、日志或错误信息中。

系统应对：强密码策略、登录限速、MFA、短期 Token、最小权限、敏感操作二次校验与异常登录告警。

6. 越权：不该看的数据看到了，不该做的操作做了

攻击方式：

• 水平越权：用户 A 修改订单、合同或文件的 ID，访问到用户 B 的数据。
• 垂直越权：普通用户直接调用管理员接口，仍能删除用户或修改配置。

测试怎么做：准备至少两个同级用户和一个低权限角色；对列表、详情、下载、编辑、删除、导出、批量操作逐项验证。不要只测页面按钮，要直接验证接口。

系统应对：后端同时校验“这个用户有没有该功能权限”和“这个用户能不能访问这个对象”。前端隐藏按钮只是体验设计，不是安全措施。

7. 文件上传攻击：把上传入口变成服务器入口

攻击方式：攻击者上传伪装文件、超大文件、畸形图片或恶意文档，试图执行代码、耗尽资源或攻击解析组件。

测试怎么做：验证扩展名、实际文件类型、大小、数量、压缩包和异常文件是否由服务端校验；验证上传文件能否被直接执行，下载链接是否绕过权限。

系统应对：服务端类型识别、大小/数量限制、病毒扫描或沙箱解析、随机文件名、独立对象存储、最小访问权限和禁止执行。

8. API 与业务逻辑攻击：合法接口被不合法地使用

攻击方式：攻击者篡改价格、数量、状态、对象 ID 等参数；重复发送支付或领券请求；跳过“创建订单 → 支付 → 发货”中的前置步骤，直接调用后续接口。

测试怎么做：对每个关键接口做三类验证：

• 参数篡改：价格、金额、状态、归属、分页大小被改后，后端是否拒绝或重新计算。
• 重放调用：同一请求重复、乱序或过期提交后，是否只执行一次。
• 流程跳步：跳过支付、审核、确认等前置状态时，后续接口是否被拦截。

系统应对：后端重新计算关键金额、对象级授权、幂等键、状态机校验、限流、风控规则和完整审计日志。OWASP API Security Top 10 将对象级授权、认证、资源消耗和敏感业务流列为重点风险，可作为 API 测试分类参考：OWASP API Security Top 10。

9. 敏感信息泄露：没有“攻破”，数据已经暴露

攻击方式：接口返回身份证号、手机号、密码哈希、内部路径或密钥；错误页泄露堆栈；日志和导出文件记录过多敏感信息。

测试怎么做：检查页面、接口响应、下载文件、浏览器存储、日志和错误页面；验证不同角色看到的字段是否不同，分页接口是否一次返回过量数据。

系统应对：数据最小化、字段脱敏、分级授权、统一错误页、密钥不入代码和日志、导出权限与水印/审计。

10. 服务器、配置和组件漏洞：应用之外的入口

攻击方式：SSH 弱密码、数据库或 Redis 暴露公网、调试接口未关闭、对象存储公开可读、过期的 Nginx/Tomcat/框架组件等，都可能绕过应用本身的防护。

测试怎么做：在授权范围内核对公网暴露服务、调试页面、错误信息、HTTPS 配置、对象存储访问策略和依赖漏洞扫描结果；发布前确认高危漏洞是否已修复或隔离。

系统应对：最小化开放端口、及时打补丁、关闭调试能力、密钥集中管理、依赖扫描、网络隔离和持续监控。

三、测试时应该先测什么

对绝大多数有账号和 API 的公网业务系统，建议按以下顺序投入测试资源：

优先级	首先验证的风险	原因
★★★★★	越权、身份认证、API 参数篡改	直接导致账户接管、数据泄露或资金/业务损失
★★★★★	SQL 注入、文件上传、敏感信息泄露	可能造成数据库、服务器或隐私数据暴露
★★★★	XSS、CSRF、重放攻击	影响已登录用户和关键操作完整性
★★★	配置、组件和服务器暴露	需要与开发、运维共同纳入发布检查
★★★	DDoS 与资源滥用	需要在专门环境验证容量、防护和降级能力

四、测试边界：在授权范围内发现问题

安全测试必须使用获授权的测试环境、测试账号和脱敏数据。不要对生产系统做未批准的扫描、压测或漏洞验证。发现问题后，记录受影响接口、复现条件、风险等级、修复建议和回归结果，直到关闭。

安全测试不是非得抓到一个“大漏洞”才算有价值。很多时候，真正靠谱的结果只是：有人改了参数，系统没上当；有人越过页面直接调接口，后端没放行；有人重复提交，业务没有多扣一分钱。上线以后少一次半夜告警、少一通用户投诉，这就是测试把风险挡在门外的意义。

五、上线前 10 分钟：安全自查清单

前面讲的是攻击原理和测试方法。真正临近发布时，测试工程师可以用下面这份清单快速做最后一次核对。它不能替代完整的安全测试，但能减少“明明知道却忘了检查”的低级遗漏。

尤其是发布前最后半小时，群里消息多、需求又容易临时改，最怕的就是“这个应该没问题吧”。与其靠感觉，不如把最容易出事的几件事老老实实勾一遍：账号、权限、金额、上传、敏感数据。十分钟花得值不值，要看它有没有帮你拦住一次线上事故。

账号与权限

• [ ] 连续登录失败后，账号或 IP 是否会被限速、拦截或要求验证码？
• [ ] Token、Cookie、重置链接是否不会出现在 URL、前端日志或错误信息中？
• [ ] 普通用户改掉对象 ID 后，是否仍无法查看、下载或修改其他人的数据？
• [ ] 普通用户直接调用管理员、审核、导出等接口时，后端是否明确拒绝？

接口与业务流程

• [ ] 金额、价格、优惠、审批状态等关键字段，是否由后端重新计算或校验？
• [ ] 重复提交、乱序提交、过期提交时，订单、支付、领券、审批等操作是否只会生效一次？
• [ ] 验证码、导出、搜索、上传等高消耗接口，是否具有频率和数量限制？

数据与部署

• [ ] 页面、接口、导出、日志和错误页中，是否意外返回了手机号、身份证号、密钥、堆栈或内部路径？
• [ ] 上传文件是否完成服务端类型与大小校验，且不能被直接执行或越权下载？
• [ ] 调试接口、测试账号、默认密码和不必要的公网端口是否已关闭或收紧？
• [ ] 高风险问题是否已完成回归验证，并保留必要的审计日志与告警？

如果这些问题中有任意一项不能回答“已验证”，就不应简单写成“安全通过”。把未确认项列为上线风险、明确责任人和关闭条件，才是专业测试工程师对发布负责的方式。