Design and threat modelling Solution S1.

• V1.1: Verify that all application components are identified and are known to be needed. (→ S1-1)

See Solution S2.

• V2.1: Verify all pages and resources require authentication except those specifically intended to be public (Principle of complete mediation). (→ S2-1)

• V2.2: Verify that forms containing credentials are not filled in by the application. Pre-filling by the application implies that credentials are stored in plaintext or a reversible format, which is explicitly prohibited. (→ S2-2)

• V2.4: Verify all authentication controls are enforced on the server side. (→ S2-3)

• V2.6: Verify all authentication controls fail securely to ensure attackers cannot log in. (→ S2-4)

• V2.7: Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent password managers, long passphrases or highly complex passwords being entered. (→ S2-9)

• V2.8: Verify all account identity authentication functions (such as update profile, forgot password, disabled / lost token, help desk or IVR) that might regain access to the account are at least as resistant to attack as the primary authentication mechanism. (→ S2-10)

• V2.9: Verify that the changing password functionality includes the old password, the new password, and a password confirmation. (→ S2-11)

• V2.16: Verify that credentials are transported using a suitable encrypted link and that all pages/functions that require a user to enter credentials are done so using an encrypted link. (→ S2-5)

• V2.17: Verify that the forgotten password function and other recovery paths do not reveal the current password and that the new password is not sent in clear text to the user. (→ S2-6)

• V2.18: Verify that information enumeration is not possible via login, password reset, or forgot account functionality. (→ S2-7)

• V2.19: Verify there are no default passwords in use for the application framework or any components used by the application (such as “admin/password”). (→ S2-8)

• V2.20: Verify that anti-automation is in place to prevent breached credential testing, brute forcing, and account lockout attacks. (→ S2-12)

• V2.22: Verify that forgotten password and other recovery paths use a TOTP or other soft token, mobile push, or other offline recovery mechanism. Use of a random value in an e-mail or SMS should be a last resort and is known weak. (→ S2-13)

• V2.24: Verify that if shared knowledge based questions (also known as "secret questions") are required, the questions do not violate privacy laws and are sufficiently strong to protect accounts from malicious recovery. (→ S2-14)

• V2.27: Verify that measures are in place to block the use of commonly chosen passwords and weak passphrases. (→ S2-15)

Handled by Solution S3.

• V3.1 Verify that there is no custom session manager, or that the custom session manager is resistant against all common session management attacks. (→ S3-1)

• V3.2 Verify that sessions are invalidated when the user logs out. (→ S3-2)

• V3.3 Verify that sessions timeout after a specified period of inactivity. (→ S3-3)

• V3.5 Verify that all pages that require authentication to access them have logout links. (→ S3-4)

• V3.6 Verify that the session id is never disclosed in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies. (→ S3-5)

• V3.7 Verify that all successful authentication and re-authentication generates a new session and session id. (→ S3-6)

• V3.12 Verify that session ids stored in cookies have their path set to an appropriately restrictive value for the application, and authentication session tokens additionally set the “HttpOnly” and “secure” attributes. (→ S3-7)

• V3.16 Verify that the application limits the number of active concurrent sessions. (→ S3-8)

• V3.17 Verify that an active session list is displayed in the account profile or similar of each user. The user should be able to terminate any active session. (→ S3-9)

• V3.18 Verify the user is prompted with the option to terminate all other active sessions after a successful change password process. (→ S3-10)

Handled by Solution S4.

• V4.1 Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. (→ S4-1, S4-2)

• V4.4 Verify that access to sensitive records is protected, such that only authorized objects or data is accessible to each user (for example, protect against users tampering with a parameter to see or alter another user’s account). (→ S4-3)

• V4.5 Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders. (→ S4-4)

• V4.8 Verify that access controls fail securely. (→ S4-5)

• V4.9 Verify that the same access control rules implied by the presentation layer are enforced on the server side. (→ S4-6)

• V4.13 Verify that the application or framework uses strong random anti-CSRF tokens or has another transaction protection mechanism. (→ S4-7)

• V4.16 Verify that the application correctly enforces context-sensitive authorisation so as to not allow unauthorised manipulation by means of parameter tampering. (→ S4-8)

Handled by Solution S5

• V5.1 Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows. (→ S5-1)

• V5.3 Verify that server side input validation failures result in request rejection and are logged. (→ S5-2)

• V5.5 Verify that input validation routines are enforced on the server side. (→ S5-3)

• V5.10 Verify that all SQL queries, HQL, OSQL, NOSQL and stored procedures, calling of stored procedures are protected by the use of prepared statements or query parametrization, and thus not susceptible to SQL injection. (→ S5-4)

• V5.11 Verify that the application is not susceptible to LDAP Injection, or that security controls prevent LDAP Injection. (→ S5-5)

• V5.12 Verify that the application is not susceptible to OS Command Injection, or that security controls prevent OS Command Injection. (→ S5-6)

• V5.13 Verify that the application is not susceptible to Remote File Inclusion (RFI) or Local File Inclusion (LFI) when content is used that is a path to a file. (→ S5-10)

• V5.14 Verify that the application is not susceptible to common XML attacks, such as XPath query tampering, XML External Entity attacks, and XML injection attacks. (→ S5-7, S5-8)

