Suppose you're writing a simple database web application using Ruby and MySQL. Access to the database is controlled by Ruby code. The user name that the Ruby code uses to access the data is the only regular user on the database. Does it make sense for that user to be "root"? Or is there any extra security in creating a second user just for the application?
Simple, consider the root as the main user, who can do everything (by default).
If he wants to dump the whole database, he can, if he wants to create some data to create (for example) fake account to overpass your bank system, he can.
So if your code is not enough secure (and this is quite often usually), you have strong security issue.
Usually, "a basic" security (really basic), should looks like that :
create a simple user, give him (with GRANTS) the right to SELECT, INSERT, UPDATE and DELETE on a specific database.
create another user who can SELECT and lock tables and SHOW VIEWS to perform dump (database save).
On a more "complex" system, you should create many users, depending of what they should access, this is for simple reason : if somebody got a SQL injection access, if the user can only access to a single view (for example), and not the whole database, this is a security issue but not the baddest one...
Also view are often used for that...
And finally don't forget triggers if you want (for example a log table), to disable insert or update or delete on a table, for everybody (except somebody who can destroy trigger of course) :
Use a trigger to stop an insert or update
Besides editing or deleting all data in your database, the root user also have the FILE privilege which gives access to:
LOAD DATA INFILE which can be used to read any file on the server machine.
LOAD DATA LOCAL INFILE which can read files on the client machine (the web server machine).
SELECT ... INTO OUTFILE which can create files on the server machine.
This is why your application should have only the privileges it needs, and this is also the reason your MySQL server daemon should be run as a non-privileged user on the server machine.
See also General Security Issues in the manual.
If everybody/thing is root, you lose auditability, you lose the ability to restrict the app to stop attacks (i.e. your app doesn't need this segment of sensitive information, seal it away from its user). If somebody compromises the app, you can suspend the account etc.
I would not make a user "root".
I'd create a separate username and password just for that application and GRANT it only the permissions required to do its job.
I would create a new user, giving it only the permissions it needs (SELECT, UPDATE, INSERT and DELETE usually do the trick). Like that, you limit the ability for the code to be manipulated in an unintended way.
"root", or generally speaking, users with Super User privileges, can change passwords, delete accounts, and therefore prevent you from accessing your own database.
If you server hosts only one application, then you may not need to create several lesser privileged accounts. However, it is common practice to create at least one user for each application, so that if one application gets compromised, other applications (and underlying data) may not be.
Related
So we've got a MYSQL database with very sensitive information and we want to prevent it from being exported by a developer/admin who has access to it, while still allowing them to access database while working on their duties.
In simple terms we want to prohibit mass select on specific tables.
Ideally it would be an option to disable mass select, something like limit 0, 1 enforcement for all SELECT queries on specific tables. Is it possible to configure MYSQL like that? Any other ideas how to prevent database from being exported?
Any solution I can think of when someone needs to access your production data within MySQL and you want to apply the principle of least privilege leads to separation of users and to the page on GRANT command in MySQL documentation.
But as I said in a comment to you question, it is much easier to develop a procedure to generate an impersonated sample of your data, so that your developers would not have access to the production data.
I need to store data for each user in ejabberd.How can I do this ? I mean I need to add one more field to user table and I should update this data whenever.
How can I do this ?
This is what I am doing.
During registration process in my Android Chat application, I post data like the desired userid (jabberid), password, email, display name, gender, mobile etc. to my PHP API. The PHP code validates if userid already exists and if it doesn't then it creates the user first in an external mysql database, storing all the fields received in post, and then creates the real user in ejabberd by executing the ejabberdctl register command. There will be some permission issues executing the command inside apace\PHP which I successfully resolved using this answer here. Now I can access the user data using my PHP API.
The idea is that I am not overloading the mnesia database with rarely accessed or modified data. IMHO, this helps if you don't want to switch ejabberd to odbc\mysql mode and lose potential benefits of mnesia or if you are planning to run mnesia in "RAM Only" mode. All this I am saying with limited knowledge of ejabberd, hence don't take my word as gospel.
I've searched for an answer to this and all I can seem to find are questions asking whether it is better to use multiple databases or multiple tables in a single database. This isn't my question though.
QUESTION 1.
I want to set up a new database alongside my current DB and don't know how. I want to give a user full admin access to DB2 without seeing DB1. This way I can host a friend's site and they can create and delete as many tables as they want without disturbing my own DB. I could also use it for demo sites that aren't secure and shouldn't exist inside my primary DB.
I figure I could do this pretty easily with a virtual machine and run a separate instance of MySQL but my resources are limited so that isn't really an option.
I'd like to set this up in one of 2 ways. I would prefer to have "server.example.com" host both DBs and open the proper DB based on user login. If not I could do it routing to server1.example.com and server2.example.com.
QUESTION 2.
If this isn't possible I'd like to know how to properly set up restricted access to a single DB in sequel pro. I have been messing around with it and so far prefer it to PHPMyAdmin. For some reason if I set up a new user with no permissions they have full access to my 'information_schema' and 'test' tables but can't create new tables. I don't want other users to access these tables though and I want them to be able to set up their own tables. I'd like to set it up so a new user can create a limited number of tables and only see and edit those tables. I can't seem to find information on this either.
Even if my first question is possible I'd like to know the answer to question 2. I've been searching for a long time and can't find reliable information anywhere. Maybe my brain is just tired...
You can set up multiple instances of mysql but for your situation you are better off creating different databases within the same instance.
You can create databases and then add users that only have access to manipulate the database they are given and nothing else.
Essentially the heirarchy is as follows:
Mysql (root or any other super user can see everything)
- Your DB
- Your Users
- Your tables/functions/Procedures/etc
- Their DB
- Their Users
- Their tables/functions/procedures/etc.
You basically separate the access for each, and in PHPMyAdmin it is very easy. The steps are:
Add Database )
Add User, restricting them to that database allowing only priveleges you want to give to that user and only to that database. (Guide here)
You can grant access to different database to different user using GRANT in MySQL.
https://dev.mysql.com/doc/refman/5.1/en/grant.html has the information you need.
The most simple you can do is
CREATE DATABASE db_for_user_a
CREATE DATABASE db_for_user_b
GRANT ALL PRIVILEGES ON db_for_user_a.* TO user_a IDENTIFIED BY 'user_a_s_password'
GRANT ALL PRIVILEGES ON db_for_user_b.* TO user_a IDENTIFIED BY 'user_b_s_password'
You are going to need to provide more information about your set up to answer this question of setting up multiple databases specifically.
Servers typically have methods to create multiple databases with software that is designed specifically to run on those platforms (Apache, and Windows server are a couple servers that can run software like WAMP or phpMyAdmin to manage these databases).
And in answer to the permissions: Yes, you can designate users that can have specific privileges on one, both, or neither of the databases. But, you can also set up table-specific roles and actions as well. This is more obvious with Microsoft's management studio though, where Mysql you may want to use something like Mysql Workbench initially.
On cPanel, for example, you can add a new database if your host allows it. On windows, you'll have to use other tools to set up a new database.
In answer to your first inquiry, each database requires its own connection, and there are database-wide operations that you can do such as migration and backups. A rule of thumb is to only keep entirely separate data in different databases, unless there is absolutely a reason to separate types of information into a different kind of database for efficiency. Typically, you do not relate data between different databases except for much more complex situations.
You can create separate databases and use them separately in sequel pro, I believe. Most platforms have an option to create a new db in the databases list.
Well I think I was confusing some stuff here. I apologize for that. I was calling databases 'tables'.
I was wanting to allow users to create new databases but not see the ones that others create. I think I can make this work by just limiting permissions and allowing users to access one or two databases.
It seems like PHPMyAdmin has some easier to use options than Sequel Pro. I've only briefly used it in the past but I'll give it another shot.
As for command line stuff, I love being able to work in command line but I don't know all the commands so it makes things generally difficult to figure out and the man pages weren't all that helpful.
Thank you for your answers and I'm sorry for my newbie questions.
We need to deploy application(developed by Java) WAR file in client place which make use of MySql 5.0. But we would like to restrict the client (the application owner, not the webpage visitor) from modifying any data in the database. Is there any way to protect data. The client can make use of the application but they should not be able to change any value in database. How to do that?
Manage Role/User permissions
Create an sql user (you should already have one), which will have only SELECT permission. So it would be something like
GRANT SELECT ON db_base.* TO db_user#'localhost' IDENTIFIED BY 'db_passwd';
http://kb.mediatemple.net/questions/788/HOWTO:+GRANT+privileges+in+MySQL
http://blog.wl0.org/2010/01/managing-mysql-grants/
http://www.ntchosting.com/mysql/grant.html
Check links below for further reading
FOR MySQL
Best Practice for Designing User Roles and Permission System?
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.devshed.com/c/a/MySQL/MySQL-User-Account-Management/
Can't set permissions on MySQL user
http://www.aquafold.com/d7/docs/BD5C99E4-3B55-C812-8318-6338A9A89ED9.html
FOR SQL Server.
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.mssqlcity.com/Articles/Adm/SQL70Roles.htm
http://www.sql-server-performance.com/articles/dba/object_permission_scripts_p1.aspx
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1061781.html
http://www.databasejournal.com/features/mssql/article.php/2246271/Managing-Users-Permissions-on-SQL-Server.htm
This is impossible; if you deploy the application at the client, he will have the credentials and will be able to log into the MySQL database and pretent he is the application. And thus he can make any change to the database that your application can.
The only way to solve this securely is to make a tier between the client and your MySQL database, and make sure that you control this so that it is only possible to make 'legal' changes.
Just write the code accordingly so that the user doesn't have any chance to modify the database? I.e. the code doesn't execute any INSERT or UPDATE and/or controls the access based on a login/role.
I honestly really don't forsee any problems here, or the code must be prone to SQL injection attacks.
Update: The above answer is actually irrelevant since the question is clarified. Turning into Community Wiki.
First off, I realize that there is no such thing as a perfectly secure solution (and even if there were, its usability would be crap).
That said, how do you protect your MySQL database from being compromised by someone downloading your code and picking through it? Based on my experience with PHP, it seems obligatory to store it within the code at some point or another, which sends up flags for me. I can see where refactoring to obfuscate variable, constant, and (user-defined) function names could be beneficial, but in the end it'd still be possible to trace through it and find the file with the DB login information.
Ideas?
Usually the MySQL auth information is stored in an external configuration file. The MySQL user used by the web-based app is given limited permissions such as SELECT, INSERT, UPDATE, DELETE and not given permissions such as ALTER, DROP, DELETE. If you want to release the code to the public you would not include your private config file, but a generic/instructional/minimal config file instead.
Storing the MySQL auth info in an encrypted format is somewhat silly, as you'd need to store the private key / unencryption locally as well. If it is trivial for an unauthenticated user to view the code or configuration files on your server the problem isn't the code - it's your server setup & config.
Security can be assisted by storing any hard-coded information (in config files or scripts) outside of the web-root, and by suppressing (on the production code) error messages. That way, hopefully, your users won't see that userValidate() expects exactly three paramaters.
pygorex1 is correct, you should use external configuration files where "external" means a file outside the web root. So even if there would be a configuration error in your web server which would allow the user to see your source code, they would not be able to see the database credentials since they cannot be accessed directly via the browser.
pygorex1 is also right on the user permissions. Limiting the mysql user's access to a minimum is always preferred. Even if a hacker would get the your mysql password and username, he would not be able to do significant damage if the user permissions are only limited to eg SELECT-queries. One thing he forgot to mention was that the mysql user should only be allowed to log in from localhost (or from whatever host the web application is on), never use wildcards in the allowed hosts.