安全测试面试问答（一）
1、常见的 Web 安全漏洞有哪些？
1）注入漏洞（Injection） | SQL 注入：攻击者通过构造恶意 SQL 语句篡改数据库查询，窃取或破坏数据。 命令注入：通过系统命令拼接执行恶意指令（如 ; rm -rf /）。 防御：参数化查询（Prepared Statements）、输入验证、ORM 框架。 |
2）跨站脚本（XSS, Cross-Site Scripting） | 类型：
防御：输入输出转义（如 HTML Entity 编码）、CSP（内容安全策略） |
3）跨站请求伪造（CSRF/XSRF） | 诱骗用户在已登录状态下执行非预期的操作（如转账）。 防御：CSRF Token、SameSite Cookie、验证 Referer。 |
4）身份认证与会话管理漏洞 | 弱密码、会话固定（Session Fixation）、Token 泄露等。 防御：多因素认证、HTTPS、短期会话超时、JWT 安全配置。 |
5）敏感数据泄露 | 明文存储密码、未加密传输（如 HTTP）、日志泄露密钥。 防御：加密（AES、TLS）、哈希加盐（如 bcrypt）、最小化数据暴露。 |
6）XML外部实体攻击（XXE） | 解析恶意 XML 文件时泄露系统文件（如 /etc/passwd）。 防御：禁用 DTD/外部实体、使用 JSON 替代 XML。 |
7）安全配置错误 | 默认密码、冗余功能（如调试接口）、错误的 CORS 配置。 防御：最小化权限、定期扫描（如 Nessus）。 |
8）不安全的直接对象引用（IDOR） | 通过修改参数（如 /user?id=123）越权访问资源。 防御：权限校验、使用随机 ID（UUID）、访问控制列表（ACL）。 |
9）服务端请求伪造（SSRF） | 诱骗服务器访问内部资源（如 http://localhost/admin）。 防御：过滤用户输入的 URL、禁用非必要协议（如 file://）。 |
10）API安全漏洞 | 未授权访问：缺少鉴权的 API 端点。 批量分配：通过 JSON 覆盖敏感字段（如 {"isAdmin":true}）。 防御：输入验证、DTO（数据传输对象）、速率限制。 |
11）文件上传漏洞 | 上传恶意文件（如 .php、.jsp）导致代码执行。 防御：文件类型校验、重命名、存储到非 Web 目录。 |
12）逻辑漏洞 | 业务逻辑缺陷（如重复提交订单、绕过支付流程）。 防御：代码审计、流程验证测试。 |
13）依赖库漏洞 | 使用含已知漏洞的第三方组件（如 Log4j、Fastjson）。 防御：定期更新依赖、SCA 工具（如 Dependabot）。 |
14）DoS/DDoS攻击 | 资源耗尽（如慢速攻击、大文件上传）。 防御：限流、WAF、CDN 抗 DDoS。 |
2、OWASP Top 10 包含哪些安全风险？
OWASP（Open Web Application Security Project）Top 10 是当前最权威的 Web 应用程序安全风险清单，每 3-4 年更新一次。
1）访问控制失效（Broken Access Control） | 风险：用户越权访问未授权的功能或数据（如普通用户访问管理员接口）。 案例：修改 URL 参数（/user?id=123）访问他人数据。 防御：强制权限校验、最小化权限原则、RBAC/ABAC 模型。 |
2）加密机制失效（Cryptographic Failures） | 风险：敏感数据（密码、信用卡号）因弱加密或明文存储泄露。 案例：使用 HTTP 传输密码、SHA-1 哈希存储。 防御：强制 TLS（HTTPS）、使用强算法（AES-256、bcrypt/PBKDF2）。 |
3）注入漏洞（Injection） | 风险：SQL、NoSQL、OS 命令等注入导致数据泄露或系统破坏。 案例：' OR 1=1 -- 绕过登录验证。 防御：参数化查询、ORM、输入过滤（白名单）。 |
4）不安全设计（Insecure Design） | 新增项：因架构或业务流程设计缺陷导致的安全问题。 案例：密码重置流程仅验证用户名（无需令牌）。 防御：威胁建模（Threat Modeling）、安全设计模式。 |
5）安全配置错误（Security Misconfiguration） | 风险：默认配置、未打补丁、暴露调试信息。 案例：未关闭的测试接口、Apache 版本泄露。 防御：自动化配置检查、最小化服务。 |
6）过时或有漏洞的组件 （Vulnerable and Outdated Components） | 风险：使用含已知漏洞的第三方库（如 Log4j、Fastjson）。 案例：CVE-2021-44228（Log4Shell）。 防御：依赖扫描（如 Snyk、Dependabot）、及时更新。 |
7）身份认证失效 （Identification and Authentication Failures） | 风险：弱密码、会话固定、暴力破解。 案例：允许 admin/password 登录。 防御：多因素认证（MFA）、密码复杂度、防撞库。 |
8）软件和数据完整性失效 （Software and Data Integrity Failures） | 新增项：未验证代码或数据的来源和完整性。 案例：从不可信源动态加载库（供应链攻击）。 防御：数字签名验证（如 GPG）、CI/CD 安全校验。 |
9）安全日志与监控不足 （Security Logging and Monitoring Failures） | 风险：未能及时发现攻击行为（如日志未记录登录失败）。 案例：攻击者尝试 1000 次密码未被检测。 防御：集中化日志（ELK）、SIEM 系统（如 Splunk）、告警机制。 |
10）服务端请求伪造（SSRF） | 风险：诱骗服务器访问内部资源（如 http://169.254.169.254）。 案例：通过上传图片 URL 读取云服务器元数据。 防御：禁用非必要协议（file://、ftp://）、网络隔离。 |
3、如何使用 Burp Suite 进行安全测试？
Burp Suite 是用于 Web 应用安全测试的集成平台，广泛用于渗透测试和漏洞挖掘。
1） 环境准备
- 安装：下载 Burp Suite（社区版免费，专业版功能更全）。
- 代理配置：浏览器设置代理为 127.0.0.1:8080（Burp 默认监听端口）。安装 Burp 的 CA 证书（访问 http://burp/cert 下载并导入浏览器），以拦截 HTTPS 流量。
- 目标确认：明确测试范围（如 https://example.com），避免非法测试。
2） 基础测试流程
(a) 拦截和修改请求（Proxy 模块）
- 步骤：打开 Burp → Proxy → Intercept，开启拦截（Intercept is on）。在浏览器操作（如登录、提交表单），请求会被 Burp 拦截。修改请求参数（如 Cookie、输入字段）后点击 Forward 发送。
- 用途：测试输入验证、越权访问等。
(b) 爬取网站内容（Target → Site Map）
- 步骤：浏览器访问目标网站，Burp 自动记录请求到 Target → Site Map。右键目标 → Engagement tools → Discover content（发现隐藏目录）。
- 用途：分析网站结构，寻找敏感文件（如 /admin、backup.zip）。
(c) 主动扫描漏洞（Scanner 模块，需专业版）
- 步骤：在 Site Map 中右键目标 → Active Scan。查看 Scanner → Issue activity 获取漏洞报告（如 SQL 注入、XSS）。
- 注意：主动扫描可能触发目标防护机制，需谨慎使用。
(d) 手动测试漏洞（Repeater/Intruder）
- Repeater（重放请求）：右键请求 → Send to Repeater，手动修改参数反复测试（如 IDOR、API 漏洞）。
- Intruder（自动化攻击）：右键请求 → Send to Intruder。设置攻击类型（如 Sniper 或 Cluster bomb），标记变量（如 §username§）。加载字典（如密码本）进行暴力破解或模糊测试。
3） 高级测试技巧
(a) XSS/SQL 注入测试
- 方法：在 Repeater 中修改输入为 <script>alert(1)</script> 或 ' OR 1=1 --。观察响应是否执行脚本或返回数据库错误。
(b) CSRF 漏洞验证
- 使用 Engagement tools → Generate CSRF PoC 生成恶意 HTML，测试能否伪造请求。
(c) 会话管理测试
- 在 Proxy → HTTP history 中分析会话 Cookie：是否可预测（如 sessionid=10001）。是否缺少 HttpOnly、Secure 属性。
(d) API 安全测试
- 导入 Swagger 文件（Target → Site Map → Import API definition）。
- 测试未授权访问、批量分配等漏洞。
4、什么是安全测试中的模糊测试 (Fuzz Testing)？
模糊测试（Fuzz Testing/Fuzzing）是一种自动化或半自动化的安全测试技术，通过向目标系统输入大量非预期、随机或畸形数据（称为“Fuzz”），观察其行为（如崩溃、错误或漏洞）来发现潜在的安全缺陷。
模糊测试的分类:
1）基于生成方式
- 基于变异（Mutation-based）：修改合法输入（如翻转字节、删减字段）。示例：将一个正常的 HTTP 请求中的 GET 改为 GEX。
- 基于生成（Generation-based）：根据协议/格式规则从头构造输入。示例：按照 HTTP 标准生成完全随机的请求。
2）基于反馈机制
- 无反馈（Dumb Fuzzing）：纯随机输入，效率低但覆盖广。
- 有反馈（Smart Fuzzing）：根据目标响应动态调整输入（如代码覆盖率）。工具：AFL（American Fuzzy Lop）、LibFuzzer。
3） 基于目标类型
- 协议模糊测试：测试网络协议（如 HTTP、TCP/IP）。
- 文件格式模糊测试：测试解析器（如 PDF、Excel）。
- API 模糊测试：针对 Web/系统 API 输入参数。
操作步骤（以 Web API 为例）：
1）确定测试目标：选择输入点（如 URL 参数、JSON 字段）。
2）生成测试用例：使用工具（如 Burp Intruder）或自定义脚本生成随机/畸形数据。示例输入：{"username": "admin' OR 1=1 --", "password": "\x00"}。
3）发送并监控：观察响应状态码（如 500 错误）、日志或内存占用。
4）分析结果：崩溃、错误信息或异常行为可能对应漏洞（如 SQL 注入、DoS）。
5、JWT 令牌存在哪些安全风险？如何进行安全验证？
JWT（JSON Web Token）广泛用于身份认证和授权，但其设计和使用中的不当可能导致严重安全风险。
常见安全风险 | |
算法篡改攻击（Algorithm Confusion） | 风险：攻击者将头部中的算法改为 none 或弱算法（如 HS256），绕过签名验证。 示例：修改 {"alg":"none"} 并删除签名部分。 触发条件：服务端未强制校验算法类型。 |
密钥泄露或弱密钥 | 风险：
案例：通过 JWT Crack 破解弱密钥。 |
令牌泄露（Token Theft） | 风险：Token 被中间人攻击截获（如未使用 HTTPS）。 客户端存储不当（如 localStorage 易受 XSS 窃取）。 |
无效的过期时间（Expiration Claim） | 风险：未设置exp字段或过期时间过长，导致令牌长期有效。 |
敏感信息泄露 | 风险：Payload 中存储敏感数据（如密码、权限列表），Base64 解码即可读取。 |
令牌重放攻击（Replay Attack） | 风险：拦截旧令牌并重复使用（尤其无短期有效性校验时）。 |
密钥管理问题 | 风险：
|
JWT 的安全验证措施：
1） 强制校验算法类型
- 代码示例（Node.js）：javascript
- 禁止：接受 none 算法或客户端可控的算法类型。
2） 使用强算法和密钥
- 推荐算法：非对称加密：RS256（RSA + SHA256）或 ES256（ECDSA）。对称加密（仅必要时）：HS256 + 强密钥（如 32 字节随机字符串）。
- 密钥管理：定期轮换密钥，使用密钥管理系统（如 AWS KMS）。
3） 校验关键声明（Claims）
- 必验字段：javascript
- 其他字段：exp（过期时间）、nbf（生效时间）、iat（签发时间）。
4） 防止令牌泄露
- 传输安全：仅通过 HTTPS 传输。避免将 Token 暴露在 URL 中（如 ?token=xxx）。
- 存储安全：客户端使用 HttpOnly + Secure 的 Cookie 存储（防 XSS）。避免 localStorage/sessionStorage。
5） 短期令牌 + 刷新令牌
- 方案：Access Token 有效期短（如 15 分钟），Refresh Token 有效期长但仅用于获取新 Access Token。服务端维护 Refresh Token 的黑名单/白名单。
6） 日志与监控
- 记录异常的 JWT 验证失败（如频繁的无效签名请求）。
- 使用工具（如 JWT Revoker）实现令牌吊销。
整理面试过程中的测试问答，常看常新，多多学习！有些问题是从其他人那里转载而来，会在文章下面注明出处，希望大家多多支持~~，觉得满意的话就送一朵小花花，谢谢！ 内容目录：https://www.nowcoder.com/discuss/779856598809264128?sourceSSR=users
阿里云工作强度 727人发布