Backend Specifics

On the backend, the APS controller interacts with APS application instances activated inside APS application connectors. APS connectors are usually deployed on the APS PHP runtime although other frameworks are also possible.

APS Application Instances

When the APS controller requests an APS connector to create an APS application instance, it initiates one of authentication protocols as mentioned in the Authentication section.

SSL Authentication

The default authentication of an APS application instance is ensured by two X509 SSL certificates:

• The APS controller certificate, for example, APSC.crt, is used by the application to validate incoming connections from the APS controller.

• The APS application instance certificate, for example, App.crt, is used by the application to identify itself when connecting to the APS controller.

An APS application connector integrates an original application with the platform usually through a single APS application instance. In rare cases, an APS application connector has more than one APS application instance. In this case, each instance has its own configuration including its own application certificate and private key.

As explained in the SSL Authentication of Application Instances section, when installing an APS application instance on an APS application connector, the APS controller generates the SSL certificate and the private key for that instance and then sends the following to the APS application connector:

• The APS controller SSL certificate

• The APS application instance SSL certificate

• The APS application instance private key

OAuth Authentication

Firstly, an administrator must have a unique OAuth-1.0a key and secret pair that both the APS controller and an APS connector will share for authentication. The APS connector must be able to use the OAuth-1.0 protocol.

When initiating the APS controller to create an APS application instance on an APS connector, the respective REST request must specify the aps.auth section with the shared pair of OAuth parameters, as in the following example:

POST /aps/2/applications/

{
   "aps": {
      "package": {
         "type": "http://event-mgmt.demo.apsdemo.org/vpscloud"
      },
      "endpoint": "https://endpoint.isv1.example.com:443/vpsclouds",
      "auth": {
         "oauth": {
            "key": "c4b3510e-a432-4e2c-940c-d151e05b68fg",
            "secret": "b57247b4-8174-420c-aa0f-1f7f863bb616"
         }
      }
   },
   ...
}

APS PHP Framework (Runtime) Implementation

PHP Framework provides an authentication method based on SSL for APS connectors.

If an APS connector is deployed over the APS PHP framework, all its APS application instances are physically presented by the config/ folder inside the folder where the APS application connector is deployed. For example, if an APS application connector is deployed in the /var/www/html/basic/ folder, an APS application instance is presented in the /var/www/html/basic/config/ folder with security files similar to the following:

#  ls -l /var/www/html/basic/config/
total 16
-rw------- 1 apache apache 4227 Jun  7 09:46 a5b521c7-144d-47b6-b3c7-086e4dc30790
-rw------- 1 apache apache 1196 Jun  7 09:46 a5b521c7-144d-47b6-b3c7-086e4dc30790.apsc.pem
-rw------- 1 apache apache 2822 Jun  7 09:46 a5b521c7-144d-47b6-b3c7-086e4dc30790.pem

In the above list:

• The first file contains both SSL certificates and the application private key.

• The second file contains the APS controller certificate.

• The third file contains the application certificate and its private key.

The file names are based on the UUID assigned to the APS application instance. If the provider installs one more instance on the same APS application connector, the three new files based on the new UUID and containing newly generated private key and certificate will appear in the same folder.

Custom Backend Framework

If you are using your own backend framework based on Java, Python, Node.js, or another programming language, pay attention to the authentication procedures and recommendations provided in the SSL Authentication of Application Instances section. Based on a custom framework, an APS application instance must meet at least the following authentication requirements:

• The instance must authenticate the SSL client certificate of the APS controller for each request coming from the APS controller.

• The instance must authenticate the SSL server certificate of the APS controller for each request going to the APS controller.

For both these cases, the APS controller sends the same SSL certificate that the application instance received during its installation.

Server-Side Application Security

When developing an APS application connector, pay attention to the following security measures on the server side:

• Properly protect the application private key.

• Since custom methods are assigned the application privileges (full access to all application resources), carefully design the access to every custom method and restrict the scope of resources managed by the method inside the code of that method.

• Implement authentication and authorization for the application’s internal auxiliary resources, such as the database, cache, and other.

• Use the encrypted attribute to protect sensitive properties from public eyes.

• Avoid logging sensitive data, such as authentication tokens and passwords.

Impersonation

When an application method requests a list of resources, it can get all resources in all subscriptions, although the method typically needs the resources of a specific subscription only. To restrict the application access only to the resources of a specific account, the recommended way for an application to do this is to impersonate that account as explained in Security Context.

The impersonation model requires an application to specify the required level of impersonation through the security.json file:

