OWASP Top 10 与 Java 防御

• 输出编码的 Java 实现
• CSP 响应头配置
• HttpOnly Cookie 设置

XSS 在 Java 中的防御分三层。输出编码：在渲染不可信数据时按上下文转义——用 HtmlUtils.htmlEscape（Spring）或 JSP 的 fn:escapeXml、模板引擎自动转义（Thymeleaf/FreeMarker 默认转义）对 HTML 实体编码；JS/属性/URL 上下文需分别用对应编码器（如 OWASP Java Encoder 的 Encode.forHtml/forJavaScript/forUriComponent）。CSP：通过响应头 Content-Security-Policy 限制脚本来源，如 default-src 'self'; script-src 'self'，Spring Security 可配置 headers(headers -> headers.contentSecurityPolicy("..."))。HttpOnly Cookie：设置 Cookie 的 HttpOnly 标志，使 JS 无法读取会话 Cookie，Spring Security 的 Session Cookie 默认 HttpOnly，自定义 Cookie 用 Cookie.setHttpOnly(true)。三者协同：输出编码治本（消除注入）、CSP 兜底（阻断脚本执行）、HttpOnly 保护会话数据（降低窃取后果）。工程上还应输入白名单消毒（富文本用 OWASP Java HTML Sanitizer）。注意 DOM 型 XSS 需在 JS 层正确处理，服务端编码不一定覆盖。

本题考察 XSS 的 Java 防御。核心是"输出编码 + CSP + HttpOnly 三层"。回答应点出具体 Java API 与配置。

• 数据加密（静态/传输）
• 字段脱敏
• 日志脱敏与安全

敏感数据泄露防护覆盖数据全生命周期。加密：传输用 TLS（HTTPS）；静态存储用对称加密（AES-GCM）加密敏感字段（如身份证、手机号），数据库列加密或应用层加密；密钥用 KMS/Vault 管理。脱敏：对外展示时对敏感字段脱敏（手机号 138****1234、姓名 张*），用注解 + 序列化器（Spring 自定义 @JsonSerialize 或脱敏工具）实现，规则可配置。日志安全：日志中禁止记录敏感明文（密码、token、身份证、完整卡号），用脱敏工具过滤日志；日志框架（Logback）配置脱敏过滤器；避免把堆栈/请求体全量打日志；日志集中存储需权限控制与加密。工程上：加密区分"可还原"（业务加密，可解密）与"不可还原"（密码哈希）；日志脱敏用正则/注解替换；敏感字段在入库、日志、接口出参三层都做处理。合规上遵循最小化收集、脱敏、加密要求。注意：加密与脱敏是不同手段——加密保证可逆安全，脱敏保证不可逆展示。

本题考察敏感数据泄露防护。核心是"加密（传输+静态）+ 脱敏 + 日志安全"。回答应点出三层防护。

• 密码安全存储（慢哈希加盐）
• Session 管理（固定、过期、轮换）
• 认证最佳实践

认证失效源于弱密码存储、会话管理缺陷、凭据泄露等。Java 防御：密码哈希——用 BCrypt/Argon2 加盐慢哈希存储，不用 MD5/SHA-256 明文哈希；用 DelegatingPasswordEncoder 支持升级；登录接口防爆破（限流、验证码、指纹）。Session 管理——Session ID 用 SecureRandom 生成、登录后轮换（防会话固定）、设置合理过期（空闲/绝对超时）、Cookie 加 HttpOnly/Secure/SameSite、登出时失效 Session 并清除 RememberMe。认证最佳实践——支持多因素认证（2FA）、密码强度校验、定期强制改密、凭据安全传输（HTTPS）、防账号枚举（统一错误提示）、会话并发限制。Spring Security 提供 PasswordEncoder、sessionManagement、rememberMe、csrf 等开箱能力。工程上：认证失败记录并限流、敏感操作二次认证、异常登录检测。整体是"强凭证 + 安全会话 + 防御爆破"。

本题考察认证失效防御。核心是"密码慢哈希 + 会话管理（固定/过期/轮换）"。回答应点出 Spring Security 能力。

