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 等标准，确保测试活动合规、可追溯。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！