OWASP Top 10 与 WSTG - 面试题

#

★★★

1. OWASP Top 10 的 10 类，A01（Broken Access Control）、A02（Cryptographic Failures）、A03（Injection）、A04（Insecure Design）、A05（Security Misconfiguration）、A06（Vulnerable and Outdated Components）、A07（Identification and Authentication Failures）、A08（Software and Data Integrity Failures）、A09（Security Logging and Monitoring Failures）、A10（SSRF）？

问题

请完整列举 OWASP Top 10 2021 版中的 10 类风险，并说明每一类的核心含义与典型场景是什么？

考察点

OWASP Top 10 2021 版 10 个风险分类的准确记忆
每类风险的核心威胁与典型漏洞场景
Top 10 与常见 CWE 的对应关系

答案

OWASP Top 10 2021 版将最常见的 Web 应用安全风险归纳为 10 类：A01 失效的访问控制（Broken Access Control），指用户可越权访问资源或功能，是占比最高的一类；A02 加密失败（Cryptographic Failures），涉及敏感数据明文传输/存储、弱加密算法、缺失 TLS 等；A03 注入（Injection），包括 SQL、NoSQL、OS 命令、LDAP 注入等，攻击者将恶意代码注入解释器；A04 不安全设计（Insecure Design），指架构层面缺少威胁建模与安全控制，属设计缺陷而非实现缺陷；A05 安全配置错误（Security Misconfiguration），如默认凭证、未加固的服务器、错误响应信息泄露；A06 有漏洞和过时的组件（Vulnerable and Outdated Components），使用已知漏洞的第三方库；A07 身份识别和认证失败（Identification and Authentication Failures），如弱口令、暴力破解防护缺失；A08 软件和数据完整性失败（Software and Data Integrity Failures），如不安全反序列化、CI/CD 管道被篡改；A09 安全日志和监控失败（Security Logging and Monitoring Failures），缺乏有效日志导致攻击无法被发现；A10 服务端请求伪造（SSRF），服务端可被诱导发起对内部资源或云元数据的请求。

解析

2021 版相较 2017 版将"敏感数据暴露"与"加密失败"合并为 A02，并新增了 A04 不安全设计和 A08 完整性失败，反映了业界对供应链安全与设计层面安全的前瞻。测试者应能熟记每个类别并映射到具体 CWE，以便在测试规划中系统性覆盖。

#

★★★

2. A01 Broken Access Control 的防御，deny by default、JWT 验证、CORS 严格策略、rate limiting 的工程实现？

问题

针对失效的访问控制（Broken Access Control），请说明 deny by default、JWT 验证、CORS 严格策略、rate limiting 等防御手段在实际工程中如何落地实现？

考察点

deny by default（默认拒绝）的授权原则
JWT 令牌的签名验证与异常处理
CORS 白名单策略的正确配置

答案

失效的访问控制是最常见的安全弱点，工程上应多层防御：首先是 deny by default，即默认拒绝所有访问，仅在白名单中显式放行，服务端在进行任何授权决策时都先假设无权限，避免因遗漏而放行；对于 JWT，服务端必须严格验证签名（如 RS256/HS256）、算法、过期时间与受众，且签名密钥必须私密保管，异常时走统一的 401 拒绝逻辑，避免因解析失败默认放行；CORS 严格策略应只允许可信来源的精确白名单，绝不使用 * 通配符并携带凭证，同时校验 Origin 头；rate limiting 对登录、越权探测、敏感接口做限流，防止攻击者批量枚举用户 ID 或资源 ID。四项手段结合服务端授权校验（而不是仅前端隐藏）才能有效防御。

解析

访问控制失效的根因往往是"依赖前端限制"或"默认放行"，因此工程实现必须强调服务端强制校验、默认拒绝、以及辅助性的防探测限流。测试时应验证删除/篡改 Header、修改请求参数后服务端是否仍正确拒绝。

示例代码

// 服务端授权：默认拒绝 + 显式放行
public boolean canAccess(AuthenticatedUser user, Resource resource) {
    if (user == null) return false; // deny by default
    if (!user.isActive()) return false;
    return user.hasRole(resource.getRequiredRole());
}

#

★★★

3. A03 Injection（SQL、NoSQL、OS command、LDAP）的防御，parameterized query、ORM、input validation？

问题

