关于MIDAS的安全问题的解决方案_Delphi教程

发布问题，编译Provider单元并将Provider.dcu文件和并入应用服务器目录中，编译应用服务器。这样Tclientdataset必须提供

'minercxy'+'select * from ...' 这样的命令才能被服务器承认。

我把'minercxy'暂且称为钥匙，钥匙可以自己进行随意设置，位数也可随意长度。当然钥匙的随机性越大安全性就越强了。

关于如果屏蔽Tclientdataset的providernames列表的问题，我在文章中也简单的写了一下，就算抛砖引玉吧。

我直接贴出来了

增强MIDAS的安全性

大家都知道，使用RemoteDataModule最令人头疼的就是安全性问题。

主要体现在：

1、远端只要知道应用服务器的端口号即可访问到应用服务器，而一旦访问到应用服务器，TClientDataSet即可获得ProviderNames列表。（观点：不让他轻易得到ProviderNames列表。）

2、一旦知道了ProviderNames列表，这就相当于将数据库暴露在外了。

例如：客户端可以通过SQL语句来对数据库进行操作了。（观点：我们的应用服务器根部不接受SQL语句。）

因为看到大家此类贴多如牛毛，又没有什么更好的解决方法，因此我发表一下我的拙见。

我对IAppServer接口进行了进一步的扩展，增强了RemoteDataModule的安全性。主要体现在：

1、客户端侦测到应用服务器的端口号可以建立与应用服务器的连接，但必须提供由TClientDataSet提供一GUID作为密码方能在设计阶段获得ProviderNames列表。此功能使得系统外部人员无法在设计阶段直接在TClientDataSet的ProviderName中直接获得应用服务器的TProvider实例。如果想通过IAppServer来获取ProviderNames列表则必须提供这一特定的GUID作为密码。

IAppServer的AS_GetProviderNames原形为

function AS_GetProviderNames: OleVariant; safecall;

扩展后的函数为

function AS_GetProviderNames(Password:WideString): OleVariant; safecall;

系统外部人员能够访问TRemoteDataModule的Provider的唯一方法就是猜测（或者成为蒙）出可能有的ProviderName直接赋值给TClientDataSet的ProviderName属性。当然这是十分困难的（只要你不是直接将datasetProvider1作为TdatasetProvider的名称）。

2、虽然恶意者可能通过其他方法（包括猜测、穷举）来获取到一个具有较高权限的TProvider，但是此步的安全特性完全将其挡在了门外。

TClientDataSet必须提供加密后的CommandText串才能得到应用服务的正确相应。因为这里的加密对象是SQL语句（一个字符串），所以可以使用n多种加密方法。如果应用服务器解密出的串为非法SQL串，会向客户端返回SQL语法错误信息。