Winform应用将SQL连接字符串存储在SQL用户自定义函数中是否安全？

用户自定义函数中的密钥可见性 #

只要登录账号拥有VIEW DEFINITION权限，就可以直接读取UDF的完整明文定义，内置的密钥完全对外暴露。即便你给只读账号限制了该权限，也存在多重泄露风险：

• 明文存储在Winforms资源中的只读账号连接字符串，可以被dnSpy等常用反编译工具直接提取，恶意用户可直接用该账号登录SQL Server，通过权限绕过、漏洞利用等方式获取UDF定义。
• 哪怕你对UDF开启了SQL Server内置的加密功能，市面上也有大量成熟的解密工具可以直接还原UDF的明文代码，密钥无法做到完全保密。

该方案的安全性评估 #

这个方案无法有效保护读写用户的连接字符串，反而会引入更多安全隐患：

• 恶意用户不需要破解密钥，只要在本地Hook程序运行流程，就可以在你程序获取到读写连接串之后，直接从内存中Dump出完整的连接字符串内容，拿到读写权限。
• 相当于你的SQL Server对外提供了一个“凭只读权限兑换读写权限”的逻辑，一旦只读账号泄露，相当于直接把读写权限开放给了所有拿到只读账号的人，风险远高于普通的权限分配方案。
• 明文存储的只读账号本身就会导致所有开放给只读权限的数据面临被批量拖库的风险。

更合理的实现方案 #

客户端部署的Winforms程序本身属于不可信环境，永远不要把直连数据库的权限下发到客户端，推荐的实现逻辑如下：

• 服务端新增一层Web API接口，所有数据库操作全部由服务端API完成，Winforms客户端不需要存储任何SQL连接字符串，只需要调用API完成业务操作。
• 用户登录时向API提交账号密码，校验通过后下发Token，后续所有业务请求都携带Token进行身份校验，服务端统一做权限控制，从根源上避免连接字符串泄露的风险。
• 如果确实有必须直连数据库的场景，请给每个终端用户分配单独的数据库账号，严格按照最小权限原则分配权限，不要共用统一的读写账号，降低泄露后的影响范围。

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