凌晨，安全设备连续弹出“SQL 注入”“命令执行”“异常文件上传”告警。运维人员打开网站，页面正常，登录正常，服务器资源也没有明显异常，于是判断：设备已经拦截，业务没有受到影响。
这个判断可能成立，也可能错过了一次真正的入侵。
Web 攻击最容易让人误判的地方，是它经常混在正常业务请求里。攻击者可能没有打满带宽，没有让服务器宕机，甚至没有触发一次明显的报错，只是利用一个缺少权限校验的接口，逐页下载了原本不属于自己的数据。页面可用，只能说明部分服务还能响应，不能证明数据、账号和服务器仍然安全。
理解 Web 攻击，需要把网络请求、应用代码、身份权限和业务行为放到一起看。
攻击者为什么总盯着 Web 系统
今天的 Web 系统，早已超出“一个网站”的范围。办公门户、运维平台、统一身份认证、文件交换、资产管理、业务 API，以及服务器和安全设备的管理页面，都可能通过 HTTP 或 HTTPS 提供服务。一个看似简单的页面，后面可能连接着数据库、文件存储、消息队列、内部接口和其他业务系统。
这些连接让业务更方便，也让一个入口的缺陷有机会影响更多资源。
防火墙允许用户访问 HTTPS，解决的是这条连接能否建立；应用还必须判断，这次请求是否合理、当前用户是否有权操作，以及输入内容是否会改变程序原本的执行方式。HTTPS 保护传输过程，并不会自动修复应用中的注入、越权或业务逻辑漏洞。
OWASP 的 Web 应用安全风险框架覆盖访问控制失效、注入、安全配置错误等多个方面。它提醒我们，Web 安全既涉及代码缺陷，也涉及权限设计、配置和运行管理。
这些问题背后，经常能找到几种相似的原因：程序把外部输入当作指令执行，把“已经登录”当作“拥有权限”，把用户提交的文件当作可信内容，或者把“来自服务器的请求”当作可靠请求。业务开发完成了功能，却没有完整约束功能被滥用的方式。
SQL 注入：用户输入改变了数据库查询的含义
搜索、登录、筛选和报表查询，都可能接收用户输入。如果程序直接把输入拼接进数据库语句，攻击者就可能改变查询逻辑，使数据库执行开发者没有预期的操作。
其后果可能包括读取敏感数据、绕过部分业务判断、篡改记录或破坏数据。能否进一步影响服务器，取决于数据库功能、账号权限和部署环境，不能看到一条 SQL 注入告警就直接认定“服务器已被控制”。
防护重点是参数化查询，让查询结构与输入数据分离；对无法使用绑定参数的表名、排序字段等，采用明确的允许列表。数据库账号还应遵循最小权限原则。使用 ORM 并不意味着天然安全，直接拼接原生查询仍可能重新引入漏洞。
XSS 与 CSRF：两种发生在用户浏览器周围的攻击
跨站脚本攻击，也就是 XSS，通常源于应用把不可信内容放进页面时，没有进行适合当前上下文的安全处理。攻击代码可能进入评论、工单描述、富文本、查询结果或前端动态渲染的内容，在其他用户浏览页面时执行。
XSS 可能篡改页面、诱导输入敏感信息，或借用用户当前会话执行操作。即使 Cookie 设置了 HttpOnly，脚本无法直接读取该 Cookie，也不代表攻击失去危害：它仍可能在用户浏览器中发起具有当前用户身份的请求。防护要结合上下文输出编码、安全的前端接口和必要的富文本净化，内容安全策略 CSP 则作为补充防线。
跨站请求伪造，也就是 CSRF，利用的则是浏览器可能自动携带登录凭据的特点。用户已经登录某系统，随后访问了攻击者控制的页面，如果系统缺少有效防护，就可能接受并执行未经用户真实意愿确认的操作。
防范 CSRF，需要结合框架提供的防护机制、服务端校验的 CSRF Token、适当的 SameSite Cookie 策略和来源校验。修改权限、调整账号信息等关键操作，还应要求再次验证身份。XSS 与 CSRF 的机制不同，不能用一种防护措施替代另一种。
越权访问：没有异常字符，也能造成严重泄露
很多人把 Web 攻击想象成一串复杂的攻击代码，但越权请求可能看起来完全正常。
例如，用户只能查看自己的申请单，接口却只根据请求中的单据编号返回数据，没有核验单据归属。攻击者修改编号，就可能读取其他用户的记录。这是横向越权；普通用户调用管理员功能，则属于纵向越权。
同类问题还可能发生在附件下载、报表导出、组织切换和多租户数据访问中。隐藏按钮只能改变前端展示，不能代替后端授权；使用难猜的编号，也不能代替权限检查。服务器必须对每次请求验证操作权限和资源归属，并默认拒绝未经明确授权的访问。
这也是传统特征检测的难点：一个已经登录的用户，发送了一条格式正确的请求，仍然可能正在实施攻击。
文件上传与路径穿越：附件和下载功能也可能成为入口
文件上传风险常见于附件、头像、导入文件和在线预览。问题可能出现在扩展名检查、内容解析、保存路径、访问权限，以及上传文件是否会被当作程序执行等环节。
WebShell 是其中一种需要警惕的结果：攻击者在满足特定执行条件时，通过服务器上的恶意脚本获得控制能力。但“上传成功”不等于“代码执行成功”，必须继续确认文件实际落点、解析方式、后续访问和主机行为。
上传防护需要组合实施：允许的文件类型、大小与内容检查、服务端生成文件名、隔离存储、禁止上传目录执行程序，以及必要的恶意内容检测。客户端提供的文件类型声明不能单独作为可信依据。
下载和预览功能则要关注路径穿越风险。如果程序允许外部输入影响实际文件路径，又缺少严格的范围约束，就可能访问预期目录之外的文件。设计上应尽量使用服务端维护的文件标识映射，避免让用户直接决定存储路径。
SSRF：让服务器替攻击者发出请求
服务端请求伪造，也就是 SSRF，经常与“输入网址导入”“远程图片抓取”“链接预览”等功能有关。应用接收用户提供的地址，再由服务器发起访问，如果没有约束目标范围，攻击者就可能利用服务器访问不应暴露的内部资源。
它的危险在于，服务器可能拥有普通用户没有的网络可达性。在特定部署环境下，还可能触及云元数据服务或内部管理接口。
防范不能只检查输入是否以某个字符串开头，而要控制允许访问的协议、目标和端口，并考虑域名解析、重定向和实际连接目标的变化。网络侧还应限制应用服务器不必要的出站访问。
命令执行、反序列化与组件漏洞：从应用入口走向服务器控制
当应用把不可信输入交给系统命令、模板引擎或其他具有执行能力的组件时，漏洞可能从“数据被读取”升级为“程序被执行”。不安全的反序列化也可能造成对象状态被操纵，严重时引发远程代码执行，具体影响取决于使用的组件和可利用条件。
这类风险的治理需要覆盖自研代码、框架、中间件、插件和依赖。减少不必要的执行能力，更新受影响组件，收紧服务账号权限，并隔离应用与核心管理资源，才能降低漏洞被利用后的影响范围。
同样需要关注暴露的调试页面、遗留测试接口和错误配置。测试环境可以正常访问，不代表它已经具备生产环境所需的安全约束。
账号攻击与业务逻辑滥用：绕过规则，有时比绕过代码更容易
弱口令猜测、撞库、密码喷洒，以及密码找回和会话管理缺陷，都可能导致账号被接管。识别时不能只统计某个 IP 的失败次数，还要观察账号、设备、来源分布和成功后的行为。多因素认证、合理的尝试限制、安全的找回流程和敏感操作再次认证，应共同发挥作用。
业务逻辑攻击则可能利用重复提交、状态跳转、并发竞争和校验位置错误，让系统接受本不该成立的操作。例如，审批状态在界面上受到限制，接口却没有验证；同一申请本应只执行一次，重复调用却产生多次结果。此时请求参数可能完全合法，判断依据必须回到业务规则本身。
应用层拒绝服务也是类似思路：攻击者未必需要制造巨大的流量，只要持续调用高成本查询、复杂报表或大文件处理接口，就可能耗尽线程、连接池、内存或后端资源。防护要控制请求成本、并发和处理时长，并针对具体接口设置限制，而不只是统一限制访问次数。
收到告警后，怎样判断攻击有没有成功
首先要区分三个事实：安全设备识别到了攻击特征，请求确实到达了应用，以及应用产生了攻击者预期的结果。这三件事不能画等号。
WAF 显示“已拦截”，需要确认拦截发生在哪里，源站是否还有其他入口，以及此前是否出现过未被阻断的相似请求。HTTP 200 只能说明请求获得了相应的 HTTP 响应，不能单独证明攻击成功；HTTP 403 或 500 也不能单独证明没有发生数据访问或其他副作用。
实际研判可以沿着下面这条证据链推进：
调查时，应把“未发现成功证据”和“确认攻击失败”分开表述。日志没有采集、已经覆盖，或者关键字段缺失，都可能让调查无法得出确定结论。
日志建设也要提前完成。访问日志之外，还需要登录、授权失败、权限变更、敏感数据访问和关键业务操作等应用审计。各系统应统一时间，使用能够关联请求的标识，并保护日志不被篡改。不要为了方便排查，把密码、完整访问令牌或其他敏感凭据写进日志。
一个更接近实战的判断过程
假设某设备报告“异常文件上传”。以下是一个示意场景，并非真实事件。
如果只查到规则命中，应用没有接收到该请求，那么可以支持“该次请求在当前入口被阻断”的结论。如果源站记录了上传请求，还需要确认应用是否接收文件、文件保存在哪里，以及是否进入解析流程。
如果进一步发现上传位置出现异常文件，相关请求之后 Web 进程又创建了不符合业务基线的子进程，并产生可疑外联，就应升级事件等级，排查服务器是否失陷。此时仅删除文件或封禁来源 IP，已经不足以完成处置。
判断的关键不是某个特征有多“像攻击”，而是不同来源的证据能否在时间、对象和行为上相互印证。同时，也要核对这些变化是否来自授权发布、运维操作或安全测试，减少误判。
发现攻击后，处置要同时考虑止损与证据
攻击仍在持续、敏感数据正在外流时，首先要控制影响：限制受影响接口、撤销可疑会话、隔离受影响实例，或收紧相关网络访问。在止损的同时，尽可能保全日志、异常文件、进程和连接信息，记录采取措施的时间及操作人员。不能为了等待完整取证而放任攻击持续，也不宜在没有评估的情况下直接清空目录、重启全部服务，破坏调查线索。
随后要确认影响范围。除了入口主机，还应检查其能够访问的数据库、共享存储、接口和管理资源；核查异常账号、权限变更、计划任务、部署产物和凭据使用情况。如果无法再信任主机完整性，应考虑从可信镜像或介质重建，而不是仅删除可疑文件后继续运行。
修复则要回到根因。补丁、代码修复、权限调整和配置收紧，应针对已经确认的问题。WAF 临时规则可以作为缓解措施，但不能替代根因修复。可能泄露的密码、密钥和令牌，需要结合系统隔离及恢复计划完成轮换，避免新凭据再次暴露。
恢复上线前，还要验证业务功能、原漏洞修复效果、同类接口风险和日志监控能力。恢复后持续观察相似行为，并把事件中暴露出的缺口转成明确的整改任务。
防范 Web 攻击，最终要落实到每一次发布
日常治理可以围绕几个具体动作展开：弄清有哪些域名、接口和管理入口；明确每个系统的责任人、组件版本和数据范围；在开发阶段落实输入处理、权限校验和业务状态约束；在部署阶段收紧权限、网络和执行能力；在运行阶段持续核查补丁、账号和异常行为。
安全测试也应贴近业务。除了扫描已知漏洞，还要验证“普通用户能不能读取别人的数据”“退出登录后原会话是否仍然有效”“重复提交是否产生重复操作”“附件是否可能被越权下载”。这些问题往往比扫描报告中的一个风险分数更接近真实损失。
一次 Web 告警是否值得紧急响应，不能只看它的名称，也不能只看网站还能不能打开。真正需要回答的是：请求到了哪里，程序做了什么，哪些权限被使用，哪些数据受到影响，以及攻击者是否仍然保有访问能力。
当这些问题能够用证据回答，安全设备的告警才真正进入了可判断、可处置、可复核的运维流程。