如何防范Jar反编译泄露远程MySQL数据库连接凭证？

核心原则：完全不信任客户端运行环境，所有敏感逻辑、凭证全部放在服务侧可控环境中，客户端仅作为渲染和操作输入的终端

1. 改造中间层接口，彻底收口查询能力 #

你之前尝试的中间层方案的核心漏洞在于接口是通用型的，用户反编译后可以模拟调用任意查询。需要把接口做完全的业务化收口：

• 服务端仅暴露场景化的窄接口，每个接口对应固定的SQL逻辑，完全禁止客户端传入原生SQL、表名、字段名类参数
• 仅允许客户端传入业务过滤参数（比如订单ID、用户所属部门），服务端对所有传入参数做严格的格式校验、范围校验，超出权限的请求直接拦截
• 接口返回数据提前做字段裁剪，仅返回该场景下用户需要的字段，无关敏感字段全部在服务侧过滤完成后再返回

2. 增加全链路身份认证和权限管控 #

• 所有客户端用户必须完成身份认证后才能使用服务，推荐使用账号密码+二次校验（短信/令牌）的方式，登录成功后下发有效期可控的JWT/会话令牌，所有接口请求必须携带有效令牌
• 服务侧给每个用户分配最小可用权限，比如普通用户仅能查询自己关联的数据，管理员才能查看全量数据，所有接口请求先做权限校验再执行逻辑
• 全量记录用户的接口请求日志，包含请求参数、返回数据量、请求时间、IP地址，短时间高频调用、参数异常等可疑请求直接触发账号/IP封禁规则

3. 数据库侧额外加固 #

• 中间层服务连接MySQL使用单独的受限账号，该账号仅分配必要的操作权限（比如仅开放SELECT权限），且仅允许中间层服务的固定IP访问，禁止其他IP连接数据库
• 数据库开启审计日志，记录所有SQL执行请求，发现异常SQL直接触发告警和阻断
• 敏感数据（比如手机号、身份证号、金额）在数据库中存储时做加密处理，中间层返回给客户端之前提前做脱敏处理

4. 客户端侧辅助加固（仅提升攻击成本，不作为核心安全依赖） #

• Jar包做代码混淆、加壳处理，提高反编译和逻辑分析的成本
• 客户端和中间层的通信全程使用HTTPS，避免传输过程中数据被窃听或篡改

你之前的三个方案的核心问题都是把敏感能力暴露给了不可信的客户端环境：直接存凭证相当于把数据库钥匙直接交给用户，加密存储配置相当于把带锁的钥匙和开锁密码一起交给用户，通用中间层接口相当于给用户开了可以随意进出的门。新方案把所有凭证、核心逻辑、权限校验全部放在你可控的服务端，就算用户反编译了客户端，也只能调用你开放的、带严格权限控制的窄接口，拿不到超出权限的数据，更无法获取数据库凭证。

内容的提问来源于stack exchange，提问作者Jaremy