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.
Related
I am currently recreating my portfolio, which is powered by a node/express backend. I want to have some pages where I can update/add projects to my portfolio, and I know that I will be the only admin on this site. I want to protect these pages with admin credentials. I think a user table on my database (mysql) is overkill though... is it a good idea to store user/(hashed)pass in process.ENV? I feel like theres a better way.
A database can be anything, text file, sql db, json file, even a variable in your program. A database it's just something which store data.
So, for me, you can without any issues store your credentials in the process.env. The only constraint is that you have to restart your server whenever you wan't to change password and you have to inject yourself the credentials in environement variables.
But if you're already have an sql database in your project, the best way is effectively to use a table User with hashed password. With this method you can change your password without restarting your app (but in your case is this really usefull ?) and if you're adding some users, the system will be already in place (but YAGNI)).
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 want to provide the ability to query the underlying mysql db on a rails-powered site to visitor on the web. The most transparent way seems to be able to take the text in a textbox and pass it to an sql connection.
However, I'd want to hide the user/password details and only make certain content tables available. Also, I only want to provide read access. Is there a convenient way to do this? It would be better if there were convenient view helpers too. Any gems like this? Perhaps something similar to PHP's MyAdmin?
The solution to this is more about configuring your database rather than finding special code.
You need to create a user in your MySQL database and grant read-only privilege to a subset of tables of your choice. Use this user in your connection string for queries from your "raw" SQL page. This is the only place you'll have to change code and all it involves is using a different connection string from your other code.
Here's an object-specific example of granting read-only permissions to a user.
To help manage this issue on the server you could make use of a schema.
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.
I found out after a while that a component used on my website had an unfiltered parameter, in a WHERE condition in the following settings:
Using Joomla! 1.5, latest update.
The component is custom made, fairly small, and after reading its source I couldn't indentify any other security flaws.
The attacker was using SQLMap to do their work, as I saw its user-agent in the log.
MySQL version is 5.1.11
PHP version is 5.1.4
The database user has USAGE privilege.
The server OS is Linux.
After trying the same steps on my own box, I was able to read the database (and since I'm not an expert in sql injection I'm not sure that was all I could do).
My worry is mostly about the session table, would the attacker be able to impersonate a user from it? Aside from that, is there any chance he could have uploaded some payload to my server?
Also, could he have "magically" updated some field through this SELECT query? (No stacked queries available).
Thanks in advance.
If you can read the database, you can dump it with SQLMap and find the hash of the administrator's password.
With that hash, the attacker could crack it (or if it is MD5, find a collision fairly quickly) and login into your administrator account.
From there, your admin account is screwed. The attacker has admin privileges, so consider your site dead. Worse than that, if Joomla is like Wordpress, the attacker can use a custom PHP code in the theme, which allows them to drop to OS level and modify your Joomla installation.
In short, they can screw up your server, as Joomla executes arbitrary PHP code when it is run.