针对注入类漏洞（SQL、NoSQL、OS 命令、LDAP），请说明 parameterized query、ORM、input validation 等防御手段的原理与适用边界？

考察点

参数化查询（PreparedStatement）防止 SQL 注入的原理
ORM 框架对注入风险的缓解与局限
输入校验（白名单/黑名单）的适用场景

答案

注入的根因是用户输入被拼接进解释器执行。SQL 注入最有效的防御是参数化查询（PreparedStatement），将 SQL 结构与参数分离，参数被作为数据而非代码处理，从根本上阻断拼接；ORM 框架（如 Hibernate、MyBatis）同样通过参数绑定规避拼接，但需注意避免使用字符串拼接的动态 SQL 或 $ 语法；NoSQL 注入需注意对查询操作符（如 $where、$gt）的过滤与类型校验；OS 命令注入应避免拼接命令，改用参数化 API 或白名单命令；LDAP 注入需对特殊字符转义。输入校验（尤其白名单）作为纵深防御补充，但绝不能作为唯一防线——因为校验规则可能被绕过，而参数化是结构性的。

解析

核心原则是"从结构上分离数据与代码"，参数化/预编译优先，输入校验仅作辅助。测试应分别验证参数化方案是否真正生效，以及绕过校验（编码、大小写、注释符）是否仍可注入。

示例代码

// 参数化查询：结构预编译，用户输入作为参数绑定
String sql = "SELECT * FROM users WHERE name = ? AND age = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setString(1, name);
    ps.setInt(2, age);
    ResultSet rs = ps.executeQuery();
}

#

★★★

4. OWASP Top 10 A04 Insecure Design 的测试方法，威胁建模(Threat Modeling)和滥用用例(Abuse Case)如何指导测试设计？

问题

针对 A04 不安全设计，请说明威胁建模（Threat Modeling）和滥用用例（Abuse Case）如何指导安全测试的设计？

考察点

威胁建模（STRIDE/DREAD）的基本流程
滥用用例（Abuse Case）与正常用例的对照
设计缺陷如何转化为可执行的测试用例

答案

不安全设计属于架构层面的缺陷，测试应在需求与设计阶段前置介入。威胁建模通过识别系统资产、信任边界、威胁模型（如 STRIDE：Spoofing/Tampering/Repudiation/Information Disclosure/DoS/Elevation of Privilege），对每个组件逐个分析可能被攻击的威胁，从而识别出需要防护的设计点。滥用用例则从攻击者视角出发，反向思考"恶意用户会如何利用正常功能"，例如正常场景是"用户查看自己的订单"，滥用用例是"用户查看他人订单"或"用户修改订单金额"。测试者将威胁建模与滥用用例的输出转化为具体测试用例，纳入测试计划，重点验证设计层面是否内置了授权、加密、审计、限流等安全控制，从而在编码前发现并规避设计缺陷。

解析

相比实现缺陷，设计缺陷难以通过代码扫描发现，必须通过威胁建模提前识别。测试的价值在于将设计审查输出落地为可执行用例，并推动"安全默认"设计原则。

#

★★★

5. OWASP WSTG v4.2 的 12 大类，Information Gathering、Configuration & Deploy Management、Identity Management、Authentication、Authorization、Session Management、Input Validation、Error Handling、Cryptography、Business Logic、Client-side、API 的测试内容？

问题

请列举 OWASP WSTG v4.2 的 12 大类测试类别，并说明每一类的测试关注点是什么？

考察点

WSTG v4.2 12 大类的完整记忆
每类测试的具体内容与关注点
WSTG 与 OWASP Top 10 的互补关系

答案

OWASP Web Security Testing Guide（WSTG）v4.2 将测试归纳为 12 大类：Information Gathering（信息收集，如指纹识别、目录枚举）；Configuration and Deploy Management（配置与部署管理，如默认页面、敏感文件泄露）；Identity Management（身份管理，如用户枚举、注册流程）；Authentication（认证，如默认凭证、暴力破解、锁定策略）；Authorization（授权，如横向/纵向越权、功能级访问控制）；Session Management（会话管理，如 Cookie 属性、会话固定、会话逾期）；Input Validation（输入校验，如 XSS、SQLi、命令注入、XXE）；Error Handling（错误处理，如错误信息泄露堆栈）；Cryptography（加密，如弱算法、密钥管理）；Business Logic（业务逻辑，如参数篡改、流程绕过、竞态条件）；Client-side（客户端，如 DOM XSS、CORS、CSRF）；API（如 REST、GraphQL、认证、参数校验）。WSTG 提供了每个测试项的具体步骤、所需工具与预期结果，是手工测试的标准化操作手册。

