Jump to content

[SOLVED] Prevent SQL injection in ODBC and MS Access? Help!


Recommended Posts

I'm on a GoDaddy Windows hosting using PHP and MS Access.

 

It is well documented how to prevent SQL injection with MySQL, but how do one prevent SQL injection with ODBC and MS Access?

 

Any suggestions would be much appreciated. Seems like Access with PHP is fairly rare and not much information on the net is written about it.

Nearly all of the injection prevention is handled by php, not the database, so it shouldn't matter if you are using MySQL or Access.

 

Many times authors will recommend mysql_real_escape_string...you can use addslashes almost as effectively with ODBC since there is no equivalent, assuming magic_quotes_gpc isn't turned on.

 

http://www.php.net/addslashes

Is there not different vulnerabilities depending on the database and how it interprets certain characters though?

 

Anyhow, after using addslashes() to insert data into databse do you use stripslashes() to return to normal state?

Is there not different vulnerabilities depending on the database and how it interprets certain characters though?

 

Anyhow, after using addslashes() to insert data into databse do you use stripslashes() to return to normal state?

 

The data would be inserted in it's normal state.

 

For example, if you put in the following:

 

This is a string.  This is one with a \'.

 

It would be put into the database as:

 

This is a string.  This is one with a '.

 

Thus, when extracting you wouldn't need to convert anything ;p.

With MS SQL (and I suspect the same may also be the case with MS Access) you cannot escape quotes with a "\" as you do with MySQL.

 

You have to replace the single-quote with two single quotes, so where in MySQL you have

INSERT INTO table (name) VALUES ('O\'Reilly')

 

with MS you have

INSERT INTO table (name) VALUES ('O''Reilly')

So to summarize:

 

1. Remove all characters of the type:  * @ ! = & (){};'"`~/-+ or more accurately, only allow certain characters, but make sure those are not in the set of allowable characters

 

2. use htmlentities() and html_entity_decode()

 

3. use urlencoding() and urldecoding()

 

I'm not sure I understand why 2) and 3) above prevents SQL injection attacks?

 

Why do PHP not have something like mysql_real_escape_string() for Access? Certainly would be easier....

So to summarize:

 

1. Remove all characters of the type:  * @ ! = & (){};'"`~/-+ or more accurately, only allow certain characters, but make sure those are not in the set of allowable characters

 

So,

- No email addresses allowed

- Don't deal with any companies with names like "Marks & Spencer" , "Saachi & Saachi" or "Ford(UK) Ltd"

- Don't have any Irish contacts with names like O'Brien, O'Reilly etc

- Don't have any contact with those people like Tim Brooke-Taylor with hyphenated surnames

- And never any mathematical equations

So,

- No email addresses allowed

- Don't deal with any companies with names like "Marks & Spencer" , "Saachi & Saachi" or "Ford(UK) Ltd"

- Don't have any Irish contacts with names like O'Brien, O'Reilly etc

- Don't have any contact with those people like Tim Brooke-Taylor with hyphenated surnames

- And never any mathematical equations

 

To be honest, the reason I summarized those was that none of them seemed the correct way to handle it. In practice, one should not rely on a function intended for a different purpose be used for another purpose simply because it has the correct effect.

 

Thus, I think if I can get stored procedures to work it would  solve all these issues in one go. I believe this is the proper way of handling SQL injections in general.

 

It is just that PHP is a complete hack as a language and it isn't clear when and where you can use functions because frequently have caveats. Simply put, even after extensive testing I do not feel confident about my code.

Barand,

 

I'm getting pretty frustrated with PHP. It is the bane of my existence as I cannot stand the language. It is a love hate relationship. I love the fact that there is so much support for it, unfortunately the language in my personal opinion is terrible.

 

Anyhow, I have been unsuccessful in figuring out how to use stored procedures in MS Access using PHP. Can you or anyone help me out on how to sanitize the input for Access?

 

It should have been as easy as applying a function to the argument... here I am spending hours digging up information.

 

I would really appreciate it if anyone could help me. #!@$!@$@#%#@Q%#@TW$%^%&^%*$^#$#@%%@$!@

 

 

There are these functions

 

http://www.php.net/odbc_prepare

http://www.php.net/odbc_execute

 

for calling stored procedures. I do not know if their use is supported at the other end by Access

Barand,

 

Unfortunately, I'm not as familiar with stored procedures and could not get it to work. I read on a web page that Access do not support stored procedures, but who knows....

 

What things should I escape or disallow other than single quotes?

my usual sanitising function is

 

<?php
function clean($data)
{
    $res = get_magic_quotes_gpc() ? stripslashes($data) : $data;   
    $res = strip_tags($res);
    $res = mysql_real_escape_string($res);
    return $res;
}

 

I strip tags to prevent javascript redirects etc.

 

For Access, assuming I am right about the double single quote,

 

<?php
function clean($data)
{
    $res = get_magic_quotes_gpc() ? stripslashes($data) : $data;   
    $res = strip_tags($res);
    $res = str_replace ("'", "''", $res);
    return $res;
}

 

So when the data is posted from a form

 

<?php
foreach ($_POST as $k=>$v)
{
     $$k = $clean($v);
}

The data in the db should be OK

 

Input : It's

 

Query : INSERT INTO table (word) VALUES ('It''s')

 

Stored as : It's

 

SELECT word FROM table --> It's

 

echo $row['word'] --> It's

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.