Security Frame: Authorization | Mitigations

• Ensure that proper ACLs are configured to restrict unauthorized access to data on the device
• Ensure that sensitive user-specific application content is stored in user-profile directory
• Ensure that the deployed applications are run with least privileges

• Enforce sequential step order when processing business logic flows
• Implement rate limiting mechanism to prevent enumeration
• Ensure that proper authorization is in place and principle of least privileges is followed
• Business logic and resource access authorization decisions should not be based on incoming request parameters
• Ensure that content and resources are not enumerable or accessible via forceful browsing

• Ensure that least-privileged accounts are used to connect to Database server
• Implement Row Level Security RLS to prevent tenants from accessing each other's data
• Sysadmin role should only have valid necessary users

• Connect to Cloud Gateway using least-privileged tokens

• Use a send-only permissions SAS Key for generating device tokens
• Do not use access tokens that provide direct access to the Event Hub
• Connect to Event Hub using SAS keys that have the minimum permissions required

• Use resource tokens to connect to Azure Cosmos DB whenever possible

• Enable fine-grained access management to Azure Subscription using Azure RBAC

• Restrict client's access to cluster operations using Azure RBAC

• Perform security modeling and use Field Level Security where required

• Perform security modeling of portal accounts keeping in mind that the security model for the portal differs from the rest of CRM

• Grant fine-grained permission on a range of entities in Azure Table Storage
• Enable Azure role-based access control (Azure RBAC) to Azure storage account using Azure Resource Manager

• Implement implicit jailbreak or rooting detection

• Weak Class Reference in WCF
• WCF-Implement Authorization control

• Implement proper authorization mechanism in ASP.NET Web API

• Perform authorization checks in the device if it supports various actions that require different permission levels

• Perform authorization checks in the Field Gateway if it supports various actions that require different permission levels

The principle means giving a user account only those privileges which are essential to that users work. For example, a backup user does not need to install software: hence, the backup user has rights only to run backup and backup-related applications. Any other privileges, such as installing new software, are blocked. The principle applies also to a personal computer user who usually does work in a normal user account, and opens a privileged, password protected account (that is, a superuser) only when the situation absolutely demands it.

This principle can also be applied to your web-applications. Instead of solely depending on role-based authentication methods using sessions, we rather want to assign privileges to users by means of a Database-Based Authentication system. We still use sessions in order to identify if the user was logged in correctly, only now instead of assigning that user with a specific role we assign him with privileges to verify which actions he is privileged to perform on the system. Also a big pro of this method is, whenever a user has to be assigned fewer privileges your changes will be applied on the fly since the assigning does not depend on the session which otherwise had to expire first.

Sensitive static and configuration files should not be kept in the web-root. For content not required to be public, either proper access controls should be applied or removal of the content itself.

Also, forceful browsing is usually combined with Brute Force techniques to gather information by attempting to access as many URLs as possible to enumerate directories and files on a server. Attackers may check for all variations of commonly existing files. For example, a password file search would encompass files including psswd.txt, password.htm, password.dat, and other variations.

To mitigate this, capabilities for detection of brute force attempts should be included.

Row-Level Security enables customers to control access to rows in a database table based on the characteristics of the user executing a query (e.g., group membership or execution context).

Row-Level Security (RLS) simplifies the design and coding of security in your application. RLS enables you to implement restrictions on data row access. For example ensuring that workers can access only those data rows that are pertinent to their department, or restricting a customer's data access to only the data relevant to their company.

The access restriction logic is located in the database tier rather than away from the data in another application tier. The database system applies the access restrictions every time that data access is attempted from any tier. This makes the security system more reliable and robust by reducing the surface area of the security system.

Azure Service Fabric supports two different access control types for clients that are connected to a Service Fabric cluster: administrator and user. Access control allows the cluster administrator to limit access to certain cluster operations for different groups of users, making the cluster more secure.

Administrators have full access to management capabilities (including read/write capabilities). Users, by default, have only read access to management capabilities (for example, query capabilities), and the ability to resolve applications and services.

You specify the two client roles (administrator and client) at the time of cluster creation by providing separate certificates for each.

When you create a new storage account, you select a deployment model of Classic or Azure Resource Manager. The Classic model of creating resources in Azure only allows all-or-nothing access to the subscription, and in turn, the storage account.

With the Azure Resource Manager model, you put the storage account in a resource group and control access to the management plane of that specific storage account using Microsoft Entra ID. For example, you can give specific users the ability to access the storage account keys, while other users can view information about the storage account, but cannot access the storage account keys.

Application should safeguard its own configuration and user data in case if phone is rooted or jail broken. Rooting/jail breaking implies unauthorized access, which normal users won't do on their own phones. Therefore application should have implicit detection logic on application startup, to detect if the phone has been rooted.

The detection logic can be simply accessing files which normally only root user can access, for example:

• /system/app/Superuser.apk
• /sbin/su
• /system/bin/su
• /system/xbin/su
• /data/local/xbin/su
• /data/local/bin/su
• /system/sd/xbin/su
• /system/bin/failsafe/su
• /data/local/su

If the application can access any of these files, it denotes that the application is running as root user.

The system uses a weak class reference, which might allow an attacker to execute unauthorized code. The program references a user-defined class that is not uniquely identified. When .NET loads this weakly identified class, the CLR type loader searches for the class in the following locations in the specified order:

1. If the assembly of the type is known, the loader searches the configuration file's redirect locations, GAC, the current assembly using configuration information, and the application base directory
2. If the assembly is unknown, the loader searches the current assembly, mscorlib, and the location returned by the TypeResolve event handler
3. This CLR search order can be modified with hooks such as the Type Forwarding mechanism and the AppDomain.TypeResolve event

If an attacker exploits the CLR search order by creating an alternative class with the same name and placing it in an alternative location that the CLR will load first, the CLR will unintentionally execute the attacker-supplied code

This service does not use an authorization control. When a client calls a particular WCF service, WCF provides various authorization schemes that verify that the caller has permission to execute the service method on the server. If authorization controls are not enabled for WCF services, an authenticated user can achieve privilege escalation.

Role information for the application users can be derived from Microsoft Entra ID or ADFS claims if the application relies on them as Identity provider or the application itself might provided it. In any of these cases, the custom authorization implementation should validate the user role information.

Role information for the application users can be derived from Microsoft Entra ID or ADFS claims if the application relies on them as Identity provider or the application itself might provided it. In any of these cases, the custom authorization implementation should validate the user role information.

The Device should authorize the caller to check if the caller has the required permissions to perform the action requested. For e.g. Lets say the device is a Smart Door Lock that can be monitored from the cloud, plus it provides functionalities like Remotely locking the door.

The Smart Door Lock provides unlocking functionality only when someone physically comes near the door with a Card. In this case, the implementation of the remote command and control should be done in such a way that it does not provide any functionality to unlock the door as the cloud gateway is not authorized to send a command to unlock the door.