Web渗透测试检查清单：信息收集、配置管理、认证授权与数据验证实战

简介：面向软件测试与安全评估人员，《渗透测试指导书.pdf》是一份可落地的操作型检查手册，用于规范Web系统渗透测试的流程与判定标准。文档以序号、检查项、检查内容、操作步骤、预期结果的结构展开，从WEB应用发现、端口扫描、错误代码分析、robots与爬虫分析，到配置管理中的中间件漏洞检查、管理界面弱口令、HTTP方法、SSL/TLS检测，再到认证测试中的用户枚举、暴力破解、验证码与密码修改点验证，基本覆盖常规渗透测试的关键环节。每个检查项均给出示例命令或工具，并标明预期结果，便于测试人员边测边对照、输出标准化结论。资源包体积小巧，仅包含1个PDF文件、大小约319KB，适合安全测试初学者快速建立渗透测试框架，也可供企业安全团队作为内部检查表或新人培训参考。该资源在CSDN已有138人学习下载，具备一定参考价值。

1. 信息收集决定渗透成功率

软件测试领域里的渗透测试，真正拉开差距的环节通常不在漏洞利用，而在拿到目标后的前二十分钟。很多测试人员直接掏出扫描器开扫，但扫描器能给出端口和服务版本，却回答不了这几个关键问题：非标准端口上还跑着哪些 Web 服务、服务器上是否绑定了其他域名、存在与不存在目录的响应是否不同。LC-CS-042.1 这份渗透测试指导书把信息收集拆成五个动作：nmap 查全端口、curl 识别 Web 服务、错误代码分析、robots.txt 与爬虫目录探测。完成这五步，后续测试重心是放在中间件漏洞还是应用层逻辑，就会非常清楚。对刚接触渗透测试的人来说，这个阶段是在建立测试面感知；对有经验的工程师来说，它决定了后面每一步测试的效率。

2. 配置管理：中间件版本、管理后台与 SSL 检查清单

配置管理测试不追求找 0day，而是检验部署层面的暴露面。同一套 Java 应用，跑在 Tomcat 或 Jboss 上，外部入口可能完全不同；同一个管理控制台是否对外开放、是否仍使用默认口令，直接决定攻击者能否快速拿到控制权限。指导书这一部分覆盖了已知漏洞排查、应用管理界面、HTTP 方法与 SSL/TLS 四类内容。

2.1 已知漏洞与配置缺陷的落地判断

指导书要求对网站基础结构做已知漏洞检查，重点列出 Struts2 命令执行、ThinkPHP 框架漏洞、常见 CMS 漏洞、Apache 与 Jboss 已知问题。实际操作时，判断依据通常是响应头里的版本信息和路径特征。先发一条 curl 请求拿响应头，看 Server 字段、X-Powered-By 以及 cookie 特征：

curl -sI http://www.example.com/

返回里的Server: Apache/2.4.6、X-Powered-By: PHP/5.6就是版本线索；出现JSESSIONID则说明后端是 JVM 系。拿到版本后再和公开漏洞库比对，决定直接验证还是先记录风险。配置缺陷测试更依赖响应差异，比如目录遍历的探测：请求http://www.example.com/images/../WEB-INF/web.xml，如果返回了 web.xml 内容，说明静态资源路径没有限制..解析。

配置缺陷还包括 IIS 上传漏洞这类因解析顺序引起的问题。判断方法是在授权范围内上传一个文本文件，改成.asp;.jpg后缀后重新上传，看服务器是否以脚本方式解析。这个动作容易产生实际文件，必须在拿到书面授权的目标上操作，不能把生产系统当成验证环境。

2.2 管理后台的探测顺序与弱口令判断

应用管理界面是配置管理里最常出结果的项。指导书列了 Tomcat、Jboss、WebLogic、WebSphere、Axis2 的控制台默认路径，这些路径是长期项目沉淀下来的，可以直接按相对路径探测。常见控制台路径和默认弱口令如下：

用 curl 循环批量探测，比逐个浏览器访问快得多：

for path in /manager/html /admin-console /jmx-console /jbossws /console /admin /axis2-admin; do code=$(curl -s -o /dev/null -w "%{http_code}" "http://www.example.com${path}") echo "${path} -> ${code}" done

返回 200 说明控制台可直接访问；401 说明存在基础认证，可以继续试弱口令；302 则要看 Location 是否跳转到登录页。如果管理端口只对内网开放，公网请求会连接超时或拒绝访问，这类结果不能直接判为不存在，要在报告里备注内网管理面的测试建议。弱口令测试先人工输入默认口令组合，再用 Burp Intruder 加载二十条左右小字典，避免一上来跑大字典，既慢又容易让账号触发锁定。

