• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Securing a web based PHP MySQL frontend?

quadomatic

Senior member
I do a lot of database work with MySQL at my job. A fair bit involves making frontends for manipulating data in MySQL databases. They're particularly fond of MS Access.

Having little experience with MS Access myself, I find building the frontend using MS Access over an ODBC connection very tedious. It seems like I could write most of the data entry and reporting features in PHP much easier, and it would probably be easier for employees to use.

However, my boss feels averse to this due to security issues, since a PHP document stored on a server would be less secure.

I was wondering if any of you know how one would go about setting up a secure web server with PHP support, accessible only via the local network. If this could be done, would it be fine to use PHP over Access?

Thanks
 
I guess I'm missing something. With Access don't you have to propagate the database credentials out to every installed copy of the client? With a web-based portal the credentials would be stored in one place, i.e. the config of the php app, and yes it's possible to make those secure through directory permissions and other means.
 
Our Access frontends connect to a MySQL database being served from elsewhere. The credentials aren't stored in the .mdb files themselves, but in the MySQL ODBC Driver. Credentials are managed in the PC's control panel.

And I probably shouldn't have said "web based" in the title. I more meant a local server only available to the building's LAN.
 
However, my boss feels averse to this due to security issues, since a PHP document stored on a server would be less secure.

Why would it be less secure?

The file has to be stored somewhere and in the web server case it's still on a server and still protected by whatever permissions you have implemented on it. Whether you access the file via HTTP or CIFS is irrelevant. If anything it would probably be better since you won't have credentials stored on every PC.

Now, if your PHP app does stupid things with regards to security that's a whole different story.
 
It should be trivial to setup a firewall rule to block anything other than requests on port 80/443 from anything other than local IPs.
 
It should be trivial to setup a firewall rule to block anything other than requests on port 80/443 from anything other than local IPs.

As long as you're not doing something stupid like have all of your internal hosts using public IPs, that shouldn't be necessary because the border firewall won't have a static setup on it unless you explicitly do that.
 
Our Access frontends connect to a MySQL database being served from elsewhere. The credentials aren't stored in the .mdb files themselves, but in the MySQL ODBC Driver. Credentials are managed in the PC's control panel.

And I probably shouldn't have said "web based" in the title. I more meant a local server only available to the building's LAN.

Yeah that's my point, and I think Nothinman's as well. I don't care what file the creds are stored in. The bottom line that your boss seems unaware of is that the credentials are configured into every client, as opposed to being stored in a single web server configuration file that can be strongly secured. The web client architecture is inherently more secure than a fat client architecture. Either can be made more or less secure through care or the lack of it, but there are more opportunities for human error to release data into the wild in the fat client scenaro.
 
I talked to my boss more about it this morning. I think his real concern is actually that faculty want to be able to create their own queries and such. It's possible that in designing the frontend in Access (or in PHP), I will leave out queries that faculty want.

If the frontend is in Access, it's easy for faculty to make their own queries.
 
Well that's a whole other can of worms and pretty much kills any data security you might try to implement. All you need is one bad UPDATE query and all your data's gone.
 
I talked to my boss more about it this morning. I think his real concern is actually that faculty want to be able to create their own queries and such. It's possible that in designing the frontend in Access (or in PHP), I will leave out queries that faculty want.

If the frontend is in Access, it's easy for faculty to make their own queries.

You have a boss that's concerned about security, yet allows users to create their own queries? Ironic.
 
Back
Top