渗透测试流程与常见漏洞防护

引言

渗透测试本质上是在授权范围内，模拟真实攻击者去看系统哪里会被打穿。它的价值不只是在'找洞'，更在于把风险暴露出来：哪些资产对外可见，哪些配置太松，哪些接口默认信任了用户输入。做得好的测试，最后给出的不是一串漏洞名，而是一份能落地的加固清单。

注意： 渗透测试必须在获得明确书面授权的前提下进行，严禁对未授权系统进行任何探测或攻击操作。

一、信息收集阶段

信息收集决定了后面能走多远。这个阶段越扎实，后面的扫描和验证越少走弯路。

1. 域名与 IP 查询

域名信息查询：用 WHOIS 看注册信息和 DNS 记录，通常能顺手摸到关联子域。
IP 信息查询：确认域名实际解析到哪里，判断前面是不是套了 CDN，源站有没有被直接暴露。
端口信息查询：用 Nmap 之类的工具扫开放端口。比如 80 端口多半是 Web 服务，3389 往往是 Windows 远程桌面；但端口只说明'可能是什么'，还得结合 Banner 和返回内容看。

2. 指纹识别

通过首页内容、源代码、HTTP 响应头去判断技术栈，通常比盲扫更省时间。

框架识别：像 wp-admin 这类特征路径，基本就能把 WordPress 先圈出来。
服务器识别：看 Server 响应头，能大致分出 Apache、Nginx 还是 IIS。
漏洞线索：目录结构、静态资源路径、暴露的调试信息，常常比'看起来正常的页面'更有用。

二、漏洞扫描阶段

信息摸清楚以后，可以上自动化工具做一轮覆盖面更广的探测。扫描器效率高，但它只是在帮你缩小范围，不是替你下结论。

1. 主机扫描

用 Nessus 这类漏扫工具检查操作系统和中间件层面的已知 CVE，重点看三类东西：没打补丁的组件、默认配置的服务、以及弱口令暴露的入口。

2. Web 扫描

AWVS（Acunetix）这类 Web 扫描器适合做初筛，SQL 注入、XSS、目录遍历之类的问题都能覆盖到一部分。问题是误报也不少，扫出来的结果最好都人工过一遍，不然报告会很花哨，结论却站不住。

风险提示： 扫描器高频请求可能把目标服务打得很慢，重一点的场景甚至会直接影响业务。生产环境上手前，回滚方案和时间窗口都得先确认好。

三、常见漏洞类型与防御策略

下面这些问题在实际测试里出现得很频繁。每一类都不是'知道名字'就够了，真正麻烦的地方在于它们往往藏在默认配置、历史包袱和业务赶工里。

1. 弱口令漏洞

漏洞描述：管理后台、数据库、SSH 等服务使用了简单密码或默认账号密码。
检测思路：如果没有验证码限制，可以用 Burp Suite 配合字典尝试验证；如果有验证码，就得看它是不是只是摆设，或者能不能被绕过。
修复建议：
1. 强制密码复杂度策略，长度不小于 8 位，并包含大小写字母、数字和特殊字符。
2. 启用多因素认证（MFA）。
3. 限制登录尝试次数，并定期更换口令。

2. 文件下载与目录浏览漏洞

漏洞描述：权限控制做得太松，导致用户能直接下载源码、配置文件，甚至任意文件。
检测思路：试试 /../ 这类路径穿越，顺手看看 .git、.svn 这些历史目录有没有被暴露出来。很多时候问题不在'能不能访问'，而在'服务端根本没拦'。
修复建议：
1. 用白名单限制可访问的目录和文件类型。
2. 过滤 ./、.. 等特殊字符。
3. 用文件流返回下载内容，不要直接暴露物理路径。
4. Tomcat 里把 listings 关掉。

3. 任意文件上传漏洞

漏洞描述：上传接口只看文件名或 Content-Type，没真正检查文件内容，最后可能把 WebShell 放进去了。
检测思路：
1. 把上传文件的 Content-Type 改成 image/jpeg，但内容仍然放 PHP 代码。
2. 换后缀，比如 .php5、.phtml，看黑名单是不是只认表面。
3. 利用 .htaccess 或 .user.ini 去改执行行为。
修复建议：
1. 服务端校验文件头（Magic Number），不要只看后缀。
2. 上传后重命名，例如改成 MD5 哈希；上传目录不要有执行权限。
3. 文件存到 Web 根目录之外，需要时再通过代理脚本读取。

