Forum Moderators: coopster

Message Too Old, No Replies

Preventing SQL inject commands!

protective measures.

         

dreamcatcher

12:48 pm on Mar 20, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Hi guys,

The server that my website resides on got attacked on Friday when someone ran a sql inject command on a site running an insecure script. This in turn put an <IFRAME> tag into all index pages on the server which executed viruses and spyware. This problem has now been sorted by my hosting company and the offending site has been suspended.

As I write my own scripts, I was wondering what measures I should take to prevent this happening with my own scripts? I know using mysql_escape_string has been mentioned a couple of times on this forum.

What do you guys do with your scripts to prevent this sort of thing?

Thanks for your help and advice.

:)

willybfriendly

2:31 pm on Mar 20, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I look forward to hearing from the real experts on this one. For myself, I screen user data to be sure it is in the realm of what the script was expecting, and then I trim and escape it before putting it in the DB. I set up users with the least permissions I can get away with. But, that's basic stuff and I expect the pros here will offer more thorough steps to take.

Also, I have had people attempt to play games by altering query strings at the end of URL's as well as with form data, so don't forget to filter those query strings as well.

WBF

dcrombie

3:53 pm on Mar 20, 2004 (gmt 0)



You can prevent most forms of SQL injection by having addslashes on by default and enclosing ALL variables in your SQL in single quotes.

Beyond that, mod_rewrite and URL rewriting can be used to screen invalid GET commands.

Finally, ANY data that you're going to INSERT should be parsed variable by variable.

jatar_k

5:29 pm on Mar 20, 2004 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



addslashes or mysql_escape_string on every single piece of data input from the user.

All input data should be heavily tested to ensure that it can't be used for malicious code injection.

Error messages from your db should be handled by your scripts and generalized so as not to freely offer information about your db structure to a possible attacker. This will allow them to use trial and error and get true tablenames or column names to assisst in their injection.

$_REQUEST shouldn't be used, always grab the specific superglobal array ie. $_POST, $_GET or $_COOKIE.

register_globals should be off and extract() should not be used.

Those are just a few things that come to mind.

willybfriendly

7:18 pm on Mar 20, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Can you expand on the dangers of estract()

WBF

jatar_k

8:37 pm on Mar 20, 2004 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



extract is, in essence, the same as register_globals if not used properly

extract($_REQUEST);

you have now extracted all vars from the $_REQUEST array which is comprised of GET, POST and COOKIE arrays, in that order of precedence. So GET vars are more important than POST and someone could possibly get values into your script using get.

Anything that touches, or deals with, data that the user inputs or brings external data into your scripts is always something that should be treated with caution.

dreamcatcher

9:02 pm on Mar 20, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Interesting. I have got out of the habit of using $_REQUEST, so thats a good thing. And I do always enclose mysql variables with single quotes. But addslashes....I use them if magic quotes are off, but not at any other time.

As for register globals, well its ok if you have access to your servers PHP.ini file, but if like me you are a shared server, then I`m stuck with them on. So I`m confused jatar_k about why it makes a difference if register globals are off. Can I assume that sites with register globals off also have magic quotes off?

coopster

6:47 pm on Mar 21, 2004 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



>>As for register globals, well its ok if you have access to your servers PHP.ini file, but if like me you are a shared server, then I`m stuck with them on.

Not always true. If the host allows per-directory overrides (for example, .htaccess files), you can control the configuration directive. Clarification of Global Variables OFF [webmasterworld.com].

>>Can I assume that sites with register globals off also have magic quotes off?

No. Configuration directives are controlled by the folks that setup the server and the PHP environment. However, if your hosting provider allows it, you may be able to override many of these directives.

Recommended reading:
How to change configuration settings [php.net]

bobnew32

8:12 pm on Mar 21, 2004 (gmt 0)

10+ Year Member



What are globals? Don't send me to a page, I most likely use them all the time. And what are the security reasons for using php globals?

coopster

1:46 pm on Mar 22, 2004 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



globals
is a term that actually refers to global variables. Variables, as you no doubt already know, are strings, arrays, etc. and quite easy to spot as they begin with a dollar sign ($). The global part refers to the scope [php.net] of the variable.
globals
are rather special in that they are automatically global--i.e., automatically available in every scope.

Don't send me to a page...

But bobnew32, what better resource than the folks that developed the tools?
Using Register Globals [php.net]
The first example listed answers your question, "And what are the security reasons for using php globals?"