企业官网建设流程全解析

若依(RuoYi)框架安全加固实战指南：从默认配置到企业级防护

第一次接触若依框架时，我被它丰富的功能模块和简洁的代码结构所吸引。但当我以安全工程师的身份审视一个使用若依框架的客户系统时，发现管理员竟然还在使用默认的admin/admin123组合——这就像给自家大门装了个指纹锁却把密码贴在门把手上。本文将分享如何系统性地为若依框架构建安全防线。

1. 身份认证安全：告别"123456"时代

若依框架默认提供的几个测试账号，已经成为黑客字典中的标配。去年某次安全评估中，我们发现83%的若依测试环境仍在使用默认凭证。以下是一份完整的认证安全改造方案：

1.1 密码策略强制升级

在application.yml中配置密码强度规则：

# 安全配置 security: password: min-length: 12 require-upper-case: true require-lower-case: true require-number: true require-special-char: true history-size: 5 # 禁止使用最近5次用过的密码

必须立即执行的操作：

• 禁用或修改所有默认账户（admin/ry/ruoyi）
• 启用BCrypt强哈希算法（若依已内置支持）
• 配置登录失败锁定策略（建议5次失败后锁定15分钟）

1.2 多因素认证集成

对于管理后台，建议增加二次验证。若依支持多种安全框架，这里以Spring Security + Google Authenticator为例：

1. 在pom.xml添加依赖：

<dependency> <groupId>com.warrenstrange</groupId> <artifactId>googleauth</artifactId> <version>1.5.0</version> </dependency>

2. 修改登录逻辑增加TOTP验证：

public boolean verifyTotp(String username, String code) { User user = userService.selectUserByUserName(username); GoogleAuthenticator gAuth = new GoogleAuthenticator(); return gAuth.authorize(user.getSecretKey(), Integer.parseInt(code)); }

2. SQL注入全面防御方案

原始文章中披露的多个注入点，其实都源于同一类问题——未严格使用预编译语句。下面是深度修复方案：

2.1 MyBatis安全编码规范

在mybatis-config.xml中强制启用严格模式：

<settings> <setting name="defaultScriptingLanguage" value="safeLanguage"/> <setting name="mapUnderscoreToCamelCase" value="true"/> <setting name="useActualParamName" value="false"/> <!-- 防止参数名注入 --> </settings>

危险操作黑名单：

• 绝对禁止在XML中使用${}拼接SQL
• 动态表名/列名必须使用白名单校验
• ORDER BY子句需要特殊处理

2.2 针对披露漏洞的紧急修复

对于文中提到的/system/role/list端点，修复后的代码应该：

@PostMapping("/list") public TableDataInfo list(@Validated Role role) { // 使用实体类接收参数 startPage(); List<Role> list = roleService.selectRoleList(role); return getDataTable(list); }

同时添加全局过滤器拦截可疑请求：

@Bean public FilterRegistrationBean<SqlInjectionFilter> sqlInjectionFilter() { FilterRegistrationBean<SqlInjectionFilter> registration = new FilterRegistrationBean<>(); registration.setFilter(new SqlInjectionFilter()); registration.addUrlPatterns("/*"); registration.setOrder(Ordered.HIGHEST_PRECEDENCE); return registration; }

3. 文件系统安全加固

任意文件读取漏洞通常源于路径校验不严，以下是多层防护方案：

3.1 路径校验白名单机制

修改CommonController中的下载逻辑：

public void downloadResource(String resource, HttpServletResponse response) { // 校验文件路径 if (!SecurityUtils.isSafePath(resource)) { log.error("非法路径访问: {}", resource); throw new RuntimeException("非法文件路径"); } ... }

配套的安全工具类：

public static boolean isSafePath(String path) { Path normalized = Paths.get(path).normalize(); if (normalized.startsWith("profile/upload")) { return true; } return false; }

3.2 文件上传安全策略

在application.yml中增加上传限制：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB file: upload: allowed-extensions: .jpg,.png,.pdf,.docx scan-antivirus: true # 启用病毒扫描

4. 会话管理与权限控制

4.1 Shiro安全配置最佳实践

若依支持Shiro和Spring Security两种方案，以Shiro为例：

@Bean public ShiroFilterFactoryBean shiroFilterFactoryBean() { ShiroFilterFactoryBean bean = new ShiroFilterFactoryBean(); bean.getFilters().put("authc", new FormAuthenticationFilter()); bean.getFilters().put("perms", new AuthorizationFilter()); LinkedHashMap<String, String> filterMap = new LinkedHashMap<>(); filterMap.put("/logout", "logout"); filterMap.put("/login", "anon"); filterMap.put("/**", "authc,perms[user]"); // 强制认证 bean.setFilterChainDefinitionMap(filterMap); return bean; }

关键配置项：

• 禁用JSESSIONID在URL中传递
• 设置合理的会话超时（建议30分钟）
• 启用HTTPS下的Secure和HttpOnly标志

4.2 细粒度权限控制方案

改造若依原有的角色权限模型：

-- 新增资源权限表 CREATE TABLE sys_resource ( id BIGINT NOT NULL, name VARCHAR(50) NOT NULL, permission VARCHAR(100) NOT NULL, method VARCHAR(10) NOT NULL, -- GET/POST/PUT等 url_pattern VARCHAR(255) NOT NULL, PRIMARY KEY (id) ); -- 角色-资源关联表 CREATE TABLE sys_role_resource ( role_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, PRIMARY KEY (role_id, resource_id) );

在代码中实现动态权限校验：

@PreAuthorize("@ss.hasPermission('system:user:edit')") @PostMapping("/edit") public AjaxResult editSave(@Validated User user) { // 业务逻辑 }

5. 安全监控与应急响应

5.1 关键日志采集配置

在logback-spring.xml中增加安全审计日志：

<appender name="SECURITY_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/security.log</file> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss} | %X{ip} | %X{user} | %m%n</pattern> </encoder> </appender> <logger name="security" level="INFO" additivity="false"> <appender-ref ref="SECURITY_LOG"/> </logger>

需要记录的关键事件：

• 登录成功/失败
• 权限变更操作
• 敏感数据访问
• 异常请求模式

5.2 漏洞扫描集成方案

建议在CI/CD流程中加入安全扫描：

# 使用OWASP ZAP进行自动化扫描 docker run -v $(pwd):/zap/wrk/:Z -t owasp/zap2docker-stable zap-baseline.py \ -t https://your-ruoyi-app.com \ -g gen.conf -r report.html

扫描策略建议：

• 每周执行一次全面扫描
• 每次发布前执行快速扫描
• 重点监控OWASP Top 10风险

6. 安全自查清单

以下是需要定期检查的核心项目：

认证安全

• [ ] 默认账户已禁用或修改
• [ ] 密码策略要求至少12位复杂度
• [ ] 启用登录失败锁定机制
• [ ] 关键操作需二次认证

数据安全

• [ ] SQL全部使用预编译语句
• [ ] 文件下载限制在指定目录
• [ ] 上传文件进行病毒扫描
• [ ] 敏感数据加密存储

会话管理

• [ ] 会话令牌使用安全属性
• [ ] 权限变更后立即生效
• [ ] 定期轮换加密密钥
• [ ] 禁用不必要的HTTP方法

监控审计

• [ ] 关键操作日志完整记录
• [ ] 日志保留至少180天
• [ ] 建立安全事件响应流程
• [ ] 定期进行漏洞扫描

在一次金融行业项目中，我们通过这套检查清单发现了7个高风险问题，包括一个可通过定时任务执行的RCE漏洞。经过3天的紧急修复，系统最终通过了银行业的严格安全审计。