SQL Injecting Microsoft Access

It is widely believed that retrieving data from a Microsoft Access database using SQL Injection is more difficult than more robust databases such as MySQL or SQL Server. There are two reasons for this misconception. First, widely employed “Convert/cast Error” attacks do not yield database information in the error message.  Second, default read permission to system tables is set to “Not Allowed” which is important to retrieve vital information such as table names and column names. Often this is used as an excuse not to worry about SQL Injection in web applications with MS Access as the backend.  However, this is true if attackers only rely on using system tables to acquire information about tables and columns. What we want to point out is that it’s not necessary to access system tables to extract database information.

What if the attacker already has information about the database behind the web application and knows table names and column names. For example, if the target is a former employer or customer of the attacker he can use Blind SQL injection to extract the data.  In some cases, union queries can be appended to the SQL allowing the attacker to retrieve additional data along with the data that is supposed to be displayed the web page.

            Another case if you use database wizards, sample applications, or common open source applications as a base for your web applications, you may be exposing to an attacker as much information as he needs to extract data from your database.  Finger printing these canned applications is fairly easy and since they are open to anyone, the attacker has the blueprint of your application.  Again, the attacker could use Blind SQL Injection or union queries to extract the data.

            Even if an attacker doesn’t have access to system tables or prior knowledge of the applications database, it can always be brute forced.

            The real solution to the problem is removing SQL Injection possibilities regardless of the database being used.  Ways to protect against SQL injection are validating input parameters in your application.  Use parameterized queries to avoid appending SQL commands.  Avoid using databases created by Access wizards and sample databases.  Also, avoid using canned applications from shared hosting providers.  If you do use open source applications, obscure your database by changing the table and column names so that they are less easy to guess by an attacker.