jeecg3.7网站开发图解步骤：5招堵住安全漏洞

网站做好了没人访问？别急着做SEO，先检查你的站点是不是被挂马了。很多JeecgBoot 3.7开发者只盯着功能实现，忽略了底层安全，结果上线三天，后台就被植入了挖矿脚本，流量全被劫持。今天这篇jeecg3.7网站开发图解步骤，不聊虚的，直接拆解从威胁场景到加固落地的全链路，帮你把安全漏洞焊死在上线前。

威胁场景：内网穿透与越权访问

在JeecgBoot 3.7的生产环境中，最常见的威胁并非外部的大规模DDoS，而是内部逻辑漏洞被利用。根据阿里云官方文档《Web应用安全最佳实践》的数据，超过40%的Spring Boot项目安全事故源于未授权的API接口暴露。

想象这样一个场景：你的JeecgBoot项目部署在阿里云ECS上，前端通过Nginx反向代理访问后端。攻击者发现 /sys/user/queryUserList 接口没有严格的权限校验，仅凭一个默认的Token就能拉取全库用户数据。更糟糕的是，JeecgBoot的在线开发模块（Online Coding）允许动态生成表单和报表，如果配置不当，攻击者可以通过构造特殊的JSON参数，触发SSRF（服务器请求伪造）漏洞，探测内网其他微服务。

对于设计师转前端或刚接触后端的开发者来说，这种“看不见”的漏洞比页面样式错位更致命。页面丑了可以改，数据泄露了只能删库。因此，在jeecg3.7网站开发的图解步骤中，安全加固必须前置，而不是上线后的补救措施。

漏洞原理：Shiro/Spring Security配置陷阱

