2

The Setup: Im building an app to model visually world data. A significant part of this project will be the database since that data is what is interesting. I should only need to allow SELECT queries, and perhaps eventually CREATE TEMPORARY TABLES should there be collaboration. 

<?php
  DEFINE('SERVER_NAME', 'localhost');           //Database server name
  DEFINE('USER_NAME', 'myCPanelName_openSrc');  //Database user name
  DEFINE('PWD', 'opensrc');                     //Database user password
  DEFINE('DB_NAME', 'myDatabase_appName');      //Database name
?>

The Problem: The data that would be exposed is my CPanel login name, and the database name. It seems leaving a door open to my database may have unseen consequences. Even while restricting access and using generic credentials.

The Question: What is standard practice in this situation? And how risky is this business of open-sourcing a database? Is data corruption/theft my only concern? Or are the consequences more sever?

DMrFrost
  • 123
  • 5
  • Possible duplicate of [Does read-only access to the database prevent sql injection?](https://security.stackexchange.com/questions/86908/does-read-only-access-to-the-database-prevent-sql-injection) – Polynomial Mar 12 '19 at 22:19
  • 4
    You should **NEVER** give direct database access to a client-side application. Implement a web service or similar on a server as an intermediary that exposes only the data you intend, with appropriate authentication and authorisation controls. – Polynomial Mar 12 '19 at 22:21
  • @Polynomial Your "duplicate link" doesn't help since sql injection is only a small piece of the overall attack architecture I am curious about. That aside the idea of a server in the middle is an interesting one. So you are saying in no circumstances in open source projects should you trust clients with a copy of your data. Is data corruption my only concern? Or is cPanel hijacking a possibility as well? – DMrFrost Mar 12 '19 at 22:43
  • The linked question covers the case of direct database access as well as SQL injection - in fact "any form of SQL access" was the threat model I assumed when writing that answer. Giving your CPanel credentials away in the client is also a bad idea and will absolutely result in your CPanel instance getting hijacked. – Polynomial Mar 12 '19 at 22:48
  • Only a username would be shared for cpanel, which I agree, is an attack vector. Though not a very strong one. Back to server relaying...Are there any tools/services you have experience with or could recommend that accomplish what you recommended? – DMrFrost Mar 12 '19 at 22:53
  • You wouldn't use an off-the-shelf tool. You'd need to write a server application to expose what you needed. There are many frameworks you could use but that's rather off-topic here. – Polynomial Mar 12 '19 at 23:09
  • @Polynomial roger that... time for more research research research. – DMrFrost Mar 12 '19 at 23:14
  • Additionally to the database issues, you are apparently using some sort of shared hosting account (cpanel) I suggest looking in to what the possible risks of shared hosting can be as well. – Jeroen Mar 13 '19 at 08:49

1 Answers1

2

This is not safe to do. Do not expose MySQL servers to public access.

  1. Any user with SELECT access to a MySQL database can execute a denial-of-service attack by performing queries which generate excessive CPU load. A simple example is SELECT BENCHMARK(1e20,1); performing a series of CROSS JOINs between large tables would have a similar effect.

  2. Allowing an unlimited number of users to connect with these credentials may allow them to consume all available connections on the server, preventing other users from accessing the server.

  3. Information about the source address and current queries being run by other users connected with the same credentials will be leaked through SHOW PROCESSLIST, even if the user does not have the PROCESS privilege.

  4. Allowing any user to access the MySQL server may expose the server to exploits which require access by an authenticated user. No public exploits of this sort are currently known, but it is possible that one will emerge at some point.

  • So yea I think it makes allot more sense to simply use a csv format for sharing data for the time being. When I get to the point where I want to allow others to upload and apply data, I will have to find another solution. But for now, cheers. – DMrFrost Mar 14 '19 at 23:31