4. 命令注入漏洞

漏洞描述：程序把用户输入直接拼到系统命令里执行了。
检测思路：在参数里试 ; ls、| cat /etc/passwd 这类命令，看有没有被原样执行。
修复建议：
1. 尽量别用 system()、exec() 这类危险函数。
2. 必须调用命令时，用白名单限制参数。
3. 过滤 |、&、;、$ 等特殊字符。

5. SQL 注入漏洞

漏洞描述：后端没有对用户输入做转义或预编译，攻击者就能把自己的 SQL 拼进去。
检测思路：
1. 手动输入 ' OR '1'='1 看返回是否异常。
2. 用 sqlmap 做自动化验证。

修复建议：

优先方案：使用预编译语句（Prepared Statements）。

// Java JDBC 示例
String sql = "SELECT * FROM users WHERE id = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, userId);
ResultSet rs = pstmt.executeQuery();

不要拼接 SQL 字符串。
给数据库账户最小权限。

6. 跨站脚本漏洞（XSS）

漏洞描述：页面直接输出了用户输入，恶意脚本就能在受害者浏览器里执行。
分类：
- 存储型：数据先入库，后展示，比如评论区。
- 反射型：URL 参数直接回显，比如搜索框。
- DOM 型：前端 JavaScript 自己处理 URL 参数时出了问题。
修复建议：
1. 对所有用户输入做 HTML 编码，比如把 < 转成 <。
2. 加 Content-Security-Policy（CSP）响应头。
3. Cookie 加上 HttpOnly 和 Secure。

7. 跨站请求伪造（CSRF）

漏洞描述：用户已经登录的情况下，被诱导访问恶意链接，结果在不知情时完成了敏感操作。
修复建议：
1. 表单提交使用一次性 Token。
2. 对关键操作加验证码。
3. 校验 Referer 请求头。
4. 像修改密码这类操作，最好再做一次身份验证。

8. 内部后台地址暴露

漏洞描述：管理员入口、API 文档、测试页面没有访问控制，直接暴露在公网。
修复建议：
1. 后台只允许特定 IP 访问。
2. 不要把敏感入口挂在明显位置，但也别把'隐藏路径'当成真正的安全措施。

9. 信息泄露漏洞

漏洞描述：备份文件、错误日志、源码片段被意外公开。
修复建议：
1. 清理 .bak、.swp 这类临时文件。
2. 屏蔽详细错误堆栈，只返回通用提示。
3. 严格控制接口权限，避免越权读取。

10. 失效的身份认证与会话管理

漏洞描述：Session ID 可预测、不过期，或者干脆放在 URL 里传递。
修复建议：
1. 登录后生成高强度随机 Session ID。
2. 禁用 URL 重写传递 Session。
3. 设置合理的会话超时时间，登出后立即失效。

11. 失效的访问控制

漏洞描述：后端没检查权限，用户就能直接访问别人的数据，也就是常见的 IDOR。
修复建议：
1. 每个业务请求都要在后端校验当前用户权限。
2. 私有资源默认拒绝访问。
3. API 加速率限制，别给自动化批量探测留太多空间。

12. 安全配置错误

漏洞描述：默认配置没改、没必要的服务还开着，或者错误信息直接把细节吐出来了。
修复建议：
1. 按最小化原则移除不必要的组件。
2. 依照标准加固流程配置服务器。
3. 统一错误处理界面，别让环境信息到处飞。

13. 使用含有已知漏洞的组件

漏洞描述：系统里还在用过时、停止维护的库或框架，比如 Log4j、Struts。
修复建议：
1. 定期更新到最新稳定版。
2. 从官方渠道获取依赖，并做签名验证。
3. 关注开源组件的安全公告，必要时先打虚拟补丁顶住。

结语

渗透测试不是做一次就结束的事情。业务会变，依赖会变，配置也会慢慢走样；如果不定期复测，很多问题会在你以为'已经修过了'的时候重新冒出来。把测试结果真正接进 DevSecOps 流程，持续复查、持续加固，效果通常比单次大扫除更靠谱。