Are there any approaches or architecture design patterns to implement secure, clean role/permission based access control and UI conveniences without coupling them together?
The long story.
I have seen ambiguous use of roles and permissions in many web applications and I have often experienced how these ambiguities have caused misunderstandings and implementation difficulties.
Here is a simplified example.
Business requirements say that permission set for some specific role should deny access to some part of the system that displays a full list of addresses. But at the same time, users of this role will need to read the addresses for an autocomplete list on some other web page.
I have seen how reckless developers create a permission entry to disable access to addresses, and later they discover that users actually need to read the addresses from other parts of the system. Then they invent another specific permission for special cases where addresses can be read.
But for me it seems ambiguous and potentially risky situation. If user has no access to some specific data, then he/she shouldn't be able to access it at all. Period. Adding a special permission just for dropdown lists seems like a deliberate security hole. If user loads the list through an async request and the server is using the same controller action to return the list (and it should - to avoid code duplication), then how the server will know when it should not return the addresses, if they are sometimes forbidden?
This situation raises the question: "why shouldn't users of some specific role see the full list of addresses in the first place, if they have access to the list through some other means?" And the answer I often get from business analysts is something like "Well, the address list is not forbidden for data security reasons, but just because users of this particular role are not expected to do anything with the address list and it would be redundant item in their workspace".
So, now the problem seems clear to me: some permissions exist just for controlling the UI and not strictly for controlling access to some data. Such (ab)use of permissions feels wrong to me. Therefore the question which was given at the very beginning.
Good writing! It pretty much feels that you already have your answer.
IMO user profiling and user access are not the same thing. Access rights should be handled as low level as possible (eg. if or not a user has read-access to a specific SQL table) and profiling in this case should only apply at the UI level ("what the user actually wants or needs to see").
When we talk about an application that has some kind of access right control, there's almost always some kind of an "engine" behind the UI that actually holds all the data. The WORST thing ever you can do is implementing the security anywhere else than the engine itself. The data must never be accessible in any other way than through that engine's own access control or otherwise it's not access control - it's UI restriction.
But that's the perfect world :/ In reality, like in all areas of work, software development also has been driven torwards being more and more cost-effective, agile and responsive to the client. Not surprisingly, this guides people to do fast and cheap decisions... like "hell, let's just make another SQL procedure that pulls the data out as an admin" instead of "we need to re-evaluate user access rights, and/or possible redesign our tables to keep consistency with the access privileges". It's always a short-term (bad) solution WHEN it's done, but some solutions are definitely more NO-NOs than others.
As a guideline I'd say that if you're not 110% sure what you're doing, it's a biggest NO-NO there is.
TL;DR: If some data should be accessible even in one place, it's not restricted by access control. If it's unneccessary to show accessible data somewhere, use user/application profiling for filtering it.
Related
I've worked at companies where an admin role is able to select and view another user's private data (view the system as if through another user's eyes). In today's day and age, is this good, ethical practice?
Generally yes. An admin is typically representing the data controller directly (and may even be employed by them), and access to their data is often both useful and necessary as part of the service they are providing. Data processors (third parties acting on behalf of the data controller) in that role are subject to a data processing agreement that will usually include confidentiality requirements – this is something I do quite often.
That said, there are scenarios where you may be handling "special category" data (to use GDPR terminology), such as medical records, where you may need to be stricter about access and processing, and you might want to make use of security measures such as encryption of data at rest - admins in that situation can control exactly what the database server does, but may not be able to see what the data contains (for example using the encryption mechanisms provided by CipherSweet).
In special category situations, GDPR requires that you conduct a data protection impact assessment (DPIA) and/or a privacy impact assessment (PIA) before implementing solutions, so that you you are able to justify your decisions should an information commissioner ask for it. These sound onerous, but they are actually an interesting exercise, helping you introspect about your internal practices more objectively. Take a look at the excellent open-source PIA tool published by the French information commissioner, CNIL, to help you build these.
So in short, it's generally OK, but there may be cases where you don't want to allow it, or only allow it when using additional security measures.
So I have decided to rewrite an application I have been writing in Node.js to Elixir because of all the extra complexity working with Node that Elixir comes with out of the box.
My issue was something I didn't have quite right in Node and is becoming just as complex in Elixir and I am not entirely sure how to go about approaching it.
I am trying to recreate a lot of how Discord does permissions. I am essentially building a CRM system, with different roles like "Sales Manager", "Sales", "Customer Service Rep" etc... But they all are able to do different things based on their "role".
Some things I need to do is be able to update a permission on the fly for a person or role. Maybe the "Sales Manager" role can't look at company financial data like an "Accountant" but we need to give that specific person access for a few days. Or I have a "Customer Service Rep" and we give that entire role the ability to add things to a calendar. I also would like to have the ability to kill sessions.
So there are a few ways I've seen said around Elixir forums, like:
Using Guardian, I really want to like tokens and think not having to hit the database every time sounds wonderful, but I don't think it's practical for this. Unless there is a good solution to updating tokens on the fly which I haven't found.
Giving each person their own process and just kill and start the process on changes with new changes. This seems pretty neat, but I'd rather not kill processes unless there is an actual error, I think this solution will come with big problems, like tracing problems. Although I am not familiar enough to know if this might actually cause problems, or if this is a bad solution for other reasons.
Use Guardian with Guardian_DB, which then defeats the purpose of using tokens, but at least I'd have a trackable session. My only problem with this is I do plan on using a load-balancer so that if a socket connection dies I can reconnect it to the same server and I am not sure there is a way to do that with tokens or if the socket itself has a session attached to it. This is not really that big of an issue though and is pretty close to what I had with Node.js.
Use Redis which I'd like to stay away from, and then update session data in Redis based on user_id when updates occur and hit Redis on every request to see if the user has permissions. I plan to put this across multiple servers eventually which means ETS is not viable unless I can load-balance socket connections like I could in Node.js.
So I guess my questions are,
Can I attach sessions to sockets? Is this a bad idea?
Should I still use a token, and just use Redis to check the token on every request?
Is a token still a better choice than a session?
Is there a much better/easier solution that I have not even mentioned?
I'm sorry this was pretty drawn out and long, I've never had to do something as permission bound as this project professionally and am pretty new to Elixir.
Phoenix channels are stateful. You can put data in the assigns field and it stays there for the duration of the connection. That is where you normally put your user_id after authenticating the user on join.
I also use the channels assigns to store client state that I need on the server.
WRT to the role to permissions question, I'm doing exactly this. What I do is load the load the role permissions from the database on startup and build an ETS store with them. You can do the same with a Task or a GenServer. If the permissions change for a given role, i update the database and the ETS table.
My user model supports a list of roles for each user.
When in need to validate the permissions for a given user, I call the Permission model api like Permission.has_permission?("create-room", user, scope). I have two level of permissions, global and per room. That is what the scope is used for.
I'm trying to implement a claims-based authorization setup using Web API/OWIN/OAuth and I'm trying to find out the best way to manage a more fine-grained type of authorization.
I don't like the idea of using just roles, as there needs to be lots of fine-grained authorization in the application I'm working on. I was thinking a roles+permissions approach made more sense (where a role simply maps to a subset of permissions). The permissions would be based on an action+resource pair (e.g. CanViewEmployee, CanEditEmployee, etc.). Nothing out of the ordinary here.
However, I'm wondering how this should be implemented using OWIN/OAuth, possibly using Thinktecture IdentityServer. I am trying to avoid hard coding the permissions in the custom AuthorizationManager I have as they need to be easily changed without a rebuild. I know it is an option to put these as policies in the web.config (mapping a resource+action to a claim type and value), but if we are talking about dozens, maybe even hundreds of permissions, this seems like it could get out of hand pretty quickly as well.
I guess the third option would be to drive it all from the database, but managing it from there would also need some kind of front-end to do so, which is more effort than just changing a config/XML file.
Am I missing some other options/best practices here when it comes to large numbers of claims/permissions, or perhaps some other utility or package I could use to help manage this when the numbers get out of hand?
Decoupling these permissions into a separate authorization manager class is a good first step. In that code you could then hard code the rules for your permissions (such as "Admin" role can do action X, Y and Z, but only "Manager" role can do X or Y). But you can also have the code in the authorization manager perform dynamic look ups to check permissions that have been set in in a database (for example).
The additional benefit of doing this in code is that you can unit test it all to prove your permissions logic is implemented correctly (and thus will be properly enforced at runtime). This will be useful if your permissions do change frequently.
Also, the decoupling will help if you need to redeploy frequently (because of the frequent changes), since the code can be isolated into its own assembly.
Is it possible to create a script that is executed outside of the server,
or with a browser add-on for example it automatically fills in form values, then submits the form all ready to be parsed by the server ? this way in three minutes a billion fake accounts could get registered very easily, imagine facebook which does not use any visible to the human captcha, a browser add on that performs the form submission and inserts the vals retrieved from a local database for new emails to be associated as that is a check - no duplicate emails, can thousands and thousands of fake accounts be created each day accross the globe?
What is the best method to prevent fake accounts? Even imagining the scenario of a rotating ips center with human beings registering just to choke the databases, achieving 30-50 million accounts in a year. Thanks
This is probably better on the Security.Stackexchange.com website, but...
According to the OWASP Guide to Authentication, CAPTCHAs are actually a bad thing. Not only do they not work, induce additional headaches, but in come cases (per OWASP) they are illegal.
CAPTCHA
CAPTCHA (Completely automated Turing Tests To Tell Humans and Computers Apart) are illegal in any jurisdiction that prohibits
discrimination against disabled citizens. This is essentially the
entire world. Although CAPTCHAs seem useful, they are in fact, trivial
to break using any of the following methods:
• Optical Character Recognition. Most common CAPTCHAs are solvable using specialist
CAPTCHA breaking OCR software.
• Break a test, get free access to foo,> where foo is a desirable resource
• Pay someone to solve the CAPTCHAs.
The current rate at the time of writing is $12 per 500 tests.
Therefore implementing CAPTCHAs in your software is most likely to be
illegal in at least a few countries, and worse - completely
ineffective.
Other methods are commonly used.
The most common, probably, is the e-mail verification process. You sign up, they send you an email, and only when you confirm it is the account activated and accessible.
There are also several interesting alternatives to CAPTCHA that perform the same function, but in a manner that's (arguably, in some cases) less difficult.
More difficult may be to track form submissions from a single IP address, and block obvious attacks. But that can be spoofed and bypassed.
Another technique to use JavaScript to time the amount of time the user spent on the web page before submitting. Most bots will submit things almost instantly (if they even run the JavaScript at all), so checking that a second or 2 has elapsed since the page rendered can detect bots. but bots can be crafted to fool this as well
The Honeypot technique can also help to detect such form submissions. There's a nice example of implementation here.
This page also talks about a Form Token method. The Form Token is one I'd never heard of until just now in this context. It looks similar to an anti-csrf token in concept.
All told, your best defense, as with anything security related, is a layered approach, using more than one defense. The idea is to make it more difficult than average, so that your attacker gives up ad tries a different site. This won't block persistent attackers, but it will scale down on the drive-by attacks.
To answer your original question, it all depends on what preventative measures the website developer took to prevent people from automatic account creation.
Any competent developer would address this in the requirements gathering phase, and plan for it. But there are plenty of websites out there coded by incompetent developers/teams, even among big-name companies that should know better.
This is possible using simple scripts, which may or may not use browser extension (for example scripts written in Perl or shell scripts using wget/curl).
Most websites rely on tracking the number of requests received from a particular browser/IP before they enable CAPTCHA.
This information can be tracked on the server side with a finite expiry time, or in case of clients using multiple IPs (for example users on DHCP connection), this information can be tracked using cookies.
Yes. It is very easy to automate form submissions, for instance using wget or curl. This is exactly why CAPTCHAs exist, to make it difficult to automate form submissions.
Verification e-mails are also helpful, although it'd be fairly straightforward to automate opening them and clicking on the verification links. They do provide protection if you're vigilant about blocking spammy e-mail domains (e.g. hotmail.com).
We're building an application designed to run on Windows-based servers. One of the considerations we're looking into at the moment is how to control access to the application's GUI, which allows configuration and controls the "back end" services.
In order to secure the application properly, there are several objects which will need ACLs to be applied - files, directories, Registry keys, named pipes, services etc. We need to provide administrators with some way to configure those ACLs in order to limit access to authorized users only.
One approach we have considered is to create a tool which can modify the ACLs on all those objects simultaneously, but that would be a fair chunk of work and could be fragile.
The other possible approach we're looking at is to create a custom group (e.g. "My App Users") so we can give that group the appropriate rights to each object. This means that administrators will be able to add/remove authorized users by using familiar Windows group membership tools.
So: is creating groups at install time an acceptable thing to do, or is it likely to upset administrators? I'm more familiar with the UNIX world, to be honest, where server-based apps are more or less expected to create groups, but I'm uncertain of the etiquette in the Windows ecosystem.
Also: is there a better solution to this that I've missed?
Thanks in advance!
The question is twofold - one technical, and one political. Technically a local group is fine, you can add AD or domain users into a local group and everyone's happy. In terms of whether an app should be messing with a server's security 'stance', the only reasonable answer is to pop up some kind of request telling the user what you are going to do and asking permission (make sure you also document the decision in some kind of log or entry). This also addresses everybody's legal a$$ eg if they click "no, leave my app unsecured" and get hacked).
Taking a UNIX approach, you could tell the user what you need, suggest a local group (and give the user the chance to pick another local or domain/AD group). Take a look at how (eg) Oracle installs on UNIX do it.
Since this is a server app and you might have to support silent/unattended install, make sure that the behavior can be specified in the install script and very, very sure that the behavior of the script is documented so that no one installs the program without realizing the change in security policy that the installer implements.
I think it's perfectly fine to create a local group for this purpose.
Furthermore I have not been able to come up with a better solution after giving it some thought.
Depending on the size of the implementation, groups could be the way to go.
But please keep in mind that the relevant ACLs on directories and the registry ought to be set. I do agree that setting them once to the group and then let access control be maintained by group memberships.
In regards to klausbyskov's answer, I think a local group could be fine, but consider using LDAP instead. From a security perspective you would detach the authentification process and let the Directory handle it; using kerberos.