• The provider level means unlimited impersonation and it is the default for those applications that are not aware of this mechanism and therefore do not contain the security.json file in the APS package. This level allows the application to impersonate any account.

• The reseller level allows the application to impersonate any reseller and any customer.

• The customer level allows the application to impersonate any customer.

When installing an APS application instance, the provider will see the required impersonation level and must accept it or reject the installation. After deployment, the platform will allow the application to impersonate accounts in accordance with the accepted request.

If none of the above levels are required, the platform will not allow the application to impersonate any account. That means the none impersonation level.

Application Threats

Typically, an APS connector has the following sensitive assets:

• Credentials for the respective original application, for example, login and password or a private key.

• Credentials for the APS controller (APSC) services, which are the APS controller certificate, the APS application instance certificate, and the private key.

• Optionally, a local storage containing users’ PII.

Accordingly, probable threats are spotted on the following diagram and the table.

Location on the diagram	Threat	Impact
T1	Leaking application credentials	A malicious actor may access the original cloud application on behalf of the provider.
T2	Leaking platform credentials	An adversary may access the platform on behalf of the application.
T3	APS controller credential spoofing	An adversary may access the original service API on behalf of the platform.
T4	Application API spoofing	An adversary may mount a MITM (man in the middle) attack against the APS connector causing information disclosure and tampering over the communication channel between the APS connector and the original API.
T5	Leaking of sensitive data from the APS connector storage	An adversary gets access to PII or other sensitive data and may blackmail the provider or use this data in other malicious ways.
T6	Insufficient authorization in APS connector API	An adversary may access APS connector resources without proper authorization.
T7	Other common threats for the web-application backend	Depends on the threat.

T1. Leaking Application Credentials

Impact:

An adversary may access the original cloud application on behalf of the provider.

Mitigations:

• Protect the application credentials using the file permissions or the encrypted attribute.

• Make sure the credentials cannot be retrieved from the APS connector over HTTP or API call.

• Never allow the leak of credentials into logs.

• Authenticate the SSL server certificate of the original application, so credentials would not be leaked over MITM attacks.

T2. Leaking Platform Credentials

Impact:

An adversary may access the platform on behalf of the application.

Mitigations:

• Protect the application certificate by assigning the proper file permissions.

• Make sure the credentials cannot be retrieved from the endpoint node over HTTP.

• Never leak credentials into logs.

• Authenticate the SSL server certificate of the APS controller.

T3. APSC Credentials Spoofing

Impact:

An adversary may access the application API on behalf of the platform.

Mitigations:

• Authenticate the APS controller SSL client certificate for every incoming API request.

• Take care when implementing an APS connector deployment scenario - allow an unauthenticated call only when no APS controller certificate is configured yet.

T4. Application API Spoofing

Impact:

An adversary may mount an MITM attack against the APS connector causing information disclosure and tampering over a communication channel between APS connector and the original service API.

Mitigations:

• Authenticate the original service API certificate, so credentials cannot be leaked over MITM attacks.

T5. Leaking of Sensitive Data from APS Connector Storage

Impact:

An adversary gets access to PII or other sensitive data and may blackmail the provider or use this data in other malicious ways.

Mitigations:

• Use encrypted attributes when storing secret data in the APS controller database.

• Avoid recording of sensitive and PII data in logs.

• Properly configure access to the internal application database.

• Prevent SQL injection and similar attacks.

• Do not expose the internal database in the network.

T6. Insufficient Authorization in APS Connector API

Impact:

An adversary may access the APS connector resources without proper authorization.

Mitigations:

• Carefully map the original API security model to the APS roles model.

• Ensure that the current actor is authorized to access resources when those resources are accessed through a custom operation.

• Avoid creating Security Roles resources.

T7. Other Common Threats for Web-Application Backend

In addition to the above APS specific threats, you should consider common Web application and REST backend security threats when developing APS connectors.

The set of probable threats includes but is not limited to:

• Programming language and development framework specific threats.

• SQL / NoSQL injections.

• Remote code execution threats.

• Path traversal, file inclusions, and other filesystem-related threats.

• Parsing errors, XML vulnerabilities, and XXE.

• Server-Side Request Forgery.

Mitigations:

• Make sure the APS connector only exposes the API of its services in the network.

• Know your programming language and framework security properties and configurations.

• Make sure you properly apply the security mitigation plan to all technologies you use in development (XML, databases/SQL/NoSQL, messaging and communication libraries and frameworks, and so on).

• Apply the Least Privilege and Defense in Depth principles.

← Security Model

Frontend Specifics →