Security Guidelines

Our customers rely on us to keep their data safe. That's why we attach great importance that the Apps offered on the d.velop cloud platform meet the corresponding security standards to protect against unauthorized access and data loss.

Because you as an App Builder, are the only person who knows the logic and source code of your App, only you can ensure that your App is secure. But we support you in this task by defining security standards and check them with you. For this check we commission an external company, which performs the penetration test of your app in the d.velop cloud.

Security standards

Below is a brief list of the information security requirements your organization and app must meet.
Please follow the corresponding link to get more detailed information for the requirement.

Organizational

1. Data protection officer
   A company data protection officer has been appointed in accordance with Art. 37 GDPR.
2. Obligation to maintain data secrecy
   All persons involved are bound by data secrecy (Art. 32 Para. 1 b) GDPR).
3. Communication of security incidents
   Security relevant events, which can have negative consequences for d.velop and its customers (e.g. suspicion of malware or information theft), are logged and immediately reported to d.velop.
4. Retirement of employees
   If employees leave the company, all accounts must be withdrawn immediately. All passwords of which the employee was aware must be changed immediately. All data and devices made available to the employee must be collected. This is documented in a security policy.
5. Access control
   It is ensured that only authorized persons have access to relevant workstations. Access is logged.
6. Password protection
   There is a corresponding password policy (e.g. with a maximum number of login errors and a defined complexity) and passwords are only stored securely. This is documented in a security policy.
7. Device security
   All devices regularly receive security patches and have always up-to-date virus protection, an activated operating system firewall, activated drive encryption and a screen saver policy with password protection. This is documented in a security policy.
8. Spam filter
   To protect against malware, a company-wide protection solution has been installed that automatically checks and, if necessary, blocks all incoming e-mails.
9. Separation of development and production environments
   Software development and testing takes place on separate non-productive environments with separate data sets.

Application security

1. Restrict Redirection
   Redirections that are externally controllable must be restricted to the Origin (scheme, domain and port) originally requested. If this is not feasible for your particular business case your App must provide the means to define a whitelist.
   If you don't restrict redirections it would be possible for an attacker to lure the user to an evil site e.g. by using a special crafted URL.
2. Respect semantics of HTTP methods
   HTTP Methoden must be used according to their specified semantics. In particular the server-side state must not be changed if Safe Methods like GET are used.
   Otherwise certain security measures that we have implemented in the d.velop cloud would probably not work.
3. Secure transport encryption
   The multitenant capable HTTPS endpoint must support TLS version 1.2 as the minimum TLS version.
4. Masking user input and values from other sources before display
   When user input or values from other sources are displayed in the browser, without these values having previously been formatted for display in a browser, it is possible to execute any JavaScript code in the browser.
5. Data minimization and storage limitation
   Only data that is absolutely necessary for the function of the app may be processed and stored. After processing, data that is no longer required (e.g. personal data) must be deleted immediately.
6. Signature of client header values
   Before a request can be processed by an app, the signature must be verified (HTTP header "x-dv-sig-1"). Requests with invalid or missing signatures must not be processed, as it cannot be ensured that these requests originate from the Approuter.

Data security and operation

1. Data center
   The data center in which the app is operated is ISO/IEC 27001 or equivalent certified.
2. Encryption
   All persistent data is stored encrypted (at file level) or stored on encrypted storage media (e.g. drive encryption).
3. Firewall
   Only the necessary ports (e.g. HTTPS) of the app are accessible directly from the Internet. Access to other ports (e.g. SSH for administration) is restricted to IP addresses or only accessible via VPN.
4. Authorization assignment
   The assignment of authorizations for access to app-relevant IT systems is restrictive, person-related and documented. Users only receive the rights required for their activities.
5. Patch management
   All app-relevant IT systems and software components used receive regular security updates.
6. Monitoring
   The accessibility and functionality of the app is continuously monitored. Relevant events trigger alarms (e.g. in the form of e-mail notifications).
7. Deletion concept
   In case of termination of the App by the customer, the App must respond to appropriate notifications in order to delete all stored data of the customer.
