This article is aimed at ensuring that the process of setting up security testing is seamless and easily accommodated in the development and testing cycles. For more information on security design, see the documentation on Object Security.
After reading this article one should be able to :
There are two main types of application security: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).
Role-based access control (RBAC), also known as role-based security, involves setting permissions based on authorized user groups. Most large organizations use role-based access control because it ensures employees can only access information and actions that should be visible for their role.
ABAC evaluates a set of rules and policies to manage access rights according to specific attributes, such as environmental, system, object, or user information. It applies boolean logic to grant or deny access to users based on a complex evaluation of atomic or set-valued attributes and the relationship between them.
This article however focuses on the role based access control and how this role based security testing should be performed.
We will use the example HR Recruitment application below on to explain security concepts. First, we will introduce the actors in the application. Then, we will explore the common security pitfalls and vulnerabilities which may arise.
As an example use case, you may have an HR recruiting application with the following user roles:
This example is using role-based access control, so each of these roles will need varying levels of access to different functionality, depending on their role. For example, an HR Director will likely have the broadest range of access, whereas the candidate themselves would have the most restricted access.
The next section will explore some common security issues which we need to address in this example.
When performing security role testing, it is important to test not only that the right objects and components are accessible to the right user groups from the front end, but also to make sure that there are no object security gaps. Avoid relying on security by obscurity, the assumption that if users cannot access pages from the front end, the application is secure. Security role testing ensures that users and groups are properly authorized to access all objects in an application by ensuring that there is no unrestricted object access.
Horizontal privilege escalation arises when a user is able to gain access to resources available to another user role at their same level, instead of their own resources of that type. For example, if an user from the interviewer group should only be able to access their own candidate records, but can in fact also access the records of other candidates belonging to the recruiter group by going directly to a specific record URL, then this is horizontal privilege escalation. The application should be able to detect whether the user who is trying to access the resource is allowed to access or not. This is a very basic role based security vulnerability which should be a part of the security testing.
There are more details around this type of security in this record level security guide.
Vertical privilege escalation arises when users are able to access actions and information which should only be available to user roles with more system access. For example in a site there could be links/ functions which are accessible only to business administrators, but any other user might be able to access the object through the front end or by copy-pasting the url in a browser. This should be disallowed and be a part of the security role testing. This can also happen when a user tries to access document links and safe urls which are not supposed to be accessible to them. In these scenarios, object level security and UI level security must be applied.
In a multi step process, there are often multiple parties who are involved in the tasks / work. In a record-centric process, vulnerabilities like unauthorized URL access and unprotected functionality can arise and need to be tested.
For example, in the example application above a process could involve:
Here, if a developer implements rigorous access controls on steps 1 and 2 but forgets to add security on step 3 assuming that only authorized users would come to step 3, they would create a loophole whereby an unauthorized user could directly try to access the 3rd step through, for example, a record action from the candidate profile.
Testing in the context of real user roles involves first identifying all of the distinct user roles within the built application. This process should be performed throughout development so that the relevant roles can be translated into test user personas, and discrete logins and Appian accounts can be made for these users. This process is iterative, and it is highly likely that additional test user roles will be added throughout the life cycle of the project.
If we take the example of the HR recruiting application, a simple snippet of the security matrix may look as follows, where the blue check marks indicate that the user has access to view/edit that particular function, whereas the red crosses indicate that the user is restricted from viewing that data/page or performing the specified action.
The steps to initiate role based testing is to create multiple test users with different profiles.
We will make use of the Google Chrome Profiles feature to create distinct profiles in Chrome for each test user. Each profile will store the user’s username and password for each Appian environment they are a member of. This section assumes that Test User accounts have already been identified/created within the environments for which Test Profiles are desired to be staged.
Note: Chrome version 89.0.4389.128 has been used for this purpose.
Navigate to the top right corner of the chrome window and click on the profile icon. Click on the settings wheel as shown
To create a new Chrome profile, click on "Add", then select “Continue Without an Account.” Enter a Name (typically the first and last name of the Test User as they appear in Appian) and click “Done” (see images below).
Navigate to the top right of the Chrome Browser and select the current profile (identified by the profile's name - see figure below). You’ll notice that upon clicking, all of the Chrome Profiles appear. Select the recently added profile.
Navigate to Chrome Settings. Scroll down to the “On Startup” section. Select the radio button for “Open a specific page or set of pages”. Here, we will want to set pages for the environments we normally log into such that when we open the window for the test user, everything is set and ready to go.
Typically, we will set up the Appian Development and Appian Test environment as start pages, in addition to the test user's email account . Close out of this Chrome browser window to prepare for the next step.
The selected profile will open in a new Chrome browser window and default to the tabs that were set for startup.
To sign in for the first time, enter the test user’s username and password for each environment, as well as the username and password for any associated test email accounts, and be sure to save the passwords by clicking the “Save” button when Chrome asks if you would like to remember your password. This will ensure that each time you log in as this test user, you are not scrambling to find the password. It will ultimately save much time during testing/demoing moving forward.
Repeat Steps 1-3 to create a new Chrome Profile for each of the test users you will be testing/demoing with. Usually, you will want at least one test user profile set up for each functional role within your application.