I have the table with username and password named 'credentials' table and 'role' table having roles of organization.I want to grant permission to that schema depending on the roles present in the table 'role' of that schema.
what i need to do?
Do not let anyone or any application have write or even read access to the mysql database. Exception: the Admin, who preferably has access only from localhost.
This implies GRANT ... ON dbname.* TO ... is the most that you give do non-admins. (Where dbname is not mysql.)
If the application (especially a web application) gets compromised, the hacker can see whatever data that it was GRANTed. If that includes mysql, then he can fish around to for the root password and do other nasties.
I have seen such a security flaw come in via a web page, and get the unix password file!.
local_infile = ON is also a security hole waiting to be exploited. Turning it off puts a crimp in certain load mechanisms, but it is worth it for an exposed web site.
Related
I have a request from a customer and I am quite sure the answer is no, but wondering if someone has a different answer.
Background
As you know MySQL installation create a database called "mysql" where it stores the databases we create and also the users.
In the user table, there is a field called "authentication_string" where the user password is saved.
Project
On this project each time a customer creates an account a new database user and database is created.
When a customer logs in through a web interface, the system calls an API to authenticate him/her. After that the root db user is used to connect to customer database, not their own database credentials, why? because they do not want to save user and password on database (this is a temp solution)
They want to change the application so after authentication/authorization process and they would somehow only needed root credentials to somehow get user and password from "mysql db" and then use them to create the connection using customer db credentials.
Is this possible? Or is there some mysql parent - children configuration where this scenario is possible?
Project uses MySQL 5.7
From what I can understand I think you could just use MySQL’s SET PASSWORD to set some random strong password for the user and then login using that. This way you would not store anything and it would still be pretty secure assuming your root db access is fairly isolated from the thing that’s trying to login as the user.
For example:
SET PASSWORD FOR some_user = <long-strong-randomly-generated-password-string>
Afterwards you return this <long-strong-randomly-generated-password-string> from your access-providing process and then the user process can login using that. In this case it would stay valid until the next SET PASSWORD, so keep that in mind, but depending on your use-case that might be ok.
I am developing a multi-user-application windows desktop application.
For User Management i use the DMBS (Oracle, MySQL, MSSQL, Postgre).
So each user has an database user account.
I do not want the user to connect to the database directly and read / write data.
The data should only be accessible connection should only be valid if they use my application.
I found this website by SQLDUDE where he describes some techniques.
One way to access the data only through a specific application is a logon trigger that checks for application_name.
However he also describes that this method can easily be spoofed as the user can specify the application_name once he knows it in the connection string.
(detailed explanation here - see Solution for Scenario #2)
He also mentions Application Roles.
A more secure approach you could use for this is called "Application
Roles". When connecting from an application you assume a particular
role and only that role is granted privileges required in the
database.
So basically the user logs in with his login credentials but has no rights at all (only connect).
Then inside the application i call sp_setapprole with a password, once the connection is established so the application rules are granted.
Once this call succeeds then the connection gets the privileges of the
application role and loses privileges of the actual user, which is
what we want. So if someone tried to connect to the database from SSMS
or SQLCMD, they will access the DB using their credentials, which
won’t have the required permissions on the tables, since only the
application role has the rights on the tables. This is more secure &
reliable approach, but one that requires application code change and
as a DBA you will have to create the application role in SQL Server.
So Application Roles sounds like the way to go.
My question is:
Are application roles DMBS standard and available to most DBMS systems?
Is there way to trace the sp_setapprole login (e.g. with WireShark)?
Of course someone could reverse-engineer the application and get the credentials for the application role - but i guess that's unavoidable :)
I've seen one simpler solution in place and it worked fine. Here it is:
The application is responsible for creating users at the database
Before creating the user, the application hashed/encrypted their password, so if you chose password "123456" it would be created as "RRU2992191910" (just an example)
If the user tried to connect to the database with "123456" it wouldn't be successful
Only the application was able to connect to database, because it hashed/encrypted the password informed by the user
This is not the most secure solution in the world, but it's very simple and does what you want. And it could be ported to different RDBMS's with no extra cost.
How do I prevent WAN access to a particular database in SQLyog? I am able to grant full access to particular DB's, but not able to prevent them. I have a Web APP that runs on an internal server and accesses MySQL on the same server. I have created a SQL user with my workstations IP, but I am receiving access denied from dbconnect when I run the APP from my workstation.
Thanks,
Tony Cripps
MySQL does not allow connections from anything other than what you've specified. If you want to disallow access from a particular IP or network, then that mean that you've already gone and granted access to them.
Review the CREATE USER syntax, particularly the section on specifying hostnames.
Review the user accounts that you've already created:
SELECT user, host, password FROM mysql.user;
And then re-create them as necessary.
Other than than that, if you want to completely disallow WAN access then you should be looking at your firewall settings, not MySQL.
Say you created a blog application, and it's data is stored in a MySQL database. In your application configuration you set the data source name to myBlog user root password whatever
Now, when users start using your blog to access, post to, and comment on threads, etc... I am assuming they connect as root through the application myblog ...
So... users connect to the application myBlog who in turn connects to MySQL as user root , using password whatever --- it's not really the users that are connecting to MySQL, it's the application. Correct?
Is there not a security issue with this approach? Should I create a new username in MySQL for the application myBlog with specific privileges and leave root only for administering the database?
yes, the application connects to the db. you should create a new mysql user for your application, do something like
CREATE DATABASE myblog_env;
CREATE USER 'myblogenv-user'#'%' IDENTIFIED BY 'your pw';
GRANT ALL PRIVILEGES ON myblog_env.* TO 'myblogenv-user'#'%' WITH GRANT OPTION;
something like the above should do it. The 'env' part of the above is for if you want to create a new db for difference environments, like dev, stage, prod, whatever....
this way your application user has complete access to its db, but no other dbs in the mysql instance.
First of all, you should NEVER use the root account of a mysql database for anything else then admin work.
Second of all, in theory yes the user of your blog would be the "root" in your mysql database, but hopefully there is a lot of sanatizing and cleaning up in your blogs code before any queries are executed...anything else would be know as an "sql inject"
You are exactly right. This is called the principle of least privilege. You should give the application the minimum access rights that it needs to complete the job. This would not be root.
The short answer is: Yes.
Long answer:
Security: You should have a different user for your application than you do for yourself as the administator. That application user should only have read (and write if necessary) privileges on the specific database it needs to access. Also, it should not have privilege-granting privileges, nor drop table privileges, nor database creation/dropping privileges, nor anything else that is reserved for you.
Convenience: If you ever need to change your password, you don't want to have to change your application, and vice versa.
How can we prevent the the query "show databases;" or "show tables;" in mysql for any non root user.Is this possible.If so please provide an example or appropriate link...indicating this..
Thanks in advance........
Non-root user sees all databases only if he has global rights (like GRANT something ON *.*). So the solution is to always grant everything ON databasename.* , never global.
I would give show_db_priv a try:
http://dev.mysql.com/doc/refman/5.1/en/grant-table-structure.html
But, there have been reports of this not working. See this bug entry:
http://bugs.mysql.com/bug.php?id=1048
Can't get you a link right now, but this is a permissions issue at heart and control over access to the root user.
On something like phpmyadmin or some other tool, you want to revoke permissions on these two databases (and any others) to all users except for your root admin. If you're on a shared server where you typically get one user for your one database you'll need to talk to your host.
My general rule (if I've got permissions control over the db server) is to create a new user for a specific database or (subset of tables) and always use that user only from the web or other application that talks to the db. It's more setup initially, but once you've got it setup you've got much more control and know that one application can't interfere with another.
Root access is simply not allowed for application use - its for maintenance only.