• Spring Security 的 headers 配置
• 各安全响应头
• 默认与自定义

Spring Security 默认启用一批安全响应头，可通过 headers() DSL 配置。示例：HSTS——headers(headers -> headers.httpStrictTransportSecurity()...)（强制 HTTPS，默认仅 HTTPS 请求时生效）；X-Frame-Options——headers(headers -> headers.frameOptions().deny()/sameOrigin())（防点击劫持）；CSP——headers(headers -> headers.contentSecurityPolicy("default-src 'self'; script-src 'self'"))（内容安全策略）；Referrer-Policy——headers(headers -> headers.referrerPolicy(ReferrerPolicyHeaderWriter.ReferrerPolicy.STRICT_ORIGIN_WHEN_CROSS_ORIGIN))；其他还有 X-Content-Type-Options（contentTypeOptions）、Cache-Control（cacheControl）等。默认值：Spring Security 默认启用 X-Content-Type-Options、X-Frame-Options、HSTS（HTTPS 时）、Cache-Control 等。配置原则：先理解各头的作用，再按业务需要开启/调整；HSTS 需在 HTTPS 环境开启；CSP 需谨慎（过于严格可能影响第三方资源）；X-Frame-Options 与 CSP frame-ancestors 可并用。也可自定义 HeaderWriter 添加任意头。

本题考察安全响应头配置。核心是"Spring Security headers() DSL 配置各安全头"。回答应点出各头与默认值。

• 各类注入的原理
• 参数化/白名单/编码
• 最小权限

注入攻击的本质是"数据与代码未分离"。SQL 注入——用 PreparedStatement 参数化、MyBatis 用 #{}、ORM 参数化，杜绝字符串拼接；LDAP 注入——对 LDAP 过滤器输入做转义（org.springframework.ldap.core.LdapEncoder 或正确转义 filter 特殊字符），或尽量用参数化 LDAP 查询、白名单校验 DN；命令注入——禁止用用户输入直接拼 shell 命令，用 ProcessBuilder 参数数组（不经 shell 解析）替代 Runtime.exec(String)，并对命令与参数做白名单校验；表达式/模板注入——限制 SpEL/模板引擎的输入；路径注入——规范化校验路径。通用方案：参数化/预编译（把数据作为参数而非代码）、白名单校验（输入必须匹配合法模式）、正确的编码/转义（按目标上下文转义）、最小权限（数据库账号最小权限、操作系统账号最小权限）、禁用危险函数（如禁止 shell 拼接）。防御原则是"数据与代码分离 + 输入校验 + 最小权限"。

本题考察注入攻击防御。核心是"参数化/白名单/编码 + 最小权限，数据与代码分离"。回答应点出各类注入的针对性防御。

• XSS 防御（输出编码/CSP）
• CSRF 防御（CSRF Token）
• 两者关联

XSS 与 CSRF 是两类不同攻击，防御各异。XSS 防御：输出编码（用 HtmlUtils/OWASP Java Encoder 按上下文转义）、CSP 响应头（限制脚本来源）、HttpOnly Cookie（防会话窃取）、输入白名单消毒。CSRF 防御：Spring Security 默认启用 CSRF 防护（CsrfFilter），通过 HttpSessionCsrfTokenRepository 生成 CSRF Token 存于 Session，表单/请求携带 token，服务端比对；前后端分离可用 CookieCsrfTokenRepository（token 存 Cookie + 请求头双重提交）；或用 SameSite=Lax Cookie 从源头减少跨站携带。两者关联：XSS 与 CSRF 常协同——XSS 可窃取 CSRF Token 或 Cookie，从而绕过 CSRF 防护；因此防 XSS（HttpOnly、输出编码）也是防 CSRF 的重要前提。实现：Spring Security 的 csrf() DSL 配置，模板自动注入 _csrf token；@EnableWebSecurity 下默认启用。注意：无状态（JWT in Authorization header）场景通常不需要 CSRF（凭据不在 Cookie）；但若用 Cookie 会话则必须启用 CSRF。

