Uploaded access database - running SSIS and virus vulnerability

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 ser开发者_高级运维ver 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.

---

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).

---

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