0

我们有一个在 Windows Server 2003 和 IIS6 上运行的 ASP Classic 网站,它抛出间歇性运行时错误 424 object required。我们已将其跟踪到初始化对元数据库的对象引用的行,如下所示(第二行):

MetaBasePath="IIS://" & ComputerName & "/" & StorageKey & "/" & DataAccessKey
Set ConfigKey=GetObject(MetaBasePath)
DataSource=ConfigKey.Get("ODBCDataSource")
UserName=ConfigKey.Get("ODBCUserName")
Password=ConfigKey.Get("ODBCPassword")

我已经搜索了 stackoverflow(以及一般的网络)以寻找其他任何人遇到此问题的任何迹象,但一直处于空白状态。有没有人有任何想法可能导致这种情况?是否有任何与性能相关的设置来控制对元数据库的访问频率?我们可以采用任何最佳实践措施来提高元数据库访问的效率吗?我们是否正确地假设我们通过在元数据库中隐藏我们的数据库访问详细信息来做正确的事情,或者这在安全性方面是否矫枉过正?

这个问题影响了我们大约 1% 的页面点击量。

我们正在研究一系列措施,包括检查服务器软件组件的补丁级别,并可能在上述代码周围添加一个循环以继续尝试直到元数据库对象正确初始化,但我认为这充其量只是一个短期修复.

欢迎咨询!谢谢,克雷格。

附加信息:刚刚发现 IIS5.0 隔离模式已启用。我试图找出为什么启用它,但这可能是相关的吗?

4

1 回答 1

1

IIS 元数据库并不是为了安全,而只是为了方便。

它只是由多个虚拟服务器(IIS/ASP 应用程序)共享的数据的中央存储库。因此,如果您只是出于安全目的使用它,则根本不需要 Metabase。

因为:

  • 你在向谁“隐藏我们的数据库访问详细信息”?程序员?但他已经可以访问它了。分配ConfigKey.Get("ODBCPassword")给密码后,任何response.write人都会显示它。即使在 中完成global.asa,您也必须在某个地方将其转换为连接字符串(或将其存储在Application变量中),以便.asp页面可以创建数据库连接对象。在元数据库和对象创建之间的某个时刻,他将有权访问连接属性。

  • 甚至不要考虑global.asa通过在应用程序变量中创建连接对象并将对象本身存储在应用程序变量中来防止这种情况。(因此隐藏了程序员可访问的文件的创建)。这不仅会杀死连接池,还会对性能造成巨大的负面影响。

如果您担心 ASP 页面的数据库安全性,我建议您采用以下方法:

  • 为网站访问创建不同的数据库用户,但权限非常有限。表示 SELECT、INSERT、UPDATE、DELETE 和 EXECUTE(存储过程)。没有 DROP、CREATE、ALTER 等。这样,任何“密码泄漏”或“程序员滥用”都不会严重损害数据库。具有完全权限的“管理员”用户密码永远无法在网站的任何地方访问(或使用)。

  • 创建一个 ActiveX(或 COM、DCOM)DLL 来包装连接设置。它可以用 C#、VB.NET 甚至经典的 VB6 编写。它将从另一个(安全且网络无法访问的)服务器文件中读取登录名和密码,创建连接对象,并将其直接传递给 ASP。

所以不要使用:

set objConn = Server.CreateObject("ADODB.Connection")

ASP 页面将使用:

set objConn = Server.CreateObject("MYCLASS.Connection")

配置文件本身甚至可以被加密,因为解密算法将存储在编译后的代码中,而不是纯文本 ASP 文件中。

也就是说,我并不是说元数据库没用。它仍然是存储数据的好地方,因为:

  • 无需更改任何代码行即可更改数据

  • 几个网站可以共享数据,即使每个网站都有自己的独立应用程序

  • 集中式数据总是比分散在文件系统中的配置和包含文件更容易维护

  • 用户/NTFS 许可可以设置为只有授权人员才能更改数据,但网站用户(和 ASP 开发人员)只能读取数据

也就是说,“受限数据库用户”+“COM 类连接包装器”是我合作过的大多数公司使用的方法。当然,那些关心安全的人。其他人只是使用“在 global.asa 中硬编码然后存储在应用程序变量中的连接字符串”。

于 2011-03-04T17:19:22.453 回答