本题考察 XSS+CSRF 的 Java 防御。核心是"输出编码/CSP 防 XSS，CSRF Token 防 CSRF，XSS 是 CSRF 的前提防护"。回答应点出两者关联。

• XXE 原理
• 禁用 DTD/外部实体
• 各解析器的安全配置

XXE 攻击利用 XML 解析器加载外部实体，读取本地文件、SSRF、DoS。Java 防御：禁用 DTD——对不需要 DTD 的场景，设置 disallow-doctype-decl=true 从源头禁用外部实体；禁用外部实体——若需 DTD，关闭 external-general-entities 与 external-parameter-entities；同时设置 FEATURE_SECURE_PROCESSING、禁用 schema 外部加载、XInclude 与 expandEntityReferences。需覆盖所有 XML 解析器：DocumentBuilderFactory、SAXParserFactory、TransformerFactory、XMLInputFactory（StAX）、XPath 等各自配置。防御原则：优先完全禁用 DTD（若业务不需），其次禁用外部实体；避免使用可能默认加载外部实体的解析方式。若业务用 JSON 替代 XML 可彻底规避。工程上应统一封装安全的 XML 解析工厂，避免各处重复配置遗漏。

本题考察 XXE 的 Java 防御。核心是"禁用 DTD + 关闭外部实体 + 覆盖所有解析器"。回答应点出各解析器配置。

• ObjectInputFilter
• 白名单/黑名单
• 替代序列化方案

反序列化漏洞利用 ObjectInputStream.readObject() 触发 gadget 链执行任意代码。Java 防御：ObjectInputFilter——通过 ObjectInputStream.setObjectInputFilter 或 GlobalSerializationConfiguration 设置过滤器，限制可反序列化的类（白名单 accept、拒绝 reject），拦截危险类（如 InvokerTransformer、TemplatesImpl）；白名单——只允许反序列化受信任的类集合，比黑名单更安全（黑名单易遗漏）；替代方案——避免直接使用 Java 原生序列化，改用 JSON（Jackson）、Protobuf 等安全格式，或使用受控的序列化框架。其他——不反序列化不可信数据、隔离反序列化数据源、用 ObjectInputFilter 限制深度/数组大小防 DoS。Jackson/Fastjson 多态反序列化也需白名单（@JsonSubTypes、autoType 关闭）。核心原则：最小化可反序列化类型面 + 不信任不可信数据。工程上：优先用 JSON，必须用原生序列化时配置 ObjectInputFilter 白名单。

本题考察反序列化防御。核心是"ObjectInputFilter 白名单 + 替代方案（JSON）"。回答应点出白名单优于黑名单。

• 关闭默认弱配置
• 避免信息暴露
• 最小化功能面

安全配置错误源于"不安全的默认配置 + 过度暴露 + 启用无必要功能"。Java 防御：默认配置——检查并加固框架默认配置（如关闭开发模式、调试、Restart 端点）、禁用弱 TLS 协议/密码套件、数据库默认账号密码必须修改、关闭不必要的自动配置；暴露信息——避免错误信息泄露内部细节（堆栈、版本、SQL、内部路径），用统一异常处理返回泛化错误，日志不打印敏感信息，/actuator 端点、/swagger 等仅在受控环境暴露；不必要功能——关闭未使用的功能/端点/组件（如不用的 starter、示例、debug 页面），最小化攻击面（禁用不必要的 HTTP 方法、CORS、上传目录执行权限）。其他——安全头齐全、依赖版本最新、配置文件的 secret 不硬编码。工程上：用安全基线检查（如 Spring Security 默认安全头、OWASP 配置检查）、定期审计配置、通过配置中心/环境差异化。核心是"最小化攻击面 + 加固默认配置 + 隐藏内部信息"。

本题考察安全配置错误防御。核心是"加固默认配置、避免暴露、最小化功能面"。回答应点出常见配置错误。

• 审计日志
• 入侵检测
• 异常告警

