上传的access数据库-运行SSIS和病毒漏洞
我创建了一个流程,其中(注册)用户可以通过 ASP.NET Web 表单将(在客户端和服务器端验证之后)(使用非常不常见的扩展名压缩)访问数据库上传到我的服务器,该表单将位于一个不错的安全位置,直到晚上安排的 SSIS 包出现,将相关数据从访问数据库传输到 SQL 服务器。
之后,我的访问数据库被删除。该数据库不会有其他执行。服务器上未安装 Access。
当然,我已经做了研究,但是我是否引入了 SSIS 可能触发的漏洞(例如访问数据库内的脚本?)?
先感谢您。
I have created a process where a (registered) user can upload (after client-side and server-side validation) a (zipped with a very uncommon extension) access database to my server through an asp.net webform, that will sit in a nice secure location until a scheduled SSIS package comes along at night, to flow relevant data from the access db to the sql server.
After that, my access db is deleted. There will be no other execution of that db. Access is not installed on the server.
I've done research, of course, but am I introducing a vulnerability (script inside the access db for instance?) that SSIS might trigger?
Thank you in advance.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
SSIS 可能使用 ODBC 或 OLEDB 来获取 Access/Jet/ACE 数据库中的数据,因此没有任何东西可以执行任何代码 - ODBC 和 OLEDB 除了数据和可能在其中执行的所有危险函数之外一无所知。 SQL 语句被阻塞。
因此,如果没有安装 Access,这里就不存在真正的危险。如果您担心存在,可以在打开文件之前使用 DAO 处理该文件,并删除 QueryDefs 集合和 Modules 文档集合中的所有内容。或者,您可以使用缓冲数据库,只导入数据表,然后将其传递给 SSIS。
但我真的不认为 SSIS 除了首先关注数据表之外什么都没有。
顺便说一句,从来没有任何病毒或漏洞通过 Access 传播,因此对 Access 漏洞的担忧被夸大了(结果是,宏被阻止、沙箱模式以及从 A2007 开始,给最终用户带来了巨大的不便)需要定义受信任位置)。
SSIS likely uses ODBC or OLEDB to get to the data in the Access/Jet/ACE database, so there is nothing there to execute any code -- ODBC and OLEDB know nothing about anything but data and all the dangerous functions that could be executed in SQL statements are blocked.
So, without Access installed, no, there's no real danger here. If you're concerned that there is, you could process the file with DAO before you open it and delete everything in the QueryDefs collection and in the Modules document collection. Or, you could use a buffer database where you import nothing but the data tables, and then pass that to SSIS.
But I don't really think SSIS is looking at anything but the data tables to begin with.
BTW, there has never once been any virus or exploit that has been propagated via Access, so the concerns over Access vulnerabilities are vastly overblown (with massive inconveniance to end users as a result, with blocked macros, sandbox mode and from A2007 on, the need to define Trusted Locations).
我同意大卫的观点(尽管使用“从不”这个词总是危险的!)。您可能需要考虑的另一件事是让在上传之前压缩数据库的人员使用每个用户特定的密码对 zip 文件进行加密。
实际的加密不一定必须特别强,尽管如果您的通信遭到黑客攻击,它会有所帮助:关键是它可以识别发起 Access 上传的人。如果 SSIS 进程尝试依次使用每个已知密码打开它,但所有密码都失败,则可以认为该包已被某些未经授权的人员引入系统,因此值得怀疑。
这与其说是为了防止恶意代码,不如说是为了防止恶意数据进入您的系统。
迈克
I'd agree with David (although using the word "never" is always dangerous!). One extra thing you might consider is having the person who zips up the database prior to uploading apply encryption to the zip file with a password specific to each user.
The actual encryption doesn't necessarily have to be particularly strong, even, although it would help if your communications were being hacked: the point is that it serves to identify the person who originated the Access upload. If the SSIS process tries to open it with each known password in turn and fails with all of them then the package can be considered to have been introduced into the system by some unauthorised person and therefore be suspect.
This is less to prevent malicious code and more to prevent malicious data being entered into your system.
hth
Mike