I'm trying to solve the problem described by CWE-798, specifically how to allow my application to authenticate to a database securely. I would like to set a mysql password within mysqld and push that information out to a PHP application server. This entails communicating the new password from mysqld to PHP before a PHP instance attempts to connect to the mysqld.
(I did read through the suggested approaches on mitre.org and have some knowledge of privileged access management - however NONE of the recommendations actually solve the problem).
Unless this is initiated within the mysqld e.g. using its event scheduler, then I need to maintain some sort of script outside MySQL which will need credentials to connect - thus defeating the objective.
My problem is that I don't know how to get MySQL to initiate a client connection to the application to inject the new password; it does not appear to provide a standard function for invoking a URL nor for executing a program.
Is my only option to implement a UDF?
The vulnerability you're describing seems to primarily relate to applications that are in the hands of users that can freely inspect what they've been given, such as might be the case in a desktop application or a mobile app. If you have credentials in there you must take great pains to encrypt them, and then prevent that encryption from being cracked by protecting your key, but seeing as how all of this has to happen on the user's hardware you're fighting a battle you may never win.
This is how the DVD encryption was cracked, the private key for decrypting DVD data was stored in a desktop application and eventually uncovered.
Server-side code has different concerns. Here you want to avoid hard-coding credentials into your application not because you're concerned about hostile users per-se, though that can be an issue, but because you do not ever want your credentials to end up in a version control system.
One way to ensure this never happens is to have the credentials stored in a file external to your application, like a config file that the application can reference. Most frameworks have some kind of configuration file (.yml, .ini, .xml) that define how they connect to the database. This file should be stored on the server and only on the server, not on developer workstations, not in your version control, and especially not somewhere shared.
You can go down the road of using something like Zookeeper to manage your configuration files but the investment of time required makes this a futile exercise unless you're managing hundreds of servers.
So the short answer here is: Don't put your credentials in your code, or store it with your code. Put it in a config file that's kept on the server and the server alone.
I'm a newbie to web development. My team at school is using J2EE and MySQL to develop a web app that will be deployed on AWS. We use GitHub for version control.
I am just wondering if I use MySQL from my terminal to add tables into the local "test" database, how can my teammates have access to them? Should I deploy the database somewhere or maybe create the tables in code so that my teammates can automatically have the tables in their local database when they run the code? But how can the data already stored in the database be shared then?
Sorry to have this naive question, I tried to do some research online but it seems that the results are more advanced and about PHP not J2EE... It will also be great if you can recommend some good resource for me to read through since I believe this is a very fundamental concept that I should know.
You can maintain the database's schema in your code so it can be committed to source control and accessed by the others. This is a good practice regardless of how you use a test database for the development.
Your team members will not be able to easily access your local database. For a distributed development environment it would be best to host your test database on a remote server, such as on an EC2 instance in a public subnet or in RDS. Then you can pass along the database's connection information (host, port) and credentials to the other team members.
Pay attention to the security group when creating the database either in EC2 or RDS. You can open it up to the world (0.0.0.0) or narrow it to just your team members' IP addresses to tighten security. Otherwise the team members will not be able to connect to the database.
It's hard for your team members to access your local database from another computer. It's a lot better to host your database on a remote server, such as a EC2 on AWS or Computer Engine on GCP. Then you MySQL database can be accessed by anyone with an authorized connection and whitelisted IP address.
Another solution is using a cloud-based data warehouse like a Snowflake or Acho Studio. Once you have the MySQL database connected to the DW, your teammates should be able to access the tables you've authorized them to see.
This way you can also share your SQL queries with your teammates so they can run them against the MySQL server themselves.
You can create a test environment using VM or containers and share it with your team members. You should pay attention to how to keep track of the changes in these test environments as well. The following answer describes how a db with schema can be shared using a docker image. You can version control these images so you can track the changes.
I am facing this problem:
stackoverflow question
except my host doesn't seem to have cpanel. Since the answer given in the linked question is cpanel related it has not helped me. Is there anything I can do?
It seems you are trying to connect from a client machine located on your desk to a mySQL server instance located in a service provider's server farm. You're trying to use the ODBC "driver" for mySQL to do this, so you can look at your mySQL data with MS Access. (Right?)
You need to make sure this particular hosting service provider allows remote connections to their mySQL server instances. Some service providers, especially the lowest-cost ones, prevent these remote connections using firewalls or other network isolation techniques. (They do that because it's easier to control both security and performance when only their own web servers can connect to their mySQL servers. ) If your service provider prevents all these connections as a matter of policy, you're going to need another service provider.
If they DO allow remote connections, you may need to enable those connections for your mySQL database. That's what the "cpanel" function mentioned in the other question is about. cpanel is a popular control panel web application offered by many commercial hosting service providers to allow self-service control by their customers. If your service provider doesn't use cpanel, you'll have to find out what they do use. Even if they do use cpanel, they may still not allow remote mySQL connections.
You will also have to make sure your client machine (the one running ODBC) and user have authorization in the mySQL user database.
You would do well to put in a service ticket to your service provider asking if they do offer remote mySQL access. If they say "yes," then you can ask them for advice and help on setting it up.
Keep in mind that opening mySQL server instances for direct connection over the publicly accessible internet is not ordinarily considered a good security practice. If the data in your database is in any way private (peoples' identity information, for example) you need to be very careful indeed.
I'm new to MySQL and I'm using a desktop DB management app called "Querious" to simplify the process while I learn.
I want to work on (mainly just structure & basic population) a database that's hosted elsewhere, but the host won't allow any remote MySQL calls on their server.
What is their reasoning for restricting MySQL calls to localhost only? Is this a security or a performance concern?
This is a security concern. The idea is that if people can't remotely connect, they have to compromise the system. Not just the files that hold the database information.
You may be able to request that just add your IP address to a trusted host file, but I doubt they'll do that either.
It's fairly common practice to not allow remote DB connections
I've run into this problem with GoDaddy where they implement this by default. You can change this, however, by indicating that you want to allow remote access. If you've already created your DB, though, you can't change it, so I would recommend creating a new DB and deleting your other one.
The reason why is for security. If only your app can call your DB, you don't have to worry about other people trying to access it.
Distill,
An improperly-configured MySQL instance is dangerous, whether the user is remote or local. This could allow malicious attackers to cause crashes or remote execution of arbitrary code (i.e., owning the machine).
You can use PuTTY to create a tunnel if it's allowed by the server so that your application traffic goes through ssh and then is forwarded to the correct port on localhost.
A database-server serves all requests, weather coming from local-host or remote client
and to listen any request, a database server must run on a port to listen requests on that port.
As far as i know, Microsoft access don't run on any port,
and it is not possible to request Microsoft access on remote machine using
DriverManager.getConnection("URL", "user", "password");
but possible if your data-source is MySql, Oracle, etc... using,
DriverManager.getConnection("jdbc:mysql://ipAddress:portNo./schemaName", "user", "password");
(if i am wrong, please correct me).
Please u guys here help me with the concept, weather Microsoft access is a
a mere file for storing data (because it don't runs on any port),
or a database server
(because for Microsoft-access Type-1 driver is available ,
it means it must be a data-source because drivers are only available for data sources).
Access does not provide networked connectivity beyond a file share. There is no "Access" port.
Access is not a database to begin with.
It is an application development environment that ships with a default database engine, Jet (or ACE in A2007, which is just an updated version of Jet), and that uses Jet MDBs or ACE ACCDBs for storing its application objects.
Your question is not about Access. It is about the Jet database engine.
Jet is not a server database. There is no process running on the server through which all communication with the Jet data store is managed.
Instead, Jet is a file-based database system. Each user runs Jet locally in memory, and opens the database file in shared mode. Locking of the database file is managed via the LDB file.
ODBC does not provide server functionality to Jet data. It is simply another user of a file.
Microsoft Access databases can be used over ODBC or using a shared file system, so from that standpoint they can be considered multiuser databases.
This not really a database server from the standpoint that, there is not one location that serves queries up to clients. Unless you are using ODBC, each "client" has it's own copy of the database engine.
Access is not designed for many users, and does not have many of the properties that you normally think of when talking about database servers. Including scalability and robustness.
MS Access is a file-based database system but technically speaking, so are many other database systems. SQL Server, for example, will store it's data in a single file and can behave in a way that's very similar to Access. Then again, SQL Server has much more additional features.
But is Access a database server? Well, that depends on your definition of what a server should do. It is possible to create an Access database and give it some server-like functionality by writing some code to "serve" your data to some client application. Been there, done that. And actually, Access has been popular in the past for several cheap-hosted websites as database to e.g. run a forum or guestbook on.
To make things more interesting, Access databases can be accessed through COM. And COM objects can be created on a remote system. So theoretically, through ADO you can already access an Access database on another machine.
Access is also reasonably able to handle multiple users and offers some basic security, if need be.
MS Access is also more than just a database file format, although most people tend to forget this. MS Access is part of MS Office and as such it provides much more functionality than just a file-based database system. (Then again, even Paradox is more than just a file-based database if you buy the complete product from Corel instead of just using the database files plus drivers.)
Btw, the term "server" can be confusing. You don't need to run something on a port to make it a server. Basically, a database server is just some program that provides database services to other programs and computers. With Access, you can technically do both, so yes: Access is a database server. (Albeit a very primitive one.)
In determining whether something is a server or not, the issue of whether it has ports is a red herring. Ports are simply one means of interprocess communication. As others have already noted, other servers use named pipes or shared memory to communicate with clients.
The architectural feature that really makes a server is process isolation. This is true whether you are talking about web servers, database servers, or display servers like X Windows. In each case you have some important resource that you want to guard very carefully. Therefore you don't let anything but a few select processes touch it. If another process wants access to that resource, they don't get to work with it directly. They have to send the server process a message, "Hey server please perform operation X on Y and send me the results". The channel used for sending the message is relatively unimportant, the key point is that some independent process is charged with managing the resource. Contrast this with Access (or as somebody pointed out more correctly the Jet database engine). If your application uses an Access database, then your process open file handles on the database, performs the record locking, and does the index lookups. This is all conveniently hidden by many layers of library calls, and it probably involves many switches to kernel space, but in the end it is still your process that is getting all the CPU cycles and doing all the work. This is true even if you are accessing the Access database via ODBC, which is really just another layer of library calls.
AFAIK, MS Access is a database and you can connect to it through ODBC etc, but it is not a database server in the way SQLServer, MySQL, Postgres or Oracle are database servers.
Access is a file that can be attached to via the JET engine or many others. But it is a file. This means that if too many people attempt to connect to it there have been stories of it becoming corrupt and the whole db lost! It is not anywhere near as powerful as the other database engines you mentioned.
It does not run on a port. It's just a file.
If you put the file on a windows file share, then protocol is SMB, the port is 445. The machine with the file is called a File Server, so in a sense, it is a server app, but MS-Access isn't the server, the SMB bits are. What SMB doesn't do that a real sql server would do is manage the concurrent access.