日志与监控不足导致安全事件无法及时发现。Java 防御：审计日志——记录认证、授权、敏感操作、异常等安全事件（操作人、时间、结果、上下文），结构化、集中存储、保留周期，支持追溯；入侵检测——监控异常行为（登录失败爆发、越权尝试、异常流量、地域异常、敏感操作异常），用规则/模型识别攻击特征；异常告警——对异常事件实时告警（登录失败阈值、403 爆发、异常接口调用、SQL/数据异常），接入监控平台（Prometheus、ELK、Sentry），分级告警并联动响应。工程上：AuthorizationEventPublisher 记录授权事件、@EventListener 记录业务事件、AOP 记录操作日志、指标埋点（失败率、异常率）；日志与告警结合，建立安全运营闭环（检测→告警→响应→复盘）。核心是"看得见（日志）+ 发现得了（检测）+ 响应快（告警）"。

本题考察日志与监控不足防御。核心是"审计日志 + 入侵检测 + 异常告警"。回答应点出安全运营闭环。

• Java 原生序列化风险
• 白名单与替代方案
• 实践建议

Java 原生序列化（ObjectInputStream.readObject()）的风险在于：反序列化时实例化对象并调用 readObject，攻击者构造恶意字节流可通过 gadget 链（如 Commons Collections、HashMap 等）触发任意代码执行、RCE、DoS。且原生序列化格式不透明、难以审计，且无法限制类型。风险缓解：白名单——用 ObjectInputFilter 限制可反序列化的类（只允许受信任类），比黑名单可靠；替代方案——用 JSON（Jackson/Fastjson 需注意多态）、Protobuf、Avro 等安全序列化格式，或使用受控的序列化框架；防御——不反序列化不可信数据、隔离数据源、限制数组/深度（防 DoS）、升级受影响库。工程建议：避免使用 Java 原生序列化，改用 JSON/Protobuf；必须用时配置 ObjectInputFilter 白名单并严格控制输入来源。对 Fastjson/Jackson 多态，用 @JsonSubTypes 白名单或关闭 autoType。核心是"最小化类型面 + 可信数据源 + 优先安全格式"。

本题考察 Java 原生序列化风险。核心是"readObject 触发链 + 白名单 + 用 JSON/Protobuf 替代"。回答应点出实践建议。

• 开放重定向原理
• 重定向目标校验
• Spring 中的防御

开放重定向漏洞源于应用根据用户可控的参数（如 redirect、next、returnUrl）进行跳转而未校验目标，导致用户被诱导到恶意站点（钓鱼）。Java 防御：校验重定向目标——只允许相对路径或白名单内的可信域名，精确解析 URL 的 host 并做白名单匹配（不能简单前缀匹配，避免 trusted.com.evil.com 绕过）；禁用危险目标——拒绝 //（协议相对）、\\、@、编码绕过、javascript: 等 scheme；使用相对路径——跳转优先用相对路径（如 /dashboard）而非完整 URL；Spring 防御——DefaultRedirectStrategy 可自定义校验，或手动校验后跳转；Spring Security 的 AuthenticationSuccessHandler 中的 targetUrl 也需校验。工程上：封装 validateRedirectUrl() 工具，统一校验所有重定向；对必要的完整 URL 跳转做白名单映射。核心是"重定向目标必须精确校验，禁止任意外部跳转"。

本题考察开放重定向防御。核心是"精确解析 host 白名单 + 相对路径 + 拒绝编码绕过"。回答应点出校验细节。

• 扩展名与内容校验
• 存储隔离
• 图片重编码

文件上传安全防护：扩展名校验——白名单校验扩展名（如 jpg/png/pdf），拒绝可执行扩展名（jsp/php/htm）；内容检测——校验文件内容（MIME 魔术字节、真实解析），不能只信扩展名或 Content-Type，防止伪造扩展名上传脚本；存储隔离——上传文件存到 Web 根目录之外、独立目录或对象存储，重命名为随机名（不保留用户原始文件名），避免直接从 Web 访问执行路径；图片重编码——对图片类文件重新解码再编码（如用 ImageIO 重新绘制），去除嵌入的恶意载荷（如图片中的脚本、恶意元数据），并重新生成随机文件名；其他——限制文件大小（防 DoS）、限制类型、文件名清洗（防路径穿越 / 非法字符）。Spring 中 MultipartFile 需校验 getOriginalFilename、getContentType、getSize、内容。核心是"类型双校验 + 存储隔离 + 重编码去载荷 + 防路径穿越"。

