I'm just getting my toes wet in MySQL DBA and created some users and assigned roles to them. It took me a long time to realize that this on its own didn't result in the user assuming the roll when they login. This led me to learn about activate_all_roles_on_login and SET DEFAULT ROLE. I understand what they do, but I'm struggling to imagine a scenario where you wouldn't want the users and roles you created to be active after logging it.
I know I must be missing something, what are some reasons you wouldn't want this as default behavior?
Are there any things to be aware of when setting activate_all_roles_on_login to true?
They're called roles for a reason. By the SQL3 standard, database users are supposed to be able to adopt only one role at a time. Like when a live stage play has too few actors, they need to play multiple characters by throwing on a different coat or a hat. The idea is that a user shouldn't have the union of the privileges of all roles they are permitted to use. They should use SET ROLE to choose one at a time.
This can be practical, for example a "backup" role may allow read-only access to data for purposes of making backups. You wouldn't want a user to have read-write access while using backup tools. But at other times, the same user doing transactions may need read-write access, though only to a limited set of tables. In some ways, this is like the principles behind SOX compliant security: No single user should have unlimited access by themselves.
MySQL does have a feature to allow a user to adopt multiple roles simultaneously. For many applications, this would be perfectly reasonable, which is no doubt why MySQL added this as an extension to standard SQL. If this is ordinary for all users at your site, you may therefore choose to enable activate_all_roles_on_login. But it's not standard SQL, so it's not enabled by default.
Related
So currently I'm working on a web application for a game and stumbled upon the following "problem"/question: Is it actually safer to have an individual table for the players/users and administrators?
Personally I think it's not and storing them both in one table would also be easier and more efficient, since every administrator is considered a player as well, but some people tell me it's safer to separate them without a clear reason why.
As for now I have them both stored in one table and am using a role based permission system.
By separating them you could control permissions to the tables with more granularity, for example limiting access to the administrators table to only certain database user accounts (so that it cannot be accessed by "game" code/servers at all).
But outside of those kinds of scenarios, I can't really think of one and agree with the second comment to your question.
Unfortunately this question may be a little broad, because I can't work out the proper terms to help me bring all this together. I'm very new to php/SQL, and I'm attempting to set up a minimal site with very simple login/register functionality.
Should I be creating a new database user whenever I register a new web user?
Are CRUD privileges safe to give to all users of the website?
Should I actually make a DB user for registering, one which can only insert into the user table and nothing else until they login (requiring no password for mysqli_connect())?
Once logged in, they would make a connection to a different type of DB user, one with more privileges to use the website.
How many different types of DB users should there be?
I assume a small group of users for the DB workers (including one for root access), another group for each type of web user (ie. employers have more privileges than employees), and another restricted user just for registering.
All in all, would >10 DB users in a small website be unusual?
Is there a performance/space cost associated with having many types of users?
I appreciate any responses and links, and apologize if these are very basic questions.
I struggled with this all those years ago, so here is the answer I wish I had:
Generally, this is overcomplicating things, and the headline answer for a basic application is: the permissions of users will be managed by the PHP code in the API calls you make, and one DB user is fine. All users should avoid interacting directly with the DB for app dev generally, to prevent violating the sanctity of the data.
It's good to think about security and restrictions, but simplicity is king - the more complex you make it, the harder it is to maintain, and therefore the easier it is to miss corner cases.
Should I be creating a new database user whenever I register a new web user?
No, database users are distinguished by their privileges. As a result, all users conform to a set of groups with varying privilege levels. The database accounts are separate from the web accounts - connecting to the database is done behind the scenes and has no link to the web account being used.
A good approach would be to create a DB account for each service connecting directly to the DB. For the vast majority, this will be one service, your web server. If the application grows and isolated services such as audits, microservices, security, IOT spring up, they should probably have their own accounts.
Are CRUD privileges safe to give to all users of the website?
The question is misguided - you give the CRUD to the DB account, which will need it. For the CRUD permissions managed inside the PHP, it really depends on your app and specific endpoints. For example, you probably don't want all your users to be able to delete User records, so your PHP code should prevent that from happening.
How many different types of DB users should there be?
The number depends on your database. Generally, there are 4 groups
Database Administrators
Database Designers
Casual End Users
Native End Users
However, if you want to grant table level privileges then you might need to branch out a little more. This would suggest 10 DB accounts is quite a small amount, several hundred is more likely.
The more privileges, the more space is required, but it's a fairly minute consideration, and shouldn't play a big role in performance. Complexity is the next issue - think carefully how many groups and permutations you actually want to test. In the case of the question above, I was a single hobbyist developer - one account as a DBA is probably fine. If there were multiple users directly accessing the DB (already probably a bad idea for app dev), then maybe split out them with varying permissions.
Talking about table level permissions for a simple app is just way overkill!
What I am trying to ask is ...
Users will only ever access the database via my application. The application itself allows an admin user to create/modify/delete users and give them certain privileges. So, I have a table which contains each users log-in name & password.
I am still developing the app, so it currently logs in as root with no password. Obviously, I will change that, but what's the best practise? Should I have a single database user & password which the application uses, or should I create a separate user for the databaase each time a user for the application is created (or modified)? The latter seems like more work.
Your APPLICATION should certainly have separate user ids and passwords for each user. Given that, there's no reason for the application to have multiple user ids when it talks to the database. As long as the application's security is implemented correctly, there's no gain from having multiple DB user ids.
Giving each user his own DB user id would surely be a gigantic pain because it would likely involve all sorts of special cases and exceptions. For example, to log in to your application, the application would have to validate the user's id and password. How will it do that if the user doesn't have access to the password table? But if anything needs to be protected from unauthorized access, it's the password table. So you'd have to use one userid to do the login, then take that away and give a different userid. It's likely that there are other tables that a given user might be allowed to access in one context but not in another. The accounting department likely needs to see total amounts paid in salaries for the year, but maybe they can't see individual employee's salaries. Employees may be able to access data about their own benefit, but not that of other employees. Etc.
The only exception I can think of to this would be if you allowed some sort of generic access to the database. To take the most extreme case, if you had a screen where the user can type in an arbitrary SQL query which you would then execute. In that case, you could theoretically have the application analyze the query and attempt to apply security rules, but that would require your application to embed an awful lot of knowledge about SQL. In that case you'd be better to give each user his own DB user id and putting the security rules into the database engine.
Short Answer: Before the internet, yes. After the internet: nobody does it, but it is still perfectly acceptable.
Common practice in the internet age is to consider your application to be the user, and to give that application a login. The only actual benefit is some performance boost from connection pooling. The perceived but illusory benefit is security.
Understanding the security angle requires the realization that all security in the end resolves down to who can read and write from what tables, rows and columns. To see how this works, consider a user who is authorized to manipulate a highly secure table, and another user who cannot even see that table. The less privileged user successfully manages a SQL injection attack attempting to wipe out the secure table, it fails because the Database prevents access by that user to that table.
The takeaway is that there is no technical reason to use a single login except if connection pooling is important. Databases are very poorly understood by many internet age programmers so explaining how to use their built-in security is an uphill battle against many pre-conceived and incorrect ideas.
There's no reason to create a database login for each user. It's really your app that's interacting with the database, not the user. Creating extra logins just makes your database that much less secure.
In several frameworks (symfony/Django), you have admin generators that usually control access via a User table (which assigns a user to a specified Group table).
I'm curious, why not simply use MySQL's actual users (with select/read/write access already baked in) instead?
Another good reason that hasn't been listed is the fact that MySQL usernames/passwords are stored in clear text in config files. There maybe a vulnerability in your code that allows a user to read a text file, which then would give immediate access to a hacker without having to breaking a password hash. Having a your database remotely accessible is a serious secuirty hazard and is prohibited by PCI-DSS.
Another good reason is that in order to add new accounts or change your password your web application would need ROOT access, which is among the worst things you could do. In many databases (including mysql) this makes it very easy for a hacker to turn a sql injection vulnerability into full remote code execution (like uploading a .php file).
I would presume one reason would be, that many ISPs provide you with only one user account (without extra cost) to your mysql database, and thus, such an aproach wouldn't work as everyone would have identical priviledges.
The magic here being lowest common denominator and easy deployment as far and wide as possible, with minimum requirement in server administration.
I'd imagine most people are a little leery giving their application's MySQL user the ability to create and grant privileges to new MySQL users, particularly in a shared hosting environment. It's not that difficult to handle, it keeps everything within one database table, and you can have any permission you like.
For a web application, when creating the user which will connect to the MySQL database, you have the choice of privileges. Assuming that the only actions intended to be done by that user are SELECT/INSERT/UPDATE/DELETE, it seems to make sense to only provide those privileges, however I've never seen that recommended anywhere - what are the reasons for and against this method?
I disagree with Bill here and Atomix's line of thinking is more suitable. Unless it can be demonstrated otherwise, Bill's answer highly increases the risk of the database being compromised.
Perhaps for very experienced developers there is other security in place, but for other developers giving a script full, unfettered access to do ~anything~ to a database is asking for trouble, when there is no need to.
The principle of least privilege should be in use here. For MySQL, have a super user with all privileges which is used for creating tables, drop database, and so on. Ideally this username and password is never seen in any PHP file or any file on the web server. (I'm using PHP as an example but it applies to other web applications). You would only use this username and password with something like PHPMyAdmin or MySQL Workbench.
Then, for PHP scripts, have one with the minimum required, such as just INSERT, SELECT, UPDATE, maybe not even DELETE, depending on your PHP script. This would be in the PHP files, that is, actually only ONE file OUTSIDE of the document root, as is recommended by most.
The reason is thus: yes, you do not need a MySQL user for every web application user. But principle of least privilege ( http://en.wikipedia.org/wiki/Principle_of_least_privilege ) should apply. If somehow your MySQL super user is compromised because you accidentally named your MySQL connect script as .txt instead of .php, or someone gained access to the web server files, at least the "worst" they can do is SELECT, UPDATE and INSERT... Which while can cause big problems anyway, is not as bad as giving them DROP DATABASE, DROP TABLES and much worse things.
Additionally, in my current project due to agile development practices (I do not work for but recommend http://www.agilealliance.org/), one or two "non-tech" team members are directly using PHPMyAdmin to make direct changes to the MySQL database. This is because creating a CMS for simple direct data entry is not required. In this case, a third MySQL user with reasonable but again, "just enough" privileges is suitable for them. We don't want to cripple the team member with too little privileges, but of course they shouldn't be able to accidentally delete or change things.
Since MySQL doesn't have ROLES (as of the time the original question was asked, and as per Bill) then allowing any web script to just access MySQL with only one Super User is very risky.
There are other privileges that a user might need during an ordinary application, for example:
CREATE TEMPORARY TABLE
EXECUTE (stored procedures)
FILE (for SELECT INTO and LOAD DATA)
LOCK TABLES
There's also the possibility that minimal privileges could mean only SELECT on certain tables, and only SELECT and UPDATE on other tables, etc. This is subject to change any time the application's functionality is enhanced. And there are weird cases, like the need to have SELECT privilege on a table you never query, because it's referenced by the foreign keys in a table you UPDATE. So tracking minimal privileges is a royal pain.
What are you trying to restrict by using SQL privileges? You're the one who wrote all the code, so managing SQL privileges at a fine granularity shouldn't be necessary. Frankly, if your users are able to upload and run SQL statements that you haven't vetted, you have bigger problems:
SELECT * FROM mytable, mytable, mytable, mytable, mytable ORDER BY 1;
The real tasks you want to govern aren't at the database level, they're at the application business level. For example, a CMS has operations like create a page, edit a page, administer comments, etc. These tasks are higher-level than SQL privileges. You could mimic them with SQL roles (which are groups of privileges), but SQL roles aren't widely supported.
I don't know anyone who maps their application users to distinct MySQL users. They're users you authenticate in your application, after the app has connected to the database (the users are just rows of data in the database).
So you're probably better off having your web app use a single MySQL user with full privileges.
A web app usually uses just one user to access the DB, rather than a user per actual user account. Applying minimal privileges is good practice. The username and password is going to be coded into your script (does anyone obfuscate this?) so there's room for compromise if your scripts aren't managed properly.
In my experience, I very, very rarely have the app delete rows - much better to flag a row as deleted as you then have an audit of what is there rather than not knowing what was there! This approach also helps keep tables and indexes optimised.
Therefore, I would suggest allowing only INSERT, UPDATE and SELECT - it will quickly become apparent if parts of your app need to be relaxed a bit!
Allowing more privileges can only broaden the possibility for DoS attacks by issuing resource intensive commands, or allowing malicious data attacks.