All security measures and recommendations are based on the BSI IT-Grundschutz Compendium.
The following tables refer to the OWASP Top 10 Security Measures 2017 and explain the security measurements and relevant settings to avoid security flaws within the Simplifier platform.
A1: Injection |
Simplifier Prevention |
| User-supplied data is not validated, filtered or sanitized by the application. | Double validation against data type definition (client and backend validation). |
| Hostile data is used directly with dynamic queries or non-parameterized calls for the interpreter without context-aware escaping. | All connector calls are parameterized, including SQL queries. |
| Hostile data is directly used or concatenated so that the SQL or command contains both structure and hostile data in dynamic queries, commands, or in stored procedures. | All connector calls are parameterized, including SQL queries. |
A2: Broken Authentication |
Simplifier Prevention |
| You may have authentication weakness if your application… | Simplifier is using token authentication. This token expires after x seconds (depends on the server security settings). |
| Permits credential stuffing, where the attacker has a list of valid usernames and passwords. | The permission object view owns user details prevents the application to access all user data. |
| Permits brute force or other automated attacks. | We secure the authentication by deactivating the account after x times of failed logins.
 |
| Permits default, weak or well-known passwords. | The admin can secure the password by setting password rules in the password settings.
 |
| Uses weak or ineffectual credential recovery and forgot password processes, such as “knowledge-based answers”, which cannot be made safe. | Actual we provide a one-time link to reset the password via email, but no other security questions. |
| Using plain text, encrypted, or weakly hashed passwords permit the rapid recovery of passwords using GPU crackers or brute force tools. | Our password does not exist in the database. We are using encrypted hashes via bcrypt algorithm. |
| Has missing or ineffective multi-factor authentication. | We provide multi-factor authentication through OAuth 2.0 authentication method. |
A3: Sensitive Data Exposure |
Simplifier Prevention |
| Data of a site is transmitted in clear text, internally or externally. | Simplifier runs behind a web proxy and all data is encrypted via HTTPS based on TLS 1.2 |
| Sensitive data is stored in clear text, including backups. | Simplifier doesn’t save personal data or sensitive data on its own database – we are using existing backend systems for that. |
| Old or weak cryptographic algorithms are used either by default or in older code. | We rely on bcrypt. |
| Default crypto keys are in use, weak crypto keys are generated or re-used, or proper key management or rotation is missing. | We rely on bcrypt. |
| Encryption is not enforced, e.g. security policies or headers are missing. | If you use our provided reverse proxy template, this can not happen. |
A4: XML External Entities (XXE) |
Simplifier Prevention |
| Your application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor. | We only support XML formats with REST and SOAP connectors from trusted backend sources and no direct upload or data processing within an application. |
| Any of the XML processors in the application or SOAP-based web services has document type definitions (DTDs) enabled. | Yes, we parse WSDL and consider DTD if available and generate corresponding data type definitions within Simplifier itself. |
| If your application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework. | We support SOAP version 1.2 |
| SAST tools can help detect XXE in source code, although manual code review is the best alternative in large, complex apps with many integrations. | We only support XML formats with REST and SOAP connector from trusted backend sources and no direct upload or data processing within an application. |
| Being vulnerable to XXE attacks likely means that you are vulnerable to other billion laughs denial-of-service attacks. | We only support XML formats with REST and SOAP connectors from trusted backend sources and no direct upload or data processing within an application. |
A5: Broken Access Control |
Simplifier Prevention |
| Bypassing access control checks by modifying the URL, internal app state, or the HTML page, or simply using a custom API attack tool. | This can not happen because every API is secured by permission objects independent from the user interface itself. |
| Allowing the primary key to be changed to another’s users record, such as viewing or editing someone else’s account. | This can not happen because every API is secured by permission objects independent from the user interface itself. |
| Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user. | The Simplifier authentication token is assigned to the client fingerprint that contains a lot of unique attributes like system configuration, browser version, screen resolution, browser plugins, etc. If you use a foreign authentification token to gain privileges, you have to be on the same client system and using the same browser and user credentials – so it is very unlikely to misuse a foreign token. |
| Metadata manipulation, such as replaying or tampering with a JWT access control token or a cookie or hidden field manipulated to elevate privileges. | The Simplifier authentication token is not stored in a cookie and is encrypted on the client with the client fingerprint. |
| CORS misconfiguration allows unauthorized API access. | If you use our recommend reverse proxy example you will be safe in terms of CORS misconfiguration. |
| Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user or API not enforcing access controls for POST, PUT and DELETE. | All APIs are secured by permission objects. |
A6: Security Misconfiguration |
Simplifier Prevention |
| Unnecessary features are enabled or installed. | Features are enabled via permission objects. |
| Default accounts and their passwords are still enabled and unchanged. | Every single installation will get an automatically generated complex administrator password. We are not using default passwords. |
| Does your error handling reveal stack traces or other overly informative error messages to users? | The logging and monitoring feature clears backend passwords out of the logs, so we will not include security-related information within the logs. |
| Old configurations are used with updated software which may not be backward compatible. | All configuration objects are automatically migrated to the newest release versions. |
| Security settings in application servers, application frameworks, libraries, databases, etc. are not set to secure values. | In our cloud environment, we are using very strong passwords. |
| The server doesn’t send security directives to client agents or they are not set to secure values for web applications. | HSTS headers are set in the web reverse proxy. |
| Any of your software is out of date. | Every customer is forced to upgrade once a year – older versions are supported via long term support that includes also security patches. |
A7: Cross-Site Scripting (XSS) |
Simplifier Prevention |
| Reflected XSS: Your app or API includes unvalidated and unescaped user input as part of HTML output or there is no content security policy header. | We use the content security header. |
| Stored XSS: Your app or API stores unsanitized user input that is viewed at a later time by another user or an administrator. | All API fields are validated against data type definitions to prevent unsanitized data. |
| DOM XSS: JavaScript frameworks, single page apps, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. | We provide encoding function also for JavaScript for HTML, URL, CSS and JavaScript. |
A8: Insecure Deserialization |
Simplifier Prevention |
| The serialization mechanism allows for the creation of arbitrary data types, AND | We transform every data to JSON format with sanitize options. |
| There are classes available to the application that can be chained together to change application behavior during or after deserialization, or unintended content can be used to influence application behavior, AND | We only accept valid JSON data. Each data object will be checked against the API data definition by default. |
| The application or API accepts and deserializes hostile objects supplied by an attacker, or an application uses serialized opaque client-side state without appropriate tamper-resistant controls. OR | We only accept valid JSON data. Each data object will be checked against the API data definition by default. |
| Security state sent to an untrusted client without some form of integrity control is likely vulnerable to deserialization. | Every client has to be authenticated to check if the client is trusted. |
A9: Using Components with Known Vulnerabilities |
Simplifier Prevention |
| You don’t know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies. | All depending libraries are checked against security exploits with VersionEye Service. |
| Your software is out of date. This includes the OS, Web/App Server, DBMS, applications, APIs and all components, runtime environments, and libraries. | All components are checked against update with VersionEye. |
| You don’t know if they are vulnerable. Either if you don’t research for this information or if you don’t scan them for vulnerabilities on a regular base. | All components are checked against update with VersionEye. |
| You don’t fix nor upgrade the underlying platform, frameworks, and dependencies in a timely fashion. | We provide security hotfixes for the last 2 major releases (1 year). |
| You don’t secure the components’ configurations. | We secured the complete configuration. |
A10: Insufficient Logging & Monitoring |
Simplifier Prevention |
| Auditable events, such as logins, failed logins, and high-value transactions are not logged. | Failed login attempts and valid logins are logged as such as every business object or connector call. No matter what kind of value this transaction is. |
| Logs of applications and APIs are not monitored for suspicious activity. | All applications are monitored. |
| Alerting thresholds and response escalation according to the risk of the data held by the application is not in place or effective. | Actual it is not possible to alert security response teams or administrator via email after certain security events – this will be available in further releases. |
