Can "SQL Injection Attack" happen to Microsoft Access 2000? RRS feed

  • Question

  • User-1807502098 posted
    I have a ASP/VB Scripts login page with Access 2000 as backend. I read several articles about the SQL Injection Attack on SQL Server. But none of them talked about anything specific to Access. I found that using "--" or ";" can not inject SQL to my login processing code. But I can not rule out all the possibilities. Can "SQL Injection Attack" happen to Microsoft Access 2000? Thanks.
    Thursday, May 4, 2006 12:08 PM

All replies

  • User-687875035 posted

    A SQL injection attack can happen whether or not the database is SQL, Access, Oracle, MySQL, or whatever. The idea behind this type of attack is when you use SQL strings within your code like:

    myVar = txtValue.Text

    mySQL = "SELECT * FROM MyTable WHERE FieldName = '" & myVar & "'"

    This string is then passed to your backend database regardless of the vendor or type. If the attacker enters in valid SQL code into your string. This occurs when you allow data to be entered directly by the user as in the example above where we have a textbox and the attacker then enters in some SQL code. This is then passed in the code behind to your database. As you can see, it doesn't matter if the database is SQL, Access or whatever, it is still passing the string to your database. In addition, this type of attack is not only independent of the database, but it is also independent of the code being used. This attack can occur using ASP.NET, ASP classic, PHP, or anywhere you're passing SQL strings to a backend database.

    Thursday, May 4, 2006 2:31 PM
  • User-1807502098 posted

    Thanks for the reply. I follow the example code in this link try to attack myself.


    but, for example I used correct Login ID and password with     ' or 1=1 --

    It is unable to login to my account. This makes me think that Access does not teat words after "--" as comments. Am I right? So what would be "--" equivalent symbol to mark comments in Access SQL?

    Thursday, May 4, 2006 3:11 PM
  • User-1853252149 posted

    That's correct, Access has different syntax on some items.  But SQL Injection can still occur.  Parameterized queries are probably the best solution, or in Access a saved parameter query.  Googling "Bob Barrows saved parameter query" will get you all kinds of links.  Bob is a Microsoft MVP who is very fluent in Access and a great resource for stopping injection attacks in Access.


    Thursday, May 4, 2006 4:10 PM
  • User-687875035 posted
    That really doesn't mean anything. It could mean you're trapping single quotes in the code and doubling up on them. It has nothing to do with Access, it has to do with how your code is handling the single quotes in the code behind. It may be that your code is using parameterized queries or whatever. Without seeing the code, I don't know. You're using one example of SQL injection pulled from an article. SQL injection is more than just that. They could enter in just  ' or '1'='1 without the "--" and the statement would evaluate to true in Access.

    Here's an example of some Access SQL Injection where you could actually shell out to the command line:

    |SHELL("cmd.exe /c dir > c:\test.txt")|

    All it takes is a knowledge of the underlying database language, and you can basically do anything you want.
    Thursday, May 4, 2006 4:11 PM
  • User-1853252149 posted

    Oh, and as an afterthoyught, you should always use parameterized SQL or saved parameter queries/stored procedures in your code.  At the least you can improve data integrity when you only allow data you want in, and at it's best you prevent the majority of common attacks.


    Thursday, May 4, 2006 4:12 PM
  • User-1807502098 posted
    My sql statement is just like that shown in the article. I tried other examples in the article and they passed as well. No injection occurs. My app is a Classic ASP / VB Script application. There is no code-behind (.NET thing) involved and Access don't support stored procedures. To be on the safer side, let me check out Bob's resource to see if I can use parameterized SQL with VBScripts. I will be back.
    Thursday, May 4, 2006 4:38 PM
  • User-823196590 posted

    ... and Access don't support stored procedures.

    Not literally, but you can use stored queries ...

    Thursday, May 4, 2006 6:02 PM
  • User-1807502098 posted

    I followed the Bob Barrows' code sample in the following link.


    My parameterized query now work like this.

      sSQL= "SELECT * FROM user WHERE Login_ID = ? and Pass_Code = ?" 

     Set conn = CreateObject("ADODB.connection")
     conn.Open myConnectionString
     set cmd=createobject("adodb.command")
     set cmd.ActiveConnection=conn
     Set RecordSet1 = cmd.Execute( ,arParms)

    Now, the code works and I am able to login. But, I am still not sure if Access will convert the parameters into text and make up an ad hoc query to execute. In order words, I don't know what's the difference at run time between ad hoc query and parameterized query. Will my parameterized query shown above guarentee the prevention of sql injection attack? Thanks.

    Friday, May 5, 2006 3:23 PM
  • User-1853252149 posted

    There are no guarantees in life, but you should be more secure.


    Friday, May 5, 2006 3:35 PM
  • User-1807502098 posted
    I think I am trying to understand why using parameters will make it safer. If the password parameter "?" was replaced with injected text such as " 'or 1=1-- " at run time by ADO, it should execute the sql just like an ad hoc text query, and the attack should still occur. I guess I am trying to know what ADO will do differently when it is a parameterized query as compared with the case of an ad hoc text query.
    Friday, May 5, 2006 6:13 PM
  • User1985048319 posted
    Would URL mapping of some kind not help prevent sql injections, I know its not that good a fix but you would at least conceal you're actions to a point when using url variables as parameters in sql queries.
    Saturday, May 6, 2006 7:18 AM
  • User-1853252149 posted

    URL mapping won't make a difference.  HTMLEncode anything you insert into the database would, escaping characters would, paraemterized queries an stored procedures would. Using a less privelegd account for DB access would.  Remove stored procedures that would allow command acces would. But focusing on simply SQL injection won't help you anyway.  The number of sites hacked through SQL injection techniques is minimal compared to every other attack out there.


    Saturday, May 6, 2006 7:27 AM