8. Data protection concept Backups are created at least once a day (RPO: 24 hours). Even if the customer cancels the app, the backups are kept for 30 days. The recovery process is documented and is tested and protocoled every six months. The protocol also includes measures derived from the results. Technical measures are in place to protect backups from accidental or deliberate deletion.
9. Disaster recovery plan
   A disaster recovery plan describes the recovery of the app if essential components fail. The deployment of the app should therefore be fully automated and/or the individual steps documented to minimize the time to recovery (RTO).

Detailed information about the corresponding requirement

Restrict redirection

Attack scenario: Unsafe redirect

In this scenario the user is redirected unnoticed (e.g. via a special crafted URL) to the attacker's site. The user is then prompted to enter confidential information such as user name and password. Since the redirect originates from a d.velop cloud App, i.e. the clicked or entered URL which belongs to a trustworthy origin and the browser automatically follows the redirect, it looks to the user like the prompt comes from a trusted App. After all most users don't check if the URL in the browser changes and if they are on a completely different origin when entering confidential data. For this attack it is necessary that the attacker can directly or indirectly manipulate the target of a redirect.

Countermeasures

Redirections that are externally controllable must be restricted to the Origin (scheme, domain and port) originally requested. If this is not feasible for your particular business case your App must provide the means to define a whitelist.

Technical implementation

If your business case must support redirects to abolute URLs you must provide the means to define a whitelist and you have to check the requests against this list.

It's sufficient to check the structure of the redirection URL if you only support relative URLs. Relative URLs always start with a forward slash / 0x2F. However the HTTP spec defines that an URL beginning with 2 forward slashes followed by http(s):// is also a valid notation for an absolute URL. Therefore it's not enough to check if the URL string starts with a forward slash. Furthermore forward slashes might be URL-hex-encoded (%2F) so it isn't sufficient to check is the URL string starts with two forward slashes either.

The following absolute URLs might be characterized as relative URLs if the check is not implemented correctly:

• //https://evil.com
• /%2Fhttps://evil.com
• %2F/https://evil.com
• %2F%2Fhttps://evil.com

Respect semantics of HTTP methods

If the HTTP methods are used incorrectly, this will result in a variety of potential problems. For example HTTP proxies cache the responses to GET requests under certain circumstances so that subsequent GET requests to the same resource may no longer reach the original App. It is obvious that this is problematic if you use GET incorrectly, to change server-side state and subsequent requests don't reach the server due to the cache. As an App Builder, you cannot know which intermediate proxies an HTTP request passes through before it reaches your App. For example, the above proxy could be part of the customer's infrastructure. For this reason it is important to adhere to the HTTP specification.

In addition, we have implemented some basic security measures that serve as a 1st line of defense and are based on the HTTP methods being used correctly.

Basic countermeasure against CSRF

One of these security measures tackles Cross-Site Request Forgery (CSRF) attacks and is centrally implemented by the HttpGateway App.

For HTTP methods which change the server side state (POST, PUT, PATCH und DELETE) the HttpGateway App checks if the Origin Header of the request matches the invoked target origin and blocks the request with 403 Forbidden if this is not the case (cf. OWASP Cheat Sheet)

Masking user input and values from other sources before display in the browser

Countermeasures

All values displayed in the browser must be masked, regardless of the source from which they originate.

The following list shows many, but not necessarily all, sources for values that must be masked:

• Configurations
• Databases
• User input
• URL parameters
• Document contents
• API interfaces
• Web Storage

Further information can be found on the page Cross-site Scripting (XSS).

Technical implementation

Apps that render their web pages in the backend have to insert already masked values when rendering. All common programming languages offer masking functions.

Modern frontend JavaScript frameworks usually do this automatically. However, it must be ensured, that only the functions of the frameworks intended for this purpose are used and that no content is inserted otherwise.

Signature of client header values

Before a request can be processed by an app, the signature must be verified (HTTP header "x-dv-sig-1"). Requests with invalid or missing signatures must not be processed, as it cannot be ensured that these requests originate from the Approuter.

Technical implementation

Under the Basics for d.velop cloud apps you can find all information how to implement the signature verification.