Can a PHP site using data from a local MySQL database be vunerable to hacks (other than someone figuring out the admin password). In other words, whats the chances of someone being able to change certain parts of the data before it is displayed. My host doesn't allow remote MySQL access so I'm thinking it should be ok?

It's not just someone working out your MySQL login credentials that you need to worry about - you also have to make sure your site is not vulnerable to SQL injection attacks.

It's not just someone working out your MySQL login credentials that you need to worry about - you also have to make sure your site is not vulnerable to SQL injection attacks.

 

This is only a risk when user input is sent to the db though right?

 

What I'm thinking is having one db for stored info that is only going to be displayed on a page (such as product info) with read-only permissions. And having a seperate db for any user input I may require. What I'm concerned about is data from the stored db being changed before it reaches the user.

If no dynamic/user data is being put into a query then you needn't worry about SQL injections, I'd just ensure your connection details are stored outside of the web directory so it cannot be accessed in a browser.

On a properly configured machine, it is sufficient only for you to ensure your database login details are safely tucked away. Because your database is locked down to TCP localhost only (or uses UNIX domain sockets), MySQL will reject connection attempts from outside the same machine, and further will not pass any traffic over the network which could be packet sniffed. However, anyone on the same machine (i.e. if you're using shared hosting) could compromise your database if they discover your login details. In theory, anyone on the same machine could also packet sniff (intercept and/or modify) localhost data to discover your login details, all executed queries and response data. However, this functionality would require root permissions and should be impossible on a properly configured server. So you should have no problems with data integrity.

On the topic of packet sniffing it's good practice to use different usernames and passwords for different things. You should never (for example) use the main username and password to connect to MySQL. You should always create an individual account so that if your database is compromised your file system (or other services) aren't.

 

Also on Unix based servers never login or use root from a script (if you have access to the root account). You should also try to avoid logging in as root generally.

 

On a properly configured machine, it is sufficient only for you to ensure your database login details are safely tucked away. Because your database is locked down to TCP localhost only (orMySQL will reject connection attempts from outside the same machine, and further will not pass any traffic over the network which could be packet sniffed. However, anyone on the same machine (i.e. if you're using shared hosting) could compromise your database if they discover your login details. In theory, anyone on the same machine could also packet sniff (intercept and/or modify) localhost data to discover your login details, all executed queries and response data. However, this functionality would require root permissions and should be impossible on a properly configured server. So you should have no problems with data inte uses UNIX domain sockets), grity.

 

Good post. Although most servers are configured pretty well by default, and things such as packet sniffing applies in general, what you said will vary depending on the operating system. I know your talking about Unix-based servers but it's different for the likes of Windows (certainly is desktop level).

Also on Unix based servers never login or use root from a script (if you have access to the root account). You should also try to avoid logging in as root generally.

Which is why sudo is very useful for those select few executables which need to use setuid or elevate themselves to root. Then a script can run only those executables which require root and which the admin has personally vetted as being "safe" to run with elevated privileges. Even if someone gains unauthorised access to the script, they shouldn't be able to do any real harm with its root permissions. This is pretty off topic for this thread though!

The last couple of posts were a little lost on me, I kinda get the gist of what you're saying. Only logging on with just enough permissions to get the job done is a good idea.

Only logging on with just enough permissions to get the job done is a good idea.

Yep, that's precisely it! In MySQL you can grant permissions on individual databases, tables and even fields for each user, so you should try to give your script user only the permissions they really need. Many financial institutions also use stored procedures (basically the same as functions you find in any other language) and grant EXECUTE permissions on these. The result is that most calculation is done inside the database server returning only the results required (thus minimising bandwidth usage), and that you can lock down the actions a specific user can perform as opposed to the raw data they can access/modify. A little off-topic, but hopefully informative.