17370845950

Java安全处理用户输入的核心是“先校验、再使用”，需后端严格校验来源、层级（格式/范围/语义/上下文）并转义，禁用前端依赖、黑名单过滤，坚持白名单与防御性编码。

Java中安全处理用户输入，核心是“先校验、再使用”，不能依赖前端验证，必须在后端做严格校验和转义。重点在于区分输入来源（如HTTP参数、JSON Body、文件上传）、明确校验层级（格式、范围、语义、上下文），并配合防御性编码手段。

基础校验：非空与类型合法性

所有用户输入默认视为不可信字符串。第一步永远是判空和类型转换保护：

• 用 StringUtils.isNotBlank() 替代 != null && !"".equals()，避免空指针和空白字符绕过
• 数字类参数不用 Integer.parseInt() 直接强转，改用 NumberUtils.toInt(str, defaultValue) 或封装 try-catch + 日志告警
• 布尔值不靠 "true".equals(input) 简单判断，使用 Boolean.parseBoolean() 并限定可接受值（如只允许 "true"/"false"，拒绝 "1"/"yes"）

格式校验：正则与白名单优先

邮箱、手机号、身份证号等有明确格式的字段，必须用预编译正则校验，且坚持白名单原则：

• 邮箱示例：^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$，注意结尾域名长度限制
• 手机号（国内）：用 ^1[3-9]\\d{9}$，不接受带区号、括号、横线的“友好格式”——前端应统一格式化，后端只认标准11位
• 绝对避免黑名单过滤（如禁用 ），攻击者总能变形绕过；只放行已知安全模式

业务语义校验：结合上下文做逻辑判断

格式正确不等于业务合法。例如：

• 用户修改密码时，“新密码”不能与“旧密码”相同，需查库比对（明文比对需脱敏处理）
• 转账接口中，“金额”必须 > 0 且 ≤ 用户可用余额，需查账务状态，不能只校验正数
• 文章标题长度限制为1–50字符，但还要过滤控制字符（\u0000–\u001F）、零宽空格（\u200B）等隐形非法字符

防御性输出与存储：防注入、防XSS、防路径遍历

校验通过后，仍需根据使用场景做安全处理：

• 拼SQL？用 PreparedStatement，绝不字符串拼接；ORM框架启用参数绑定
• 返回前端？HTML内容用 StringEscapeUtils.escapeHtml4() 转义；JSON响应确保序列化器已禁用危险类型（如 Hibernate 的 LazyCollection）
• 文件名来自用户？提取原始文件名后，用 FilenameUtils.getName() 获取纯名称，并重命名（如UUID）+ 限定扩展名白名单（如 ["jpg","png","pdf"]）

基本上就这些。校验不是越严越好，而是要贴合业务真实约束；安全不是加一层过滤器，而是每个接收点都默认怀疑、主动验证、明确处置。不复杂但容易忽略。