本题考察文件上传安全。核心是"扩展名+内容双校验、存储隔离、图片重编码"。回答应点出重编码去载荷。

• 预编译 vs 字符串拼接
• MyBatis #{} 与 ${}
• 动态 SQL 的风险

SQL 注入防御的核心是"数据与代码分离"。预编译占位符（PreparedStatement ?、MyBatis #{}）把用户输入作为参数绑定，由数据库当作数据处理，安全；字符串拼接直接拼接用户输入进 SQL，攻击者可控 SQL 语义，注入风险。MyBatis 中 #{} 生成预编译占位符（安全），${} 直接字符串替换（存在注入风险），仅用于动态表名/列名/排序字段等需拼接的场景，且必须对输入做白名单校验（如枚举表名、校验列名）。此外：ORM（JPA/Hibernate）参数化较安全，但原生 SQL（createNativeQuery 拼接）或自定义 SQL 的 ${} 需警惕；动态 ORDER BY/LIKE 等场景也要用参数化或白名单。工程建议：默认全部用参数化（#{}/?），${} 用于绝对必要的动态标识符且严格白名单；对 LIKE 用 CONCAT('%', #{input}, '%') 参数化，避免拼接。核心是"永远不要用用户输入拼接可执行 SQL"。

本题考察 SQL 注入防御。核心是"预编译占位符安全、${} 有注入风险、动态标识符白名单"。回答应点出 MyBatis 差异。

• 访问控制失效风险
• 方法级安全（@PreAuthorize）
• 对象级授权

访问控制失效是未正确校验请求者权限导致的越权。Java 防御：URL 级授权——SecurityFilterChain 的 authorizeHttpRequests 按路径配置权限；方法级安全——@EnableMethodSecurity + @PreAuthorize/@PostAuthorize 用 SpEL 在方法层校验角色与对象属性，实现粗粒度（角色）与细粒度（对象归属）授权；对象级授权——@PreAuthorize("#order.userId == authentication.name") 校验资源归属，防止 IDOR；数据权限——行级/列级过滤。Spring Security 的防御要点：方法级安全需启用代理（避免自调用绕过）、注解统一放实现类、拒绝决策可审计。工程实践：所有敏感操作都做服务端授权（不依赖前端隐藏）、默认拒绝（denyAll/最小权限）、对象操作校验归属、失败时区分 403。核心是"在服务端对每个请求/操作做授权，结合 RBAC 与对象属性（ABAC）"。

本题考察访问控制失效防御。核心是"方法级安全 + 对象级授权 + 默认拒绝"。回答应点出 @PreAuthorize 与对象归属。

• 依赖漏洞扫描
• SBOM 清单
• CVE 监控与修复

使用含已知漏洞的组件（如 Log4j 的 Log4Shell）是常见风险。Java 防御：依赖扫描——用 OWASP Dependency-Check、Snyk、Trivy 等工具在 CI 中扫描依赖，识别已知漏洞（CVE），构建时阻断高危漏洞；SBOM（Software Bill of Materials）——生成依赖清单（如 CycloneDX/SPDX），记录所有组件与版本，用于漏洞追踪与合规；CVE 监控——持续监控依赖的新披露漏洞（NVD、GitHub Advisory），及时升级修复；版本管理——锁定依赖版本、定期升级、用 mvn dependency:tree 检查依赖树；安全基线——建立允许的依赖版本与漏洞阈值。工程实践：把依赖扫描接入 CI（mvn verify 前），生成 SBOM 并归档，订阅漏洞告警，重大漏洞（如 Log4Shell）立即排查升级。核心是"扫描 + 清单 + 监控 + 修复"闭环。