解析

WSTG 是"怎么做测试"的指南，Top 10 是"测什么风险"的分类，二者互补。面试者应能枚举 12 类并举例说明，体现对安全测试方法论的系统掌握。

#

★★★

6. WSTG v4.2 Authentication 测试，default credentials、weak lockout、session timeout 的工程检查？

问题

依据 WSTG 的 Authentication 测试类别，请说明默认凭证、弱锁定策略、会话超时等认证机制的工程检查方法？

考察点

默认凭证（default credentials）的检查
弱锁定（weak lockout）如暴力破解防护的验证
会话超时（session timeout）的正确配置

答案

认证测试重点检查三类问题：一是默认凭证，检查应用是否仍使用出厂默认账号密码（如 admin/admin、默认 Tomcat 页面），以及注册/重置流程是否可被枚举或滥用；二是弱锁定策略，验证登录失败到一定次数后是否触发锁定或延迟，锁定是否可被绕过（如忽略锁定、通过刷新计数、利用不同用户名或分布式 IP 绕过），以及是否配置了强密码与多因素认证；三是会话超时，验证空闲超时与绝对超时是否正确生效，超时后旧会话是否立即失效，Cookie 是否设置了合理的过期时间。工程上应通过自动化脚本（如 ZAP/Burp 的认证测试插件）模拟连续错误登录、会话复用等场景，并核对配置仓库中的安全基线。

解析

认证是安全的第一道门，测试需从配置基线与行为验证两个层面覆盖。工程检查应结合配置审计（默认凭证、超时参数）与动态行为验证（锁定、会话失效）。

#

★★★

7. WSTG v4.2 Input Validation 测试，XSS、SQLi、Command Injection、XXE 的防御测试？

问题

依据 WSTG 的 Input Validation 测试类别，请说明 XSS、SQLi、Command Injection、XXE 的防御测试方法？

考察点

XSS（反射/存储/DOM）的测试与输出编码验证
SQLi 的注入点探测与参数化验证
Command Injection 的命令拼接测试

答案

输入校验测试围绕四类核心漏洞展开：XSS 需区分反射型、存储型与 DOM 型，构造绕过过滤的 payload（大小写、编码、事件属性），验证输出端是否做了上下文相关的 HTML/JS/URL 编码，并检查 CSP 配置；SQLi 通过在参数中注入单引号、注释符、联合查询等检测注入点，同时验证服务端是否使用参数化查询；Command Injection 在系统命令接收点（如 ping、文件下载）注入 ;、&&、| 等分隔符，验证是否执行了额外命令；XXE 通过构造含外部实体的 XML 文档（如 <!DOCTYPE 引用外部文件或 OOB 请求）验证是否开启外部实体解析与 DTD 处理。测试目标是确认防御措施（输出编码、参数化、输入白名单、XML 解析器禁用外部实体）真正生效。

解析

输入校验测试的核心是"假设输入不可信"，通过构造畸形、编码、嵌套的 payload 尝试绕过过滤器，并验证输出端与服务端的结构性防御。测试应同时覆盖输入段与输出段。

示例代码

// 安全 XML 解析：禁用外部实体与 DTD，防御 XXE
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);

#

★★

8. A02 Cryptographic Failures 的检测，弱密码、缺失 TLS、敏感数据明文存储？

问题

针对 A02 加密失败，请说明如何检测弱密码、缺失 TLS、敏感数据明文存储等加密问题？

考察点

弱加密算法与弱密码的识别方法
缺失/错误配置 TLS 的检测
敏感数据明文存储与传输的验证

答案