• V5.15 Ensure that all string variables placed into HTML or other web client code is either properly contextually encoded manually, or utilize templates that automatically encode contextually to ensure the application is not susceptible to reflected, stored and DOM Cross-Site Scripting (XSS) attacks. (→ S5-9)

• V5.22 Make sure untrusted HTML from WYSIWYG editors or similar are properly sanitized with an HTML sanitizer and handle it appropriately according to the input validation task and encoding task. (→ S5-9)

Handled by Solution S6

• V7.2 Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable oracle padding. (→ S6-1)

• V7.7 Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard. (→ S6-2)

Handled by Solution S7

• V8.1 Verify that the application does not output error messages or stack traces containing sensitive data that could assist an attacker, including session id, software/framework versions and personal information. (→ S7-1)

• V8.13 Time sources should be synchronized to ensure logs have the correct time. (→ S7-2)

Handled by Solution S8 * V9.1 Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features. (→ S8-1) * V9.3 Verify that all sensitive data is sent to the server in the HTTP message body or headers (i.e., URL parameters are never used to send sensitive data). (→ S8-2) * V9.4 Verify that the application sets appropriate anti-caching headers as per the risk of the application, such as the following: Expires: Tue, 03 Jul 2001 06:00:00 GMT ; Last-Modified: {now} GMT ; Cache-Control: no-store, no-cache, must-revalidate, max-age=0 ; Cache-Control: post-check=0, pre-check=0 ; Pragma: no-cache. (→ S8-3) * V9.9 Verify that data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII. (→ S8-4)

Handled by Solution S9

• V10.1 Verify that a path can be built from a trusted CA to each Transport Layer Security (TLS) server certificate, and that each server certificate is valid. (→ S9-1)

• V10.3 Verify that TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions, and does not fall back to insecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm. (→ S9-2)

• V10.11 Verify that HTTP Strict Transport Security headers are included on all requests and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains. (→ S9-3)

• V10.13 Ensure forward secrecy ciphers are in use to mitigate passive attackers recording traffic. (→ S9-4)

• V10.14 Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. (→ S9-5)

• V10.15 Verify that only strong algorithms, ciphers, and protocols are used, through all the certificate hierarchy, including root and intermediary certificates of your selected certifying authority. (→ S9-6)

• V10.16 Verify that the TLS settings are in line with current leading practice, particularly as common configurations, ciphers, and algorithms become insecure. (→ S9-7)

Handled by Solution S10

• V11.1 Verify that the application accepts only a defined set of required HTTP request methods, such as GET and POST are accepted, and unused methods (e.g. TRACE, PUT, and DELETE) are explicitly blocked. (→ S10-1)

• V11.2 Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1). (→ S10-2)

• V11.5 Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components. (→ S10-3)

• V11.6 Verify that all API responses contain X-Content-Type-Options: nosniff and Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content type). (→ S10-4)

• V11.7 Verify that a content security policy (CSPv2) is in place that helps mitigate common DOM, XSS, JSON, and JavaScript injection vulnerabilities. (→ S10-5)

• V11.8 Verify that the X-XSS-Protection: 1; mode=block header is in place. (→ S10-6)

Handled by Solution S11

• V16.1 Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content. (→ S11-1)

• V16.2 Verify that untrusted file data submitted to the application is not used directly with file I/O commands, particularly to protect against path traversal, local file include, file mime type, and OS command injection vulnerabilities. (→ S11-2)

• V16.3 Verify that files obtained from untrusted sources are validated to be of expected type and scanned by antivirus scanners to prevent upload of known malicious content. (→ S11-3)

• V16.4 Verify that untrusted data is not used within inclusion, class loader, or reflection capabilities to prevent remote/local file inclusion vulnerabilities. (→ S11-4)

• V16.5 Verify that untrusted data is not used within cross-domain resource sharing (CORS) to protect against arbitrary remote content. (→ S11-5)

• V16.8 Verify the application code does not execute uploaded data obtained from untrusted sources. (→ S11-6)

• V16.9 Do not use Flash, Active-X, Silverlight, NACL, client-side Java or other client side technologies not supported natively via W3C browser standards. (→ S11-7)

Partially handled by Solution S12

• V18.1 Verify that the same encoding style is used between the client and the server. (→ S12-1)

• V18.2 Verify that access to administration and management functions within the Web Service Application is limited to web service administrators. (→ S12-2)

• V18.3 Verify that XML or JSON schema is in place and verified before accepting input. (→ S12-3)

• V18.4 Verify that all input is limited to an appropriate size limit. (→ S12-4)

• V18.5 Verify that SOAP based web services are compliant with Web Services-Interoperability (WS-I) Basic Profile at minimum. This essentially means TLS encryption. (→ S12-5)

• V18.6 Verify the use of session-based authentication and authorization. Please refer to sections 2, 3 and 4 for further guidance. Avoid the use of static "API keys" and similar. (→ S2, S3, S4)

• V18.7 Verify that the REST service is protected from Cross-Site Request Forgery via the use of at least one or more of the following: ORIGIN checks, double submit cookie pattern, CSRF nonces, and referrer checks. (→ S4-7)

Handled by Solution S13

• V19.1 All components should be up to date with proper security configuration(s) and version(s). This should include removal of unneeded configurations and folders such as sample applications, platform documentation, and default or example users. (→ S13-1)