扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
使用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语法错误信息。
而我在处理时并没有对SQL进行真正的加密,而是在TClientDataSet的CommandText中包含了一特定的字符串作为钥匙,而如果服务器得到请求后在CommandText中没有找到这一钥匙则返回“Missiong SQL property”异常。如果服务器得到了这一钥匙,则将这一钥匙从CommandText串中移除后交给TProvider进行处理。
实现:
听上去好像很玄,但实现起来比较简单:
我这里简单说说对SQL串的加密方法:
打开Provider单元,找到TDataSetProvider的SetCommandText方法。
你应该明白了吧。。。
还可以这样写:
var commandt:string;
begin
if CommandText='' then Exit;
if Copy(Commandtext,1,8)<>'minercxy' then Exit;
commandt:=Copy(CommandText,9,length(CommandText)-8);
if not(poAllowCommandTet in Options) then
DatabaseError(SCannotChangeCommandText);
CheckDataSet;
IProviderSupport(DataSet).PSSetCommandText(CommandT);
end;
发布问题,编译Provider单元并将Provider.dcu文件和并入应用服务器目录中,编译应用服务器。这样Tclientdataset必须提供'minercxy'+'select * from ...' 这样的命令才能被服务器承认。
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者