加密失败检测覆盖三个层面：弱密码方面，检查是否使用 MD5、SHA-1、DES、RC4 等已废弃算法存储密码或哈希，密码是否采用加盐的强哈希（如 bcrypt、scrypt、Argon2），密钥是否硬编码在代码或配置中；缺失 TLS 方面，用 SSL/TLS 扫描工具（如 sslyze、Qualys SSL Labs）检查端口是否启用 TLS、证书是否有效、是否支持弱协议（SSLv3、TLS 1.0）与弱密码套件，以及是否强制 HSTS；明文存储方面，检查数据库、日志、Cookie、URL 参数中是否出现明文密码、身份证号、支付信息等敏感数据，以及传输是否走 HTTPS。结合 SAST 规则扫描代码中的弱加密调用与硬编码密钥，配合 DAST 抓包验证传输加密。

解析

加密失败是"数据保护"的核心，检测需结合静态代码审计（算法、密钥管理）与动态流量检查（传输加密、证书配置）。测试应验证从存储到传输的完整数据链路。

#

★★

9. OWASP Top 10 A08 Software and Data Integrity Failures 的 CI/CD 管道完整性测试，如何验证构建和部署管道的完整性？

问题

针对 A08 软件和数据完整性失败，请说明如何验证 CI/CD 构建和部署管道的完整性？

考察点

构建产物来源与签名的验证
依赖来源与供应链完整性
CI/CD 配置与权限的最小化

答案

软件和数据完整性失败的核心是"构建出来的东西是否可信"。测试应从以下方面验证：构建产物是否经过签名（代码签名、容器镜像签名），能否验证其来源与未被篡改；依赖是否来自可信源并锁定版本（lockfile、固定哈希），是否对依赖做 SCA 扫描与材料清单（SBOM）；CI/CD 管道配置是否最小权限，是否防止恶意 PR 注入构建脚本，是否对 runner 做隔离；构建是否可复现、是否采用不可变构建，部署产物是否经校验后上线。测试应模拟对构建参数的注入、篡改依赖版本、篡改产物等场景，验证签名校验与完整性校验是否生效。

解析

完整性攻击（如 SolarWinds 供应链事件）往往发生在 CI/CD 管道，因此测试重点是验证从源码到产物的每一环节是否具备签名、校验与可追溯能力，并验证管道配置的安全基线。

#

★★

10. WSTG v4.2 Business Logic 测试，parameter tampering、workflow bypass、race condition 的工程价值？

问题

依据 WSTG 的 Business Logic 测试类别，请说明参数篡改、工作流绕过、竞态条件等测试的工程价值？

考察点

参数篡改（parameter tampering）测试
工作流绕过（workflow bypass）测试
竞态条件（race condition）测试

答案

业务逻辑漏洞往往带来直接的经济损失，是自动化扫描难以覆盖的领域。参数篡改测试通过在请求中修改价格、数量、金额、用户 ID 等参数，验证服务端是否信任客户端提交的敏感字段；工作流绕过测试验证是否可跳过关键步骤（如跳过支付、直接进入发货、跳过审批），或通过直接访问深层 URL 绕过流程；竞态条件测试通过并发请求验证是否存在重复提交、金额不一致、库存超卖等原子性缺陷。这三类测试都需要结合业务规则理解，手工设计场景，工程价值在于发现自动化工具无法发现的、直接导致资损或业务被滥用的逻辑性缺陷。

解析

业务逻辑测试强调"理解业务规则"，以攻击者视角逆向推演滥用场景。其价值在于发现自动化扫描盲区，测试者需与业务方协作确认预期行为。

#

★★

11. OWASP Top 10 的类别与变化？

问题

请说明 OWASP Top 10 各版本（尤其 2017 与 2021）的类别构成与主要变化？

考察点

2021 版 10 类风险及与 2017 版的对比
新增/合并/移除的类别
类别调整背后的趋势

答案

2021 版相对 2017 版有较大调整：A01 从注入变为失效的访问控制（原 A05 越权）并占据首位；A02 由原"敏感数据暴露"与"加密失败"合并为加密失败；A03 注入跌至第三名；A04 新增不安全设计；A05 为安全配置错误（由原 A06 配置错误调整而来）；A06 为有漏洞和过时的组件（原 A09）；A07 由原 A02 身份认证（Broken Authentication）重组为身份识别和认证失败；A08 新增软件和数据完整性失败；A09 新增安全日志和监控失败；A10 新增服务端请求伪造 SSRF。2017 版中的"XML 外部实体"（XXE）被并入注入类，"不安全反序列化"并入 A08。

解析

