DVWA靶场 生产落地案例

五、生产落地案例

案例一：研发团队的新人安全培训环境。背景是团队每年有校招新人，讲完 Web 安全理论课后没有可动手的环境，新人把「参数化查询」当口号背，写代码时照样拼接。做法是：在内网隔离的一台测试机上用 Docker 起 DVWA，只在办公网段开放，公网入口全部关闭；培训分三场，第一场在 Low 档复现四类漏洞，第二场切 Medium/High 讨论绕过思路，第三场直接打开 Impossible 档的 PHP 源码逐行讲防御。关键配置上，除了 DVWA 自身，还额外做了一件事：把靶场的访问日志接到内部日志平台，让新人看到自己打的 payload 被完整记录下来——顺带讲清「留痕」是授权测试的一部分。效果是新人提交代码里拼接 SQL 的比例明显下降，代码评审时能自己指认出问题行。踩过的坑有三个：一是靶场一度被映射到带公网 IP 的机器上，被外部扫描器探到并尝试爆破，发现后立刻下线并检查了日志；二是宿主机 80 端口已跑着内部系统，容器起不来，改用 8080 映射；三是Security Level 存在 session 里，有人点了 Reset DB 以为会回到 Low，结果档位没变，换了浏览器才对上。

案例二：上线前的自测清单演练。背景是一个内部管理系统要做等保测评前的自查，团队没有专职安全人员。做法是：先用 DVWA 把「注入、跨站、上传、越权、重定向」五类问题过一遍，形成一份对照清单，再拿这份清单去逐条检查自己的系统——每条都要求写出「我这边对应的接口是哪个、当前写法是什么、是否命中」。关键点是把 DVWA 的 Impossible 档源码当作「正确写法参考」，例如用它演示的参数化查询 + 白名单校验来对照自己的 DAO 层。效果是自查阶段就发现了几处越权接口（前端藏了按钮但后端没校验），在测评前修完。坑在于：一度有人想直接把 DVWA 装到预发环境「顺手测」，这等于把一堆已知漏洞放进接近生产的网络位置，被明确禁止——靶场必须与业务网络隔离。

漏洞分级与修复闭环：演练或自测出来的问题，按影响面分级——能直接拿到数据或执行命令的算高危，需先修；能造成信息泄露但需要前置条件的算中危，排期修；只影响体验或需要极端条件的是低危，记录跟踪。每个问题建单时必须写清：接口位置、复现步骤、影响、修复方案、验证方式；修完要用同一段 payload 复扫一次，确认不再复现才关闭。这份单据应在团队内部留存，不要连同未修复的漏洞细节外发。