JeecgBoot 3.7默认使用Shiro进行权限管理（部分新版本模块开始引入Spring Security），其核心问题往往出在忽略URL的配置上。为了调试方便，开发者常在 shiro-config.yml 或代码中将 /sys/** 或 /api/** 设置为 anon（匿名访问）。

漏洞代码示例（Java）：

// 错误的配置：将所有/sys路径设为匿名，导致用户信息接口暴露
@Bean
public ShiroFilterFactoryBean shiroFilterFactoryBean() {ShiroFilterFactoryBean shiroFilter = new ShiroFilterFactoryBean();shiroFilter.setSecurityManager(securityManager());Map<String, String> filterChainDefinitionMap = new LinkedHashMap<>();// 高危：这里把/sys下的所有接口都放行了，包括敏感的用户管理接口filterChainDefinitionMap.put("/sys/**", "anon");filterChainDefinitionMap.put("/doc.html", "anon");shiroFilter.setFilterChainDefinitionMap(filterChainDefinitionMap);return shiroFilter;
}

这段代码的问题在于，/sys/user 下的登录、注册、密码重置等接口虽然需要认证，但 /sys/user/list 等查询接口也被误伤放行。攻击者无需登录，直接请求该接口即可获取用户列表。此外，JeecgBoot 3.7的在线代码生成器生成的Controller，默认继承自 JeecgController，如果未显式添加 @RequiresPermissions 注解，且Shiro配置宽松，极易造成垂直越权。

另一个高频漏洞是SQL注入。JeecgBoot的QueryGenerator在构建查询条件时，如果用户输入直接拼接到SQL片段中，而非使用参数化查询，就会留下隐患。特别是在自定义SQL报表功能中，若允许用户输入“字段名”或“排序字段”，风险极高。

防护方案：代码级与配置级双重加固

针对上述漏洞，我们需要在jeecg3.7网站开发的图解步骤中，实施“白名单+参数化”的双重防护。

修复方案一：精细化Shiro权限控制

将宽泛的 anon 替换为具体的URL白名单，并启用JWT或Session校验。

// 正确的配置：仅放行必要的匿名接口，其余强制认证
@Bean
public ShiroFilterFactoryBean shiroFilterFactoryBean() {ShiroFilterFactoryBean shiroFilter = new ShiroFilterFactoryBean();shiroFilter.setSecurityManager(securityManager());Map<String, String> filterChainDefinitionMap = new LinkedHashMap<>();// 静态资源放行filterChainDefinitionMap.put("/css/**", "anon");filterChainDefinitionMap.put("/js/**", "anon");filterChainDefinitionMap.put("/img/**", "anon");// 仅放行明确的匿名接口，如登录、注册、验证码filterChainDefinitionMap.put("/sys/login", "anon");filterChainDefinitionMap.put("/sys/register", "anon");filterChainDefinitionMap.put("/sys/captcha", "anon");// 其余所有接口强制认证filterChainDefinitionMap.put("/**", "authc");shiroFilter.setFilterChainDefinitionMap(filterChainDefinitionMap);return shiroFilter;
}

修复方案二：SQL注入参数化加固

在JeecgBoot的自定义查询中，严禁使用 ${} 拼接用户输入。必须使用 #{} 或Jeecg提供的 QueryWrapper 方法。

// 安全的查询方式：使用QueryWrapper避免SQL注入
public IPage<SysUser> queryPageList(Page<SysUser> page, String username) {QueryWrapper<SysUser> wrapper = new QueryWrapper<>();// 如果username不为空，进行模糊查询if (StringUtils.isNotEmpty(username)) {// 使用 like 方法，框架内部会进行转义和参数化wrapper.like("username", username);}// 如果涉及动态排序字段，必须通过白名单校验String orderField = "createTime"; // 默认字段if ("username".equals(request.getParameter("orderByColumn"))) {orderField = "username";}// 严禁: wrapper.orderBy(request.getParameter("orderByColumn"));return this.page(page, wrapper.orderByDesc(orderField));
}

此外，建议在Nginx层面增加一层防护。根据阿里云官方文档推荐，应在Nginx配置中限制请求头大小，并禁用不必要的HTTP方法。

# Nginx 安全加固配置片段
server {listen 80;server_name your-domain.com;# 限制请求体大小，防止恶意大文件上传client_max_body_size 10m;# 限制连接数，防止CC攻击limit_req zone=one zone=5r/s;# 隐藏Nginx版本信息server_tokens off;# 仅允许必要的HTTP方法if ($request_method !~ ^(GET|HEAD|POST)$) {return 405;}location / {proxy_pass http://127.0.0.1:8080;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}
}

检测与修复：自动化扫描与人工复核

在jeecg3.7网站开发的图解步骤中，人工审查效率低且易遗漏。建议引入自动化安全扫描工具，在CI/CD流水线中集成。

1. 静态代码分析（SAST）：使用SonarQube或Fortify扫描Java代码，重点检查 SQLInjection、XSS 和 HardcodedCredentials 规则。JeecgBoot源码中若存在硬编码的数据库密码，必须替换为环境变量或配置中心管理。
2. 动态应用安全测试（DAST）：使用OWASP ZAP或Nessus对预发布环境进行扫描。重点关注Shiro反序列化漏洞（CVE-2023-33753等），确保JeecgBoot依赖的Shiro版本在3.7.1以上。
3. 依赖漏洞检查：JeecgBoot 3.7依赖大量Spring Boot组件。使用 dependency-check-maven 插件生成SBOM（软件物料清单），比对CVE数据库。特别是 fastjson 库，若项目中使用，必须升级到1.2.83或2.0.x版本，并开启SafeMode。

发现漏洞后，修复优先级如下：

• P0（紧急）：远程代码执行（RCE）、SQL注入导致数据删除、后台登录绕过。
• P1（高）：敏感信息泄露（如用户手机号未脱敏）、XXE漏洞、CSRF。
• P2（中）：XSS存储型、信息泄露（版本号、堆栈信息）。

每次修复后，必须回归测试，确保业务功能不受影响。特别是权限控制变更，需测试不同角色（超级管理员、普通用户、游客）的访问权限，防止误拦截。

安全加固清单：上线前的最后防线

在完成上述代码和配置加固后，还需要在运维层面进行最后的安全加固。以下是jeecg3.7网站开发上线前的必查清单：

特别强调：ICP备案与SSL证书不仅是合规要求，更是信任背书。阿里云官方文档指出，未备案域名在中国大陆访问会被阻断，而HTTPS证书能显著提升搜索引擎排名和用户信任度。在jeecg3.7网站开发过程中，建议将证书自动续期脚本纳入运维体系，避免因证书过期导致全站瘫痪。

安全不是某一次加固就能一劳永逸的，它是一个持续的过程。JeecgBoot 3.7作为快速开发平台，极大地提升了开发效率，但也因为代码生成器的特性，带来了更多潜在的攻击面。作为开发者，必须在享受便利的同时，保持对底层安全的敬畏。

你踩过哪些建站的坑？评论区交流