Add authentication/authorization related PoCs

[jeongsoolee09]

What this PR contributes

This PR adds several PoCs pertaining to authentication or authorization issues, as well as model tests to make sure that the model classes correctly capture the relevant portions of code.

nonprod-authn-strategy

Level: Error, Precision: High.

This category is about mistakes due to using development-only authentication strategies, assuming code-scanning is called before the application goes into production.

basic/mocked/dummy-authentication

Level: Error, Precision: High.

• Basic authentication is used in a production environment, with hardcoded username and password entries of mocked users in the application's package.json.
• Mocked / Dummy authentication is used in a production environment without hardcoded username and password entries.

misused-privileged-user

This category pertains to the mistakes caused by misusing the cds.User.Privileged class in a couple of ways. Since this class bypasses all means of authorization, developers should be prudent in ways it is used.

default-is-privileged

Level: Error, Precision: High.

The cds.User.default property, initially cds.User.Anonymous, is overwritten to cds.User.Privileged at some execution point of the application. This models the scenario where the developer overwrote the property for convenience during development but forgot to put it back to the default class.

dynamically-generated-privileged

Level: Error, Precision: Low.

A user of cds.User.Privileged is created and used somewhere in the application in an inappropriate manner. Particularly, its misuse allows for elevated access rights of a user to its maximum.

• privileged-user.js contains a custom authentication strategy that creates a privileged user on login.
• service1.js contains five transactions that reads from various entities with a privileged user:
  • this.on("send1", ...): Not an error. It SELECTs from its own entity that does not require authorization.
  • this.on("send2", ...): Is an error. It SELECTs from its own entity that requires authorization.
  • this.on("send3", ...): Not an error. It SELECTs from a locally available entity that does not require authorization.
  • this.on("send4", ...): Is an error. It SELECTs from a locally available entity that requires authorization.
  • this.on("send5", ...): Is eligible for a warning. It SELECTs from a remote entity of which authorization strategy is unknown. Treating this as an error may result in many false positives, so we overapproximate that the remote entity does restrict access rights in some way and issue a warning instead.

entities-with-no-authn

Level: Warning, Precision: High.

When a CAP application chooses to use a production-level authentication strategy, all of its entities, services, actions, and functions are "locked down" to require 'authenticated-user' as its access control. Therefore, a warning should be issued whenever a CAP declaration without an access control is encountered.

Alternatively, if the aformentioned issue is present but cds.env.requires.auth.restrict_all_services is set to false in the application's package.json, then an error should be raised.

entities-exposed-with-no-authz

All entities, services, actions, and functions are not secured. Every occurrences of such should raise an alarm.

entities-exposed-with-cds-authz

All entities, services, actions, and functions require authentication via @restrict or @requires annotations on the CDS file that declares them (Note that event declarations cannot be qualified with neither of both). As a result, no alerts should be produced on this application.

entities-exposed-with-js-authz

All entities, services, actions, and functions require authentication either via:

• Service.before handler registration that checks access rights and rejects the request, or
• Service.on handler registration that checks access rights and executes business logic or rejects the request on the result of the authorization.

Hence, for similar reasons for entities-exposed-with-cds-authz, no alerts should be produced on this application.

Model tests

privilegeduser

privilegeduser.js contains true-positive cases where a privileged user is created to access an entity, with three variations in how it is configured:

1. A user is created using directly using a custom middleware that configures a req.user as a privileged user. The user is initialized by a constructor call to CustomPrivilegedUser1, which is equivalent to cds.User.Privileged since it has a constant true function as its is instance method used for authorization.
2. A user is created by a direct constructor call to cds.User.Privileged.
3. A user is created by a direct constructor call to the above CustomPrivilegedUser1.

req-user-authz

Extensive collection of all combinations involving this.before and this.on handler registrations written for authentization and authorization, which is similar to those appearing in the example dynamically-generated-privileged said above.

Future work

Implement queries that correctly finds all true positive cases but avoids all false positive ones.

[mbaluda]

It's a good set of tests!