2.3 HTTP 方法与 SSL/TLS 的检查命令

HTTP 方法测试的目标是确认服务器没有开放 PUT、DELETE、COPY、MOVE 等写方法。指导书推荐用 netcat 发送 OPTIONS 请求，在没有图形化工具的环境里也能直接做：

printf 'OPTIONS / HTTP/1.1\r\nHost: www.example.com\r\n\r\n' | nc -v -w 5 www.example.com 80

响应中的 Allow 头会列出服务器允许的方法，例如Allow: GET, HEAD, POST, OPTIONS。如果出现 PUT 或 DELETE，不能立刻判定漏洞，还需要对具体路径试一次上传，确认服务器真的接受写操作再定性。多数情况下，只有 WebDAV 目录开放写方法，普通静态目录会返回 405。

SSL/TLS 测试分两块。一是传输加密：用 Burp 截获登录请求，密码明文且没有 HTTPS 直接判不符合要求。二是加密强度，指导书列出域名匹配、有效期、吊销、可信根四个证书检查点。命令行快速验证用 openssl：

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

证书没问题后再用 ssl-enum-ciphers 脚本看加密套件，一次性覆盖协议版本和弱套件检查：

nmap -p 443 --script ssl-enum-ciphers --script-args vulns.showall www.example.com

输出会标明每个协议版本支持的套件以及是否存在已知漏洞项。看到 TLSv1.0、DES、RC4 时，标记为高风险通信项。

3. 认证与会话：从绕过手法到会话边界

认证测试表面上是和登录框较劲，实际要覆盖三个阶段：登录前如何绕过、登录后如何保持会话、退出后如何失效。指导书把这一块拆成认证绕过、用户枚举、暴力破解、验证码、密码修改与重置，再加上会话管理，覆盖了账户生命周期里的主要边界点。

3.1 认证绕过三板斧

第一板斧是直连后台地址。先用管理员账号登录，记录后台实际访问过的页面 URL，退出后清空 cookie，在浏览器里直接输入这些地址。如果页面仍然能打开，说明认证只依赖前端跳转，服务端没有做全局 session 校验。这类问题在老旧 ASP 站点里很常见，后台文件名经常是 admin_top.asp、menu.asp 这种可预测名称。

第二板斧是参数篡改。指导书给的例子是把list?action=view改成list?action=edit，验证操作权限是否绑定在 URL 参数上。测试时先抓一个正常操作的请求，逐个修改功能参数和资源 ID，观察页面内容是否随之变化。权限控制如果依赖参数值而不是服务端角色判断，攻击者改一个词就能越权。

第三板斧是登录时的 SQL 注入绕过，在用户名处输入：

admin' or '1'='1

后端如果把参数直接拼接进 SQL，登录查询会变成WHERE username='admin' or '1'='1'，条件恒为真，密码校验被绕过。这个 payload 只对字符型拼接有效，参数化查询不会受影响。测试时要在页面和 Burp 里各提交一次，因为部分 WAF 只拦截浏览器页面请求，不拦截工具重放的报文。

3.2 用户枚举与暴力破解的节奏控制

用户枚举测试的关键是两次请求的差异。正确用户名配错误密码，和不存在的用户名配错误密码，如果返回文案不同，例如“密码错误”与“用户不存在”，网站就泄露了账户是否存在。测试过程要保持两个请求除用户名字段外完全一致，避免因为其他参数差异产生误判。

提示：只对已授权目标做用户枚举与登录爆破，控制请求频率，避免触发账户锁定和业务告警。

暴力破解前要观察锁定策略。连续输错三次就锁定，爆破就失去意义，还会给业务制造真实故障。指导书建议先建 20 条口令的字典，用 Burp Intruder 对单个用户名跑。字典质量比数量重要，优先组合目标历史口令、通用弱口令和公司缩写，而不是直接拿百万行字典去撞。

3.3 验证码检测的三层检查

验证码不是有就行。指导书把检查拆成三层：图形复杂度、是否可从前端获取、服务端是否真正校验。图形要有干扰线，不能是纯色背景，这是第一层。

第二层是右键查看源代码，搜索验证码参数名或生成的接口。如果验证码明文出现在 HTML 或 URL 参数里，等于没有验证码。第三层最关键：表单提交时服务端必须先校验验证码再校验密码。操作方法是用 Burp 抓登录请求，复制 post 内容，保持验证码不变，多次重复提交。如果每次都能登录成功，说明验证码被复用或根本没有参与校验；只有第一次成功，说明校验后刷新了 session，旧验证码立即失效，这是合格实现。

