Jump to content

The truth about mySQL Security


fusionpixel

Recommended Posts

So I finished a small application that I am using on my computer only to avoid any problems on the net in regards to security.

Since there is no easy way to ask a question like “What is the best way to create a secure application” I decided to send the question out there and ask to what everyone thinks or believes is a secure way to create their applications.

I have been working with PHP/mySQL as user not much as developer for the past years but now trying to learn more about the developer side, I have hit a wall once I have faced Security.

For a while I was certain that putting my sql connection in a PHP file it was ok, this believe was even stronger while using different applications out there that place their connections logarithms inside folders named as simple as “connections”, and if we want to examine this theory further if you create a Database Connection in Dreamweaver the application itself will create a folder titled “Connections” and inside that folder it will write the scripts necessary to connect to your DataBase.

With all this in mind I ran into a basic tutorial that highlighted the importance of having your connections secure and one recommendation was to place your connections script (or PHP file) under a password protected directory. This would be an overkill IMHO and not only that but securing a password with another password?

Comments?
Link to comment
Share on other sites

  • 3 weeks later...
hmm you could probably squeeze several books out of web security, but i think the guidelines i kinda stick to, which kinda summarises everything i ever learnt about php/mysql security is:

1, guard against SQL injections if you use $_POST/$_GET/$_REQUEST, etc. not just talking about backslashes and apostrophes here, but the whole hog - make sure there's NO way of inducing an error message via user input/changing URLs, etc.

2, like you rightly point out, Dreamweaver automatically creates a 'Connections' folder. to be honest, i 'borrowed' some ideas from phpbb's mysql class, so i don't use dreamweavers recordset/database features at all anymore. also, i do not keep my username/password file within the web tree, but rather i access the details i need via an include.

3, which brings me onto another point i picked up on. i read once somewhere that if you don't want people to access something, don't upload it at all. seems a bit unpractical, so my compromise is - keep everything you don't want direct access to (even images, etc) OUTSIDE of the web tree, and use a script to access these files instead. i made an entire recruitment system that allows users to register and store their CVs (resume's). the details of the CV's are stored in a database, but the files themselves are stored OUTSIDE the web tree, and fed back to the browser if required via a seperate script. images too - imagecreatefromjpeg/gif, etc, are excellent functions to access images stored outside of the web tree.

4, error reporting - excellent whilst youre developing a site (for you), and excellent whilst the site is live (for a potential hacker). make a point of turning off error messages in your PHP.INI file (or via a htaccess file) when the site goes 'live'. on the same note, i really never use: die(mysql_error()) anymore either, as it reveals too much info as far as i'm concerned about the structure of my database for people to possibly try SQL injections. this is also one of the reasons i don't use dreamweavers custom recordset/database scripts anymore, and rather use ONE database accessing script that i can turn debugging on and off by changing one value in one file, not hundreds of values/lines of code sitewide.

so in summary, i think it's important to remember not to have ANYTHING sensitive on a server at all, but if it has to be that way (as in most cases), then putting the files outside the web tree and bulletproofing the scripts that access them and feed them to the user is a good option.


Link to comment
Share on other sites

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.