I'm creating a web app that users will create an account for, which allows them to read/write data on a database. I'm about to start creating the login authentication part of the website, and its my first time really doing this part. As I understand it, I'm going to create a users table which will store all the necessary login info for the website.
I know there are also database roles/permissions. My question is about how the 2 relate in this instance. Do I need to authenticate the users on the website and the database? My thought process was that if all of my PHP scripts are set up in such a way that the session data will only allow authenticated users read/write to the DB, then I don't need to do anything on the database end, but I want to make sure I'm thinking about this correctly.
Is that clear as mud?
If I understand correctly, your question is wether or not your users need access to your database.
Your users are not going to communicate with the database directly. Your app will. Your users are only going to use your app which will act as an interface between the user and the database.
Therefore, only the app needs access (and the appropriate permissions) to the database. Because it now has access to the database, it becomes responsible for making sure that only the right people can perform certain actions. (by means of a login- and permission system)
If not all users should have the same permissions within your app (you might have normal users and administrators), you need to create a permission system within your app that checks wether a user has the appropriate permissions to perform a certain action.
For instance if someone tries to delete some important data, you
make sure he's logged in (if he's not, redirect to the login page)
make sure he has the appropriate role / permissions (in this case he should be an administrator - if he's not, cancel the action)
Symfony's page on Security gives some insight. Just skip the Symfony-specific parts and read about the general idea.
Your users will authenticate on your website (by requesting details about their validity from the database). Once authenticated they can do things that the website gives them access to.
The only user that will communicate with the database directly is you/your website. Your database will have a table entitled 'users', but the actual user of the database should be no one else but you - you don't want to give random users free reign. You can then set what database queries you wish the database to perform on certain users actions.
Hope that helps clarify
Related
I have several different types of users who use my system. One set of users is unique as all their credentials are accessed via LDAP, the other users are all relatively similar but do have different roles. I am using the built in User class for the regular users (that is, not the ones who login using LDAP) and am using Laravel 4. I query the LDAP and it returns either success or failure but once I've done that I don't have a user logged in per se. I set up a "fake" user in the Users database, which I could then manually authorise by using it's id
Auth::loginUsingId($user_id);
In this case, when I have verified their details via LDAP I manually authorise them using the dummy account. In this sense, every user who logs in with LDAP credentials is authorised as this single dummy user. While this works it means making a redundant User with false information and it is just generally quite messy. Furthermore, I lose the rich information the LDAP provides.
Effectively, I'd like to be able to authorise a user when they are not actually a User according to the Users table. I believe the solution may lie in altering the UserProviderInterface.php or the EloquentUserProvider.php.
So I'm currently in the process of creating a small public website (where users can, for example, log in and change personal information), but I am wondering how the database security is actually designed for that type of thing, so I have several questions.
When an internet user accesses a page like stackoverflow, for example (without logging in on the site), which database user or role is he logged on in order to be able to see all the posted questions? Then, when the user logs in with his account, does his role in the database change (since he has more rights)?
If I setup my database to have a "Users" as well as a "Permissions" table, I can make sure that a user can only have access to his own data, at least application side. But how do I make sure the data is still protected database side since I suppose every public user has the same "database login" or "role"?
I know my question is probably a bit unclear, but don't hesitate to ask me for clarifications. I didn't really know where to begin.
Thanks.
P.S.: I'm currently using SQL Server
Database role doesn't change, but functions do. Users are authorized from the back end code, not from directly database. If you are trying to create logins for every single user for your database, that would not be a good aproach since there could be thousands or milions of users which somehow can have direct access to your database with some permissions.
You've almost answered your own question.
Generally, your website will run under some user account, lets call this 'IWEB', this user account will be the same for everyone that hits your website, regardless of whether the user is logged into your website or not.
IWEB will have permissions to read data from a database. That's how the anonymous users work.
In your database you will have a user table, possibly a permissions table. IWEB will be given database permissions to create new users, update users. It possibly will be prevented from deleting users.
Your application will (though IWEB) use these tables to control who has access to your application and who can update what. A bug (e.g. SQL Injection) in your application could allow a malicious user to create admin accounts, change other users passwords etc...
In certain scenarios e.g. using Windows Authentication, you can pass through the user logged into your site, translate that into a database user and given them permissions. However you are unlikely to do that for a public facing website.
You could possibly do something where the tables are not directly accessed, but are controlled through stored procedures, denying access to the underlying tables. One of the parameters is the currently logged in user, that could then control access at the database layer (prevent a user updating another users profile). Unless of course your application has a bug that could allow an attacker to change their currently logged in user.
It all depends on your security requirements. In the main though, you will control access at your application.
What's wrong with having an Anonymous user in the Users table, having the lowest privileges in the Permissions table?
To your first question: When a user first lands on a web page they have no 'role'. Your scripting will decide what the users can and cannot see.
For example you have a post that only certain user can see. That post will be hidden by default. Your script should then run a test to see if the user is currently logged in and if that user is in the permission group to view that post. If they are, then show the post.
Your database should not be accessible either way.
I am in the process of making an app that will allow certain users to insert values into a database. Atm if I go to the php file and add ?year=235&name=ggg to the end of the URL it would be added to the database. What would be the best way to protect against this and only allow information coming from the app to be entered in the database? Or is it a waste of time trying?
I know really the only way for people to get the URL for the php file, is if they used something like wireshark/packet tracer.
At the very least, you should be using HTTPS. Secondly, it would be wise to use some form of OAuth. That way, one would require a special token, which the user themself doesn't know, in order to access your page, and you could restrict database access to users who are authorized.
I have to provide access rights like edit, view, delete values in the database to the users dynamically in php, so that the super admin can change the privileges from the application itself.(no need to open the database and do it for each and every user).
When you create the database, you also create the users with the different rights you need, the you have a configuration file, where each user is mapped to a specific DB user, then when you make the connections, you are already using that user with the specific rights. You detect the user when they log in the application.
You may also change a bit the interface of the site to each user group, so you don't show controls or actions not related to that group.
There is a portal that a company's users are familiar with, and we will put a link to login to a different portal on a different machine. This process would not require username/password check, just hitting the link will log them in.
How can this two delivered in secured way? We don't want that anyone with the link to be able to log in, how can we make this to work between the two platforms?
I'm presuming the two portals aren't able to share sessions/cookies. If they are you can just use those to keep track of who is logged in where.
In the situation where that's not possible, you could use an authentication API, which you could query to see if a given user_id is logged in on that portal. This could be a very simple API which returns a yes or no, or you could develop it to be more complex.
Additionally keep in mind that there are Open Source choices out there. Open ID is a system that stackoverflow uses, for example.
Easiest method would be script on main site, that waits for session ID in POST/GET input, if session exists, it outputs user name. The new site server, when user comes in, reads in cookie with session ID, sends a request to main site server script and asks if session ID exists, if exists, uses that user name, for new site server.