We have the angularjs application where we have different roles associated to the users. For ex: the two roles are Admin and Local. Based on the role, we show some menu items for the Admin and adds more features/screen to the Admin .
The userInfo with the Admin Property is returned from the login response and based on what we decide which all menu and screens to be rendered .
But if we user the developer tool, and the set the break point where the admin property is used, and set the admin property as true the user even he is a local user would be able to access admin privileges .
In short who has some idea about the javascript code can get the admin privileges . Is there any idea other than minification of the code to prevent this kind of security threats
Thanks
As the front-end of your application will run on the client machine there is actually no way to stop a user from debugging or modifying the code. Thus it's impossible to prevent someone from tricking their local instance of the application to think it's signed in as an administrator.
If you simply want to hide the admin interface, one possibility is to have separate (or additional) templates for administrators and restrict access to these based on the user's privilege. If there is anything to be gained from this is up to you. You will still need to validate the rights to execute any privileged action on the server anyway. Obtaining administrative privileges on the client must never be the same as obtaining them on the server side.
Related
I all, I'm writing a boilerplate for future projects. Composition is as follows:
Server:
Express,
Prisma 2,
Typescript,
JWT Auth (Access token in memory, Refresh in cookie)
MySQL
I'm writing an RBAC schema, and have successfully written express middlewares to determine if a user is logged in, and for if a user has a specific permission on their role.
If you've ever used any of the minecraft server permission plugins, I'm trying to emulate the common pattern used there.
Users have role(s)
Roles have permissions
Roles can inherit permissions from one or more roles
Roles have a "nextRole" field to determine what role to give when the "promote" event is triggered.
Everything works fine on the server side.
What I'm wondering about is, how should I go about copying the middlewares (login, permissions) to the client side, and how should I determine whether a user has permission to do something?
What I've looked at:
Creating a "hasPermission" endpoint wouldn't be very good as I'd need to make an API call every time a permission check is needed.
Eager loading all roles and permissions from the api when logging in and returning them in the response (I can't eager load the recursive role inheritance/nextRole as far as I know)
Returning ONLY the user without roles and permissions for the JWT/login bit and getting roles/permissions from their own endpoints (again, needs to be recursive to get all inheritance and said permissions from inheritance)
Has anyone created an RBAC schema like this, and how did you go about checking permissions on the client side without being too redundant/using too much memory/too many api calls?
This is a good question, here's my answer to it.
An app is normally protected by the auth info, which means it could be blocked if a user is not permitted. If this is a server application, it can be easily done, because the session can be used to find out the current user info including roles.
However if this is a client app, it's a bit tricky. Say we can protect a route (page or section of page) once the user log in.
if (!user.authenticated) return null
We can use the above line to block private or public user. Or other information you can grab from the user to protect more.
if (user.role !== 'Admin') return null
We could wrap in these into a component, such as
<Allow role="admin" render={...} />
I believe you get the point. However there's something which is very unique about the client approach. The entire user info is returned back, and only the user info, not the user type or permission type.
So to follow your plan, do we need to share a permission or role type to the client side? This is a million dollar question.
In practice, the UI never needs the complete info, why? because UI normally reshapes the permission a bit. That doesn't mean you can't share the complete info from the backend. Doing that may make the UI job easy or more complicated. Nobody knows.
The reason is what I explained above, the UI is writing a if statement (could be hidden) anyway. Either this if is true or false, most of the front-end code is already loaded. It's very different than the backend version, which can entirely block the deliver of the content.
I am new to Salesforce, but am an experienced developer. I am provided a link to a Salesforce report, which mostly has the right filters (query). I would like to use an REST API to pull that information as CSV or JSON so that I can do further processing on it.
Here are my questions:
Do I need special permissions to make API calls? What are they?
Do I need to create an "app" with client-key & secret? Does my admin need to grant me permission for this too?
There are a lot of REST APIs from Salesforce, which one do I need to get the info from the report? Analytics?
How do I authenticate in code?
You'd have to work with the System Administrator on the security pieces. Anybody who knows how the company works, can all users see everything, is there Single Sign-On in place, how likely is the report to change...
You will need an user account to pull the data. You need to decide if it'll be some "system account" (you know username and password and have them stored in your app) or can it run for any user in this org. It might not matter much but reports are "fun". If there will be data visibility issues 6 months from now, you'll be asked to make sure the report shows only French data to French users etc... you can make it in report filters or have multiple reports - or you can just use current users access and then it's the sysadmin that has to set the sharing rules right. (would you ever think about packaging what you did and reusing in another SF instance? Making a mobile app out of it? Things like that, they may sound stupid now but will help you decide on best path)
The user (whether it'll be system account or human) needs Profile permissions like "API Enabled" + whatever else you'd need normally ("Run Reports" etc). If you're leaning towards doing it with system user - you might want to look at Password Policies and maybe set password to Never Expires. Now this is bit dangerous so there would be other things you might want to read up about: "API only user" (can't login to website), maybe even locking down the account so it can login only from certain IP ranges or at certain times when the job's supposed to be scheduled...
Connected App and OAUth2 stuff - it's a good idea to create one, yes. Technically you don't have to, you could use SOAP API to call login, get session id... But it's bit weak, OAuth2 would give you more control over security. If you have sandboxes - there's little-known trick. You can make connected app in production (or even totally unrelated Developer Edition) and use client id & secret from it to login to sandboxes. If you create app in sandbox and you refresh it - keys stop working.
(back to security piece - in connected app you can let any user allow/deny access or sysadmin would allow only say these 3 users to connect, "pre-authorize". Could be handy)
Login - there are few REST API ways to login. Depends on your decision. if you have 1 dedicated user you'll probably go with "web server flow". I've added example https://stackoverflow.com/a/56034159/313628 if you don't have a ready SF connection library in your programming language.
If you'll let users login with their own credentials there will be typical OAuth "dance" of going to the target page (Google login, LinkedIn, Twitter...) and back to your app on success. This even works if client has Single Sign-On enabled. Or you could let people type in their username and pass into your app but that's not a great solution.
Pull the actual report already
Once you have session id. Official way would be to use Reporting API, for example https://developer.salesforce.com/docs/atlas.en-us.api_analytics.meta/api_analytics/sforce_analytics_rest_api_get_reportdata.htm
A quick & dirty and officially not supported thing is to mimic what happens when user clicks the report export in UI. Craft a GET request with right cookie and you're golden. See https://stackoverflow.com/a/57745683/313628. No idea if this will work if you went with dedicated account and "API access only" permission.
One thing I do currently in an enterprise app is logon to a single admin email account that has delegation over other users and using delegation, we are able to manipulate email/calendar/contacts of users.
I'm looking to use the Microsoft Graph API and I have managed to use admin delegation and gain access to various resources, however last modified (on Onedrive/Sharepoint) is showing the app instead of an individual user.
I understand I can use Oauth and logon as individual users, capture a token and then do what I need under the context of that user, but, I need to do this server side where tasks run. Is there anyway to use admin approved delegation/impersonation from the app so that the users don't have to signin?
e.g. standard that works:
https://graph.microsoft.com/v1.0/sites/my-site.office.com/drive/root:/file.txt:/content
Looking to add a user tag, but this doesn't work:
https://graph.microsoft.com/v1.0/user/{id-of-user}/sites/my-site.office.com/drive/root:/file.txt:/content`
After searching for ages, the closest I have read seems to be in here however, I was wondering if there was a standard way of doing this - I haven't been able to get the JWT part of this working (and not sure if this is even the correct thing I am looking for).
I've written a security module for my MVC intranet that allows administrators to grant permissions to users for certain functions like viewing, editing, deleting etc. When an intranet user visits a page, the underlying security module checks the SQL database to see if an administrator has given them access to perform the task and, if they have the required permission, they can click a link or whatever.
What baffles me is that the above system doesn't work unless I republish the website after the administrator has granted the permission. The permission is stored correctly in a permissions table in the database but when the user tries to use the permission it doesn't work. As far as I can tell my security module is completely standalone and is just a case of reading and writing to a database using static methods like this:
if (SecurityManager.HasRole(Request.ServerVariables["AUTH_USER"], "edit")) { }
I'm sure this is just a basic flaw in my understanding but does anyone have any ideas how I can get this to work?
I am creating an Angular 1 SPA. Certain controls are only visible to users with certain permissions. This is based on scope variables set by server api calls.
It occurred to me that if I could access these variables through a browsers dev console, I could change their values.
I tried this for example:
angular.element($0).scope().$parent.myUserInfo.accessType = "admin"
angular.element($0).scope().$apply()
And sure enough, the admin controls popped up on the page even though I was not logged in as an admin. Is there a best practice to stop this or am I going about it completely wrong?
The authentication always have to be made on the server side.
I don't know what you are trying to do, but if the user interacts with some webService/Rest API, etc... the server should disallow such interactions.
If the accessType property of your scope is just a way for you to know which UI you should display to the user, and the authentication/session mechanism is correctly handled by the server, that should not be a problem.
However, you cannot disallow the user to play with the dev console, so you'd better handle the authentication correctly.
I am not sure if there is a way of protecting values in $scope.
But as JavaScript is executed client-side and it is therefore be possible for users to modify said code, I would always verify permissions server-side. Then it wouldn't matter if users enable the admin controls client-side as they have no permission to use the api calls.