3.4 Cookie 重放、会话固定与 CSRF

Cookie 测试可以归纳为三个问题：是否无限期有效、是否保存明文敏感信息、关键字段能否被猜测篡改。登录后保存 cookie，退出后重放同一份 cookie 访问受限页面：

curl -s -b "JSESSIONID=xxxx; IsAdmin=no" http://www.example.com/admin/order/list

退出后 cookie 仍能访问受限页面，说明服务端没有销毁会话。响应里出现 IsAdmin、role 这类字段，改成 yes 或 admin 再请求，如果权限变化，说明服务端信任了可篡改的 cookie 字段。正确做法是权限只存在服务端 session 里，客户端 cookie 只存随机会话 ID。

会话固定则看登录前后 sessionID 是否变化。登录前用 Burp 拿到一个未认证的 sessionID，登录成功后再抓一次包对比。如果 ID 没变，攻击者可以在受害者登录前塞给他一个已知 ID，登录后直接冒充。修复手段是登录成功后显式调用request.changeSessionId()或重新生成 session。

CSRF 检测的切入点是看关键操作是否使用 GET 请求。像delete?id=111这种通过地址栏就能触发的删除接口是 CSRF 高发场景。测试时记录所有修改类操作的类型，POST 和 DELETE 如果既不携带 token 也不校验 Origin 头，同样存在 CSRF 风险，但危害最大的始终是 GET，用户访问一张恶意图片就会中招。

3.5 密码修改与重置的隐藏检查点

密码修改点要抓包看两个字段：是否要求旧密码，是否包含用户名或用户 ID。如果修改请求里只有新密码和用户 ID，把 ID 改成另一个用户的，就可能实现任意账户密码修改。管理员重置密码的功能不要求旧密码，这是合理的，但必须限制只有管理员可调用；普通用户修改自己密码时必须验证旧密码。

密码重置要测四件事：安全问题是否可猜、是否允许无限次重置、重置后的密码是否明文返回、同一账号是否反复触发短信或邮件。遇到重置接口没有频控、目标手机号一分钟收十几条短信的情况，不算单纯的漏洞，但属于业务逻辑缺陷。通过邮件重置时，重放修改密码的请求若包含用户名参数且可篡改，同样属于越权漏洞。

4. 授权与数据验证：越权、路径遍历与注入测试

授权测试和认证测试的区别在于：认证解决“你是谁”，授权解决“你能做什么”。很多系统在登录框上做足了功夫，却在登录后的每个功能接口上忘记校验角色，导致普通用户直接访问管理页面就能操作。数据验证测试则是看应用是否信任了所有外部输入，包括参数、文件名、上传内容和请求头。

4.1 水平越权与垂直越权的分辨方式

指导书描述的测试步骤可以归纳为一句话：用高权限账号记录功能入口，换成低权限账号重放。垂直越权是普通用户访问管理员的增删改接口，水平越权是用户 A 修改用户 B 的数据。测试时先用管理员账号登录，记录添加账户一类的后台 URL，退出后换普通账号直接访问。页面能打开，说明菜单层面隐藏了入口，但接口层没有做权限判断。

水平越权还需要修改请求中的资源 ID。比如order.php?order=0001改成 0002 能查看他人订单，就是典型的水平越权。指导书在业务逻辑测试里补充了一点：交易类功能要把金额字段改成负数试试。负数金额不完全是安全漏洞，但它属于业务校验缺失，可能导致账户余额异常，同样要修复。

4.2 路径遍历与文件下载的测试方法

路径遍历的目标是读取 Web 目录之外的文件。指导书给出的用例是index?file=../../../../etc/passwd，执行时注意两点：../可能被过滤，需要尝试 URL 编码形式如%2e%2e%2f；判断依据是返回内容，不是状态码。有些系统对不存在的路径返回 200 空页面，有些返回 404，只有看到 passwd 文件内容才能确认漏洞。

文件下载漏洞的判断逻辑类似。用 Burp 抓取download.php?path=/web/1.rar请求，把参数改成../../../../../../etc/passwd或绝对路径，查看响应是否包含目标文件内容。下载功能最常见的问题是只校验文件后缀，不校验真实路径，导致攻击者可以读取任意文件。

4.3 SQL、XSS 与命令执行的验证路径

SQL 注入测试从最基础的单引号开始：

http://www.example.com/a.asp?id=1' http://www.example.com/a.asp?id=1 and 1=1 http://www.example.com/a.asp?id=1 or 1=2

加单引号后页面报错说明参数可能拼接；and 1=1与or 1=2的差异能确认注入点。每一条 payload 的响应都要记录，不能只凭页面差异判断，要确认是参数化查询还是过滤函数拦下的。如果 WAF 过滤了含空格的 payload，用/**/或 URL 编码绕过后再试。

