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 looking for share database from two server into one server, for sample that there is one mysql database server relate to shopping database from hostgator.com and there is two shopping websites server from other hosting company NOT from hostgator company, my question is that is this possible to login in into other company sever use that database from other two from shopping site server from other company!
If possible how, do we can use that! what do we called this! is there is website that i can learn more!
many thanks.
Use:
$con = new mysqli ("SERVER_IP","db_user","db_pass","db");
Instead of
$con = new mysqli ("localhost",...);
You need to create a user for the database with host % permissions and you need to allow remote access to the database, see here:
enable remote access
Hope this was what you are looking for
Any application can directly use any database if the application can "see" that database. What this means includes, but is not limited to:
Both the application and the database and currently running
The hosts running the application and the database can reach each other over a network
The database service is reachable by the application over the network
Necessary ports aren't blocked
Necessary permissions are enabled
etc.
As long as there doesn't exist a condition by which one instance can't "see" the other (such as a firewall preventing host and/or port access) then it makes no difference what hosts the application and database are on. It's just a change to the connection string.
However, if there does exist such a condition (such as a blocked port, which would be very common in this scenario) and the database isn't "visible" to the application, then you have two options:
Correct the condition (for example, open the port)
Create an intermediary API
In many cases, particularly where you don't own the network infrastructure being used, the first option may not be possible. (Even if you do own the network infrastructure, it may not be advisable for security reasons. Internet-accessible databases are generally frowned upon unless you really understand the security of that database.)
So in the event that you need to create an API, this would simply be an additional application which can see the database (possibly running on the same host, or within the same firewall) and which exposes functionality that is visible (such as a web service instead of direct database access). It can be very simple, exposing just get/save (CRUD) functionality to the database. Or it can be more intelligent, exposing business operations over the data which external clients can use. It's up to you.
I am creating a web service for a small company which will use client authentication and possibly https for a RESTful service. I am asking a very simple question that I hope is not too broad, but I am very new and naive to internet security. What precautions must I take to ensure my data is secure?
To describe my service a bit, users have an account where they place presumably insensitive information and retrieve it from a database using a homemade authentication token I create on successful login with a salted password. I am using an amazon instance where MySQL is local and access is granted remotely to me so I can access it directly from my home. I am using a few php scripts to do my work requesting and adding data and am attempting to protect against injection. I am storing my MySQL credentials in a separate file from the php scripts. I can only ssh into my server with a pem file that I believe is safe.
My biggest fear is that someone will come and delete all of my data. What other precautions must I take? Thanks
If you're using Amazon EC2 then you should make use of their security groups to lock down your MySQL server and ensure that no external access to it is possible.
Application servers have an internal non-routing 10.x type IP that should be used for access control, and any external IPs, like your home network, should be specifically whitelisted if VPN access or SSH tunnelling is not practical, as those two are far easier to secure.
Be absolutely sure that no credentials, configuration files, or keys are stored anywhere in your web root. That is, should you accidentally misconfigure your application server in the worst possible way, with directory indexes turned on and everything, it's not possible to snag anything critical.
You might also want to specifically exclude the downloading of *.inc in case you make a mistake. The idea here is to set up a number of safeguards you'd have to break before things go horribly awry. A single-mistake failure situation is always the result of bad planning.
Above all else, be extremely vigilant about proper SQL escaping to avoid SQL injection bugs as no amount of firewall security on your MySQL server will help you when someone can drive a truck through a mistake in your code and have free reign on the server. It's recommended to thoroughly audit any SQL interfacing code you've written before going live with it.
Be sure to have a proper deployment procedure that uses a version control system. If you ever have an intrusion it's very easy to roll back to a known-good version of the code if you have one. The 1990s style "throw files at server with FTP" deployment approach is hazardous at the best of times and fatal to your business when it goes wrong. Use version control or you're living on borrowed time.
I'm working on an application in VB.NET that has to connect to a MySQL database and FTP. How secure is it if I used it in an application that I gave to other people. E.g. if I was to let other people use this application would they be able to find out the MySQL and FTP connection details through intercepting packets or something like that?
If that's the case how can I work round this? Also, part of my application is an uploader for users to upload files, is FTP secure for that or are there better alternatives ways in doing that? My server is a Windows Server 08 if that makes any difference.
Thanks in advance.
FTP is plaintext. It is very easy to get user names and passwords just by packet sniffing. If the ftp is supposed to be secure rather look ay sftp or ftps solutions. These use SSL type encryption on the network layer. Never ever use a ftp server for sensitive information.
MySQL traffic can also be sniffed though it is considerably harder to reverse engineer the protocol. If data has to flow between client and mysql in a secured fashion you can configure mysql to use SSL certificates to encrypt the information. This will ensure security is of highest standards.
It depends, but as per Accessing SQL Server with Explicit Credentials article and it is applicable to MySql as well:
The recommended method is to store the predetermined user name and
password on the server, and then read it and add it to the connection
string at run time. An advantage of this technique is that your
application can access the database using different credentials under
different circumstances, depending on what it needs to do in the
database.
Security Note Never hard-code credentials as strings into programs in your application. Anyone who can get access to the code
file, even the compiled code, will be able to get at the credentials.
Security Note Always give a predetermined user name the minimal access privileges to a resource. Never use "sa" or any other
administrative-level user name. Always use passwords
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.