版本变化反映了社区对现实威胁的认知演进：访问控制与设计缺陷上升，反映了自动化工具对注入的覆盖提升、而访问控制与设计仍需人工测试的现状。测试者应关注趋势以调整测试重点。

#

★★

12. 不安全反序列化(Insecure Deserialization)的测试方法，如何用 ysoserial/PHPGGC 等 gadget 链生成工具构造 payload，验证 Java readObject、Python pickle/yaml.load、PHP unserialize 等入口的 RCE 风险，并验证类白名单、HMAC 签名与 JSON 等安全序列化格式等缓解措施是否生效？

问题

针对不安全反序列化，请说明如何使用 ysoserial/PHPGGC 等工具构造 gadget 链 payload，验证 Java、Python、PHP 反序列化入口的 RCE 风险，并验证类白名单、HMAC 签名、JSON 等缓解措施是否生效？

考察点

ysoserial/PHPGGC 等 gadget 链生成工具的使用
Java readObject、Python pickle/yaml.load、PHP unserialize 等入口
类白名单、HMAC 签名、JSON 序列化等缓解措施的验证

答案

不安全反序列化测试的核心是构造 gadget 链触发 RCE。对 Java 使用 ysoserial 生成针对已知 gadget 的序列化 payload（如 CommonsCollections、Spring 等），在目标反序列化入口（如 readObject）注入；对 PHP 使用 PHPGGC 构造针对框架 gadget 的 payload 注入 unserialize；对 Python 构造恶意 pickle 或利用 yaml.load（非 yaml.safe_load）构造对象。测试时先确认反序列化入口与可用的类库，再验证 payload 是否触发命令执行。缓解措施方面，验证是否启用类白名单（仅允许白名单类反序列化）、是否对序列化数据做 HMAC 签名防篡改、是否改用 JSON 等安全格式替代原生序列化。测试应确认这些措施确实阻挡了恶意 payload。

解析

反序列化漏洞难以用普通扫描发现，需结合源代码分析定位入口并针对性构造 payload。测试既验证漏洞存在性，也验证缓解措施的有效性，形成闭环。

#

★★

13. A10 SSRF 的测试方法，如何构造内网探测、云元数据访问与重定向绕过请求，验证服务端请求伪造防护？

问题

针对 A10 SSRF，请说明如何构造内网探测、云元数据访问与重定向绕过请求，以验证服务端请求伪造防护？

考察点

SSRF 的形成原理与入口
内网探测与云元数据访问（169.254.169.254）的构造
重定向、DNS 重绑定等绕过手段

答案

SSRF 指服务端被诱导发起对非预期目标的请求。测试时从 URL 下载、图片抓取、Webhook 回调等入口构造请求：内网探测通过 http://127.0.0.1、http://10.0.0.1、http://192.168.1.1 等探测内网开放端口；云元数据访问尝试请求 http://169.254.169.254/latest/meta-data/（AWS/Azure/GCP 云元数据端点）以窃取凭证；绕过防护可尝试重定向（目标 URL 302 跳转到内网）、DNS 重绑定、IP 编码（十六进制/八进制）、@ 语法混淆、短域名等。验证防护时检查是否对协议白名单（仅 http/https）、目标 IP 做黑/白名单、是否禁止跳转至内网地址、是否禁用元数据端点访问。测试应确认这些绕过均被拦截。

解析

SSRF 的防护难点在于"看似合法的 URL 经解析后指向内网"，因此测试需覆盖解析歧义与重定向链。云元数据端点是高危目标，应重点验证。

#

★★

14. 文件上传漏洞测试，恶意文件类型、尺寸限制、文件名注入与解析漏洞如何设计用例，防护措施如何验证？

问题

请说明针对文件上传漏洞，如何设计恶意文件类型、尺寸限制、文件名注入与解析漏洞的测试用例，并验证防护措施？

考察点

恶意文件类型（含可执行文件）的上传测试
文件大小、数量限制的验证
文件名注入与目录穿越

答案

文件上传测试需覆盖多类场景：恶意文件类型方面，上传可执行脚本（.jsp、.php、.asp）、伪装扩展名（如 .jpg 内含脚本）、上传 webshell 及图片马，验证服务端是否按内容而非扩展名校验文件类型；尺寸限制方面，上传超大文件、空文件、批量文件，验证大小与数量限制是否生效；文件名注入方面，构造含路径穿越（../）、特殊字符、统一编码的文件名，验证是否可写入任意目录；解析漏洞方面，双扩展名（shell.php.jpg）、%00 截断、上传目录可执行脚本等，验证上传文件是否可被解析执行。防护验证包括：基于内容嗅探的 MIME 校验、随机化存储文件名、上传目录不可执行、文件类型白名单、病毒扫描与文件大小限制。

解析

文件上传的高危在于"上传文件被当作代码执行"或"文件被覆盖/泄露"。测试需验证存储与执行环节的安全控制，而非仅校验扩展名。

#

★★

15. A06 使用含漏洞的过时组件，如何用成分分析与漏洞库评估组件风险，测试如何验证组件版本与已知漏洞的对应？

问题

针对 A06 使用含漏洞的过时组件，请说明如何用成分分析（SCA）与漏洞库评估组件风险，并验证组件版本与已知漏洞的对应？

考察点

SCA（软件成分分析）工具与 SBOM 的关系
CVE/NVD 漏洞库的查询与比对
组件版本与漏洞的精确对应

答案

过时组件测试的核心是精确匹配组件版本与已知漏洞。流程上：首先生成应用依赖清单（SBOM），通过 SCA 工具（如 OWASP Dependency-Check、Trivy、Snyk）扫描依赖树，识别每个组件及其版本；然后将组件版本与 CVE 数据库（NVD、GitHub Advisory）比对，匹配存在已知漏洞的组件版本；风险评估需结合 CVSS 严重度、漏洞被利用性（是否在 Exploit-DB 或蠕虫化）、组件是否暴露在攻击面。测试需特别关注传递依赖（transitive dependencies）与版本范围（如 >=1.0, <1.2）的准确解析，避免误报或漏报。测试验证应能证明"该版本确实存在该漏洞"以及"升级到修复版本后漏洞消失"。

解析

组件漏洞测试的难点在于版本-漏洞的精确映射与传递依赖解析。测试应集成 SCA 到 CI/CD，并对高严重度漏洞做回归验证。

#

★

16. OWASP Top 10 在 SAST/DAST 工具（ZAP、Burp）的扫描规则？

问题

请说明 OWASP Top 10 如何在 SAST/DAST 工具（如 ZAP、Burp Suite）的扫描规则中体现，扫描结果如何与 Top 10 类别对应？

考察点

OWASP Top 10 与 SAST/DAST 工具规则的映射
ZAP、Burp Suite 的扫描规则配置
扫描结果如何归类到 Top 10 风险类别

答案

OWASP Top 10 并非一套可直接运行的规则，而是风险分类框架，工具通过将其映射到具体检测规则来落地。ZAP（Zed Attack Proxy）内置了大量主动扫描规则，按类别对应到 Top 10：如 SQL 注入、XSS、命令注入规则对应 A03 注入；目录遍历、会话 Cookie 缺失属性对应 A01 访问控制与 A07 认证失败；HTTPS 与 TLS 配置检查对应 A02 加密失败；错误信息泄露对应 A09 日志监控。Burp Suite 通过 Scanner 引擎与扩展（如 BChecks、Pro 的主动扫描）提供类似覆盖，且可自定义规则。扫描结果通常以"风险等级 + 漏洞类型 + 类别标签"呈现，测试者可将结果按 Top 10 类别聚合，快速识别哪些类别问题集中。需要明确的是，工具对 A04 不安全设计、A08 完整性失败等设计/流程类风险覆盖较弱，需结合人工测试。

解析

工具扫描是 Top 10 自动化落地的主要手段，但工具覆盖偏重实现类漏洞（注入、XSS、配置），对设计类与供应链类风险覆盖有限。测试者应理解工具规则与 Top 10 的映射关系，同时用人工方法补足盲区。

#

★

17. OWASP Top 10 中各风险项的测试优先级排序方法？

问题

请说明如何对 OWASP Top 10 中各风险项确定测试优先级排序？

考察点

风险排序的维度（似然与影响）
业务暴露面与资产价值
测试资源与风险的匹配

答案

对 Top 10 风险项排序测试优先级，应从多维度综合评估：一是风险可能性，即该类漏洞在本应用的技术栈与业务场景下是否容易出现（如大量使用拼接 SQL 的旧系统则注入优先）；二是影响程度，即漏洞被利用造成的损失（数据泄露、资损、可用性）；三是暴露面，即该功能是否面向公网、是否处理敏感数据、是否为关键入口；四是历史漏洞数据与本组织弱点画像。结合这些因素，将风险项分成高/中/低优先级，优先测试高风险、高暴露、高影响的项，让有限测试资源投向最可能被利用的环节，而非机械化地平铺所有 10 类。

解析

优先排序的本质是"基于风险的测试"，用暴露面、可能性、影响三个维度加权，使测试资源聚焦于真实风险最高处，避免平均用力。

#

★

18. WSTG v4.2 API 测试，REST、GraphQL、gRPC、WebSocket 的测试差异？

问题

请说明 WSTG 中 API 测试对 REST、GraphQL、gRPC、WebSocket 的测试差异？

考察点

REST API 的测试重点
GraphQL 的查询注入与批量查询
gRPC 的二进制协议与安全性

答案

不同 API 协议的测试重点各异：REST API 重点测试资源级授权（IDOR）、HTTP 方法滥用、参数校验、认证与令牌、CORS 配置；GraphQL 需额外关注内省（introspection）泄露、查询深度/复杂度限制（防 N+1 与 DoS）、批量查询（batching）滥用、字段级授权，以及嵌套查询导致的资源耗尽；gRPC 采用二进制协议与 protobuf，需测试消息大小限制、认证与 TLS、服务端反射暴露，以及输入校验（恶意 protobuf 消息）；WebSocket 需测试握手阶段的认证与 Origin 校验、消息级权限校验、心跳与超时、以及消息内容注入（如 JSON 消息中的 XSS）。各类协议都要将认证、授权、输入校验贯穿始终。

解析

API 测试差异源于协议特性不同：GraphQL 的查询灵活性带来新攻击面，gRPC 的二进制性需专门工具，WebSocket 的持久连接需关注握手与消息校验。测试者需按协议适配测试策略。

#

★

19. 安全测试的报告，风险分级与建议？

问题

请说明安全测试报告如何对发现的风险进行分级，并给出可执行的修复建议？

考察点

风险分级标准（CVSS 与业务影响）
报告的结构与要素
可执行修复建议的撰写

答案

安全测试报告应结构清晰、风险分级明确。风险分级通常采用 CVSS 评分结合业务影响综合定级，一般分为严重（Critical）、高危（High）、中危（Medium）、低危（Low）四档，并考虑漏洞的可利用性、是否需要认证、影响范围（是否涉及敏感数据/资产）与业务价值。报告应包含：漏洞概述、复现步骤（含请求/响应与截图）、影响分析、风险等级、修复建议（具体到代码、配置或补丁）、以及复测验证方式。修复建议应具体可执行，例如"使用参数化查询替代字符串拼接""升级 XX 组件至 X.Y.Z""为登录接口添加速率限制"。分级与建议要让非安全背景的开发与决策者能理解并优先处理高危项。

解析

报告的价值在于推动修复，分级要科学、建议要落地。测试者应区分"可被直接利用的高危"与"需组合条件的中危"，并给出优先修复顺序。

#

★

20. 安全日志与监控的测试，如何验证登录失败、越权尝试与敏感操作被记录，日志缺失如何作为缺陷提交？

问题

请说明如何验证登录失败、越权尝试与敏感操作被记录，以及日志缺失如何作为缺陷提交？

考察点

关键安全事件的日志记录验证
日志内容与格式的完整性
日志缺失与监控告警的缺陷化

答案

安全日志与监控测试的目标是验证关键安全事件可被完整记录。测试应：触发登录失败（多次错误密码）、越权尝试（访问未授权资源）、敏感操作（修改权限、导出数据、删除用户）等事件，然后核对日志中是否记录了时间戳、用户、IP、操作对象、结果等关键字段，且日志是否实时、可检索、格式统一。若日志缺失或字段不全（如未记录失败原因、未记录客户端 IP），应作为缺陷提交，说明缺失导致无法进行安全审计与事后追溯，并给出修复建议（补充日志、接入集中日志平台、配置告警规则）。同时验证监控告警是否对关键事件（如大批量登录失败）触发通知。

解析

A09 的根因是"没有日志则攻击无法被发现"，因此测试要验证日志的完整性与告警的有效性。日志缺失属于真实缺陷，应描述其对审计与应急响应的影响。