本题考察漏洞组件防御。核心是"依赖扫描 + SBOM + CVE 监控 + 升级修复"。回答应点出工具与闭环。

• URL 校验
• DNS 重绑定防护
• 内网地址黑名单

SSRF 防护的 Java 实现：URL 校验——解析 URL，校验 scheme（仅 http/https）、主机名、端口，拒绝危险协议（file/gopher/dict）；内网地址黑名单——解析目标 IP，拒绝内网/保留地址（如 127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.169.254 云元数据、::1 等），用 InetAddress 解析后判断；DNS 重绑定防护——DNS rebinding 攻击让域名在"校验时"指向公网 IP、在实际请求时解析到内网 IP，绕过校验；防御需在校验后、实际请求前重新解析并校验，或用固定 IP 解析、限制重定向（禁止跟随重定向到内网）、限制重定向次数、校验实际连接的 IP。其他——出网白名单（只允许访问可信域名）、禁止跟随重定向、隔离响应。实现要点：用 URI 解析而非字符串操作；解析 IP 后校验；用 HTTP 客户端（如 HttpClient）禁止重定向或自定义重定向处理。核心是"校验与实际请求一致（防 DNS rebinding）+ 拒绝内网地址"。

本题考察 SSRF 防护实现。核心是"URL 校验 + 内网黑名单 + 防 DNS 重绑定（请求前重新校验）"。回答应点出实现细节。

• OWASP Dependency-Check
• SBOM 生成
• 漏洞修复流程

安全依赖管理是持续识别与修复依赖漏洞的过程。OWASP Dependency-Check——开源依赖扫描工具，通过 NVD 等数据库比对依赖的 CVE，生成扫描报告，可在 CI 中配置失败阈值（有高危漏洞即构建失败）；SBOM——用 CycloneDX/SPDX 格式生成依赖清单，记录组件、版本、许可证，用于漏洞追踪与合规审计（Maven 可用 cyclonedx-maven-plugin 生成）；漏洞修复流程——持续监控新披露漏洞（NVD、GitHub Advisory、Snyk）→ 评估影响（是否在受影响版本、是否可达）→ 升级依赖或应用补丁 → 回归测试 → 发布；对不可升级的组件做缓解（如配置加固、网络隔离）。工程实践：把 Dependency-Check 集成到 CI（提交时扫描）、生成 SBOM 归档、告警订阅漏洞、制定升级策略与紧急响应预案（如 Log4Shell 类 0day）。核心是"扫描 + 清单 + 监控 + 分级修复"的闭环。

本题考察安全依赖管理。核心是"Dependency-Check 扫描 + SBOM + 漏洞监控修复流程"。回答应点出流程闭环。

• IDOR 与垂直越权的检测
• 对象级授权实现
• 测试与审计

水平越权（IDOR）与垂直越权的检测与防御：检测——通过安全测试（渗透测试、自动化扫描）验证：水平越权用"切换 id 访问他人资源"测试；垂直越权用"低权限账户调用高权限接口"测试；结合代码审计（检查是否在查询/更新时校验归属与角色）；运行时用授权事件审计（AuthorizationEventPublisher 记录拒绝事件）发现越权尝试。对象级授权实现——在访问每个资源时校验"当前用户是否有权访问该对象"：查询时绑定 owner（WHERE id=? AND owner_id=?）、用 @PreAuthorize("#resource.ownerId == authentication.name") 校验、或先取资源再校验归属；对列级/行级权限用数据权限过滤。垂直越权用方法级/URL 级授权（@PreAuthorize("hasRole('ADMIN')")、authorizeHttpRequests）实现。测试——为每个对象操作写授权测试（@WithMockUser 不同角色验证 403）。核心是"服务端对每个资源/操作做授权校验，不依赖前端"。

本题考察越权检测与对象级授权。核心是"检测（测试+审计）+ 对象级授权（owner 绑定/归属校验）"。回答应点出实现与测试。