Postman Linux版如何进行安全性测试 - 问答

Postman Linux版进行安全性测试实操指南

一环境准备与代理抓包

安装与启动：在 Linux 下载 Postman 的 tar.gz 包，解压至 /opt/Postman，创建软链到 /usr/local/bin/postman 后直接运行；首次启动可选择“Skip and go to the app”，无需登录即可使用。为便于安全测试，建议全程使用 HTTPS 端点。
与 Burp Suite/ZAP 联动抓包：在 Postman 的 Settings → Proxy 中开启“Global Proxy Configuration”，关闭“Use System Proxy”，将代理设为 127.0.0.1:8080（与代理工具一致）；同时可在同一设置页的 General 中将“SSL certificate verification”临时关闭以绕过自签证书错误（仅测试环境）。如需长期可信拦截，请将代理 CA 导入系统信任库。抓包验证可在代理工具的 Proxy/History 中查看请求是否到达。

二认证与授权安全测试

认证机制覆盖：在 Postman 的 Authorization 选项卡测试 Basic、Bearer Token、OAuth 2.0 等模式；使用环境变量（如 {{access_token}}）管理令牌，并在集合运行或 CI/CD 中复用。
负面用例与权限校验：对受保护端点执行未授权访问、错误凭据、过期令牌、作用域越权等用例，校验返回 401/403 且不含敏感细节；对管理接口验证 RBAC 是否生效（普通用户不可越权）。

自动化断言示例：

成功登录应返回 200，凭据错误应返回 401
令牌过期应返回 401 并可触发刷新逻辑
越权访问应返回 403
示例脚本：

// 认证成功/失败校验
pm.test("Auth success returns 200", () => pm.response.to.have.status(200));
pm.test("Auth failure returns 401", () => pm.response.to.have.status(401));

// 错误响应不应泄露敏感信息
pm.test("Error response no sensitive info", () => {
  if (pm.response.code >= 400) {
    const txt = pm.response.text();
    pm.expect(txt).to.not.include("password");
    pm.expect(txt).to.not.include("secret");
    pm.expect(txt).to.not.include("stacktrace");
  }
});

上述流程依托 Postman 对多种认证的原生支持与 Tests 脚本的断言能力，可系统化覆盖认证与授权场景。

三输入验证与加密配置

注入与畸形输入：在参数、Header、Body 中构造常见攻击载荷，验证过滤与错误处理，如：
- SQL 注入：/users?name=normal_user' OR '1'='1
- XSS：POST /comments，Body 含 <script>alert('xss');</script>
  并在响应中检查是否被反射或存储，且未被正确编码/过滤。
加密与协议：确保全程使用 HTTPS/TLS；在 Postman 中发起请求时以 https:// 为目标；如需限定 TLS 版本，可在 Pre-request Script 中设置（示例：pm.request.setProtocolVersion(1.2);）。
响应与编码校验：对返回页面或错误信息验证 HTML 转义、JSON 安全序列化，避免脚本执行或信息泄露。

自动化校验示例：

// 检测响应是否意外包含未转义脚本
pm.test("No unescaped XSS payload in response", () => {
  const body = pm.response.text();
  pm.expect(body).to.not.include("<script>alert('xss');</script>");
});

以上方法可在 Postman 中直接构造用例并用脚本自动判定，覆盖输入验证与传输加密的关键风险点。

四批量执行与持续化安全回归

集合与变量：将安全用例沉淀为“API Security Tests”集合，使用环境变量管理 base_url、access_token、client_id/secret 等，便于多环境复用。

命令行与 CI/CD：使用 Newman（Postman CLI）在 Jenkins/GitLab CI 中批量运行并产出报告，实现每次提交后的安全回归。示例：

# 安装 Newman（示例）
npm i -D newman

# 运行集合与环境，并生成 HTML 报告
npx newman run "API Security Tests.postman_collection.json" \
  --environment "test_env.postman_environment.json" \
  --reporters cli,html \
  --reporter-html-export newman-report.html

监控与基线：利用 Postman Monitor 对关键安全断言（如 401/403 正确性、错误不泄露、TLS 使用）做定时巡检，形成可观测的安全基线。

五合规范围与工具边界

工具定位：Postman 适合做 功能性与安全回归（认证、授权、输入校验、错误处理、加密配置等）的自动化验证；它并非专业渗透工具，不能替代 Burp Suite、OWASP ZAP、Mitmproxy 等代理/扫描器在流量拦截、模糊测试、主动漏洞扫描方面的能力。建议将 Postman 与代理工具联动，形成“手工深度测试 + 自动化回归”的组合。
合规与范围：在测试前明确范围与策略（如优先覆盖 未授权访问、注入、敏感信息泄露 等高风险项），并尽量遵循 OWASP API Security Top 10 等标准，确保测试活动合规、可追溯。

0 赞

0 踩