XSS 测试要分反射、存储、DOM 三类。反射型在 URL 参数里提交<script>alert(1)</script>，存储型在注册、留言、文章等位置提交，看是否执行。脚本被转义时不能直接判定安全，要看源代码转义了哪些字符。只转义尖括号没有转义引号时，可以改用事件属性构造新 payload。DOM 型 XSS 的输出发生在 JavaScript 运行时，响应包里看不到变化，需要逐个检查 URL 参数向 DOM 的写入位置。

命令执行和代码注入常见于文件包含、日志查看、导出功能。测试时先提交;id、| whoami、$(id)等拼接字符，观察响应是否包含命令输出。这类问题一旦存在基本都是最高优先级，因为可以直接拿到命令执行权限。

4.4 文件上传与下载的检查次序

文件上传测试有固定顺序，指导书已经拆成前端验证、服务端验证、重命名策略、路径可见性、解析漏洞五个层次。按这个顺序复现就不会漏掉关键信息：

# 先看前端是否存在本地校验 curl -s "http://www.example.com/upload" | grep -i "accept\|\.jpg\|\.gif" # 用 curl 绕过浏览器直接提交 jsp 文件 curl -s -F "file=@shell.jsp" -F "submit=upload" "http://www.example.com/upload"

第一步 grep 到前端硬编码的后缀白名单，说明校验只存在于页面脚本；第二步用 curl 直接 POST 任意文件，如果服务器接受了 jsp 文件，可以确认服务端没有做校验或校验可以被绕过。上传后要核实是否重命名、路径是否可预测。随机命名加非 Web 目录存储基本安全，原文件名加静态目录可直接访问则风险极高。

解析漏洞要针对中间件调整文件名。IIS 6 时代的分号截断、Apache 多后缀解析，在老系统里仍有残留。先识别服务器类型，再构造对应文件名上传，能执行脚本内容才算确认漏洞，不能只凭文件上传成功就下结论。

5. 把检查单固化成可复现的回归脚本

指导书内容量大，每次从头跑一遍不现实。我通常把检查项压缩成一条脚本，首次测试用它摸清轮廓，修复后的回归验证也用它做前后对比。

5.1 一条命令完成阶段性检查

#!/bin/bash TARGET="${1:?usage: $0 http://target.example.com}" TS=$(date +%Y%m%d_%H%M%S) OUT="quick_pentest_${TS}.txt" { echo "==== [1] response head ====" curl -sI "$TARGET" echo "==== [2] robots.txt ====" curl -s "$TARGET/robots.txt" echo "==== [3] admin console probes ====" for p in /manager/html /admin-console /jmx-console /jbossws /console /admin /axis2-admin; do code=$(curl -s -o /dev/null -w "%{http_code}" "$TARGET$p") echo "$p -> $code" done echo "==== [4] HTTP methods ====" nmap -Pn -p 80,443 --script http-methods "$TARGET" \ | grep -iE "PUT|DELETE|COPY|MOVE" || echo "no unsafe methods" echo "==== [5] SSL/TLS ====" nmap -Pn -p 443 --script ssl-enum-ciphers "$TARGET" \ | grep -iE "TLSv1\.0|DES|RC4|weak" || echo "no weak cipher found" } | tee "$OUT"

脚本五个模块对应信息收集和配置管理的主要检查项。curl -sI看响应头与版本特征，robots.txt 推断隐藏目录，控制台路径探测是管理后台检查的批量版，http-methods 和 ssl-enum-ciphers 负责 HTTP 方法与加密套件。tee 把输出同时写到终端和时间戳文件，复测时直接 diff 两次日志，能一眼看出哪些问题已修复、哪些端口或响应头发生变化。

5.2 让报告具备可复查性

每条漏洞记录只写“存在 SQL 注入”没有意义，至少要保存三样东西：复现请求、受影响参数、修复建议。SQL 注入要贴出完整 URL 和 payload，注明是在登录页还是列表参数发现的；越权问题要记录高权限账号访问过的 URL 和低权限账号重放后的响应。渗透测试工程师交接项目时，请求时间、会话 ID 和原始报文比截图更有价值，因为修复后的回归测试需要用同一份报文重新放一遍，判断是否真的被拦住。

手动测试阶段尽量把 Burp 的请求历史导出保存。指导书本身是 PDF 文档，但工作产物应当是脚本和捕获的数据包，这样下一轮测试才能在同一基础上对比，而不是重新摸索一遍检查边界。

本文还有配套的精品资源，点击获取