|
|
|
# Architecture
|
|
|
|
Verify that all application components are identified and are known to be needed.
|
|
|
|
Verify that all components, such as libraries, modules, and external systems, that are not part of the application but that the application relies on to operate are identified.
|
|
|
|
Verify that a high-level architecture for the application has been defined.
|
|
|
|
Verify all security controls (including libraries that call external security services) have a centralized implementation.
|
|
|
|
Verify that components are segregated from each other via a defined security control, such as network segmentation, firewall rules, or cloud based security groups.
|
|
|
|
Verify the application has a clear separation between the data layer, controller layer and the display layer, such that security decisions can be enforced on trusted systems.
|
|
|
|
Verify that there is no sensitive business logic, secret keys or other proprietary information in client side code.
|
|
|
|
Verify that all application components, libraries, modules, frameworks, platform, and operating systems are free from known vulnerabilities.
|
|
|
|
|
|
|
|
# Auth
|
|
|
|
Verify all pages and resources by default require authentication except those specifically intended to be public (Principle of complete mediation).
|
|
|
|
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.
|
|
|
|
Verify all authentication controls are enforced on the server side.
|
|
|
|
Verify all authentication controls fail securely to ensure attackers cannot log in.
|
|
|
|
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.
|
|
|
|
Verify that all authentication decisions can be logged, without storing sensitive session identifiers or passwords. This should include requests with relevant metadata needed for security investigations.
|
|
|
|
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.
|
|
|
|
Verify that information enumeration is not possible via login, password reset, or forgot account functionality.
|
|
|
|
Verify there are no default passwords in use for the application framework or any components used by the application (such as “admin/password”).
|
|
|
|
Verify that anti-automation is in place to prevent breached credential testing, brute forcing, and account lockout attacks.
|
|
|
|
Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a protected location.
|
|
|
|
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.
|
|
|
|
Verify that account lockout is divided into soft and hard lock status, and these are not mutually exclusive. If an account is temporarily soft locked out due to a brute force attack, this should not reset the hard lock status.
|
|
|
|
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.
|
|
|
|
Verify that risk based re-authentication, two factor or transaction signing is in place for high value transactions.
|
|
|
|
Verify that if an application allows users to authenticate, they can authenticate using two-factor authentication or other strong authentication, or any similar scheme that provides protection against username + password disclosure.
|
|
|
|
Verify that administrative interfaces are not accessible to untrusted parties.
|
|
|
|
|
|
|
|
# Session management
|
|
|
|
Verify that there is no custom session manager, or that the custom session manager is resistant against all common session management attacks.
|
|
|
|
Verify that sessions are invalidated when the user logs out.
|
|
|
|
Verify that all pages that require authentication have easy and visible access to logout functionality.
|
|
|
|
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.
|
|
|
|
Verify that all successful authentication and reauthentication generates a new session and session id.
|
|
|
|
Verify that only session ids generated by the application framework are recognized as active by the application.
|
|
|
|
Verify that session ids are sufficiently long, random and unique across the correct active session base.
|
|
|
|
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
|
|
|
|
Verify that the application limits the number of active concurrent sessions
|
|
|
|
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.
|
|
|
|
|
|
|
|
# Access control
|
|
|
|
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.
|
|
|
|
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).
|
|
|
|
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.
|
|
|
|
Verify that access controls fail securely.
|
|
|
|
Verify that the same access control rules implied by the presentation layer are enforced on the server side.
|
|
|
|
Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.
|
|
|
|
Verify that all access control decisions can be logged and all failed decisions are logged.
|
|
|
|
Verify that the application or framework uses strong random anti-CSRF tokens or has another transaction protection mechanism.
|
|
|
|
Verify that the application correctly enforces contextsensitive authorisation so as to not allow unauthorised manipulation by means of parameter tampering.
|
|
|
|
|
|
|
|
# Malicious input
|
|
|
|
Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.
|
|
|
|
Verify that server side input validation failures result in request rejection and are logged.
|
|
|
|
Verify that input validation routines are enforced on the server side.
|
|
|
|
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 parameterization, and thus not susceptible to SQL injection
|
|
|
|
Verify that the application is not susceptible to LDAP Injection, or that security controls prevent LDAP Injection.
|
|
|
|
Verify that the application is not susceptible to OS Command Injection, or that security controls prevent OS Command Injection.
|
|
|
|
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.
|
|
|
|
Verify that the application is not susceptible to common XML attacks, such as XPath query tampering, XML External Entity attacks, and XML injection attacks.
|
|
|
|
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.
|
|
|
|
If the application framework allows automatic mass parameter assignment (also called automatic variable binding) from the inbound request to a model, verify that security sensitive fields such as “accountBalance”, “role” or “password” are protected from malicious automatic binding
|
|
|
|
Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, environment, etc.)
|
|
|
|
Verify that client side validation is used as a second line of defense, in addition to server side validation.
|
|
|
|
"Verify that all input data is validated, not only HTML form
|
|
|
|
fields but all sources of input such as REST calls, query
|
|
|
|
parameters, HTTP headers, cookies, batch files, RSS feeds, etc;
|
|
|
|
using positive validation (whitelisting), then lesser forms of
|
|
|
|
validation such as greylisting (eliminating known bad strings),
|
|
|
|
or rejecting bad inputs (blacklisting).
|
|
|
|
Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as validating suburbs and zip or post codes match).
|
|
|
|
Verify that unstructured data is sanitized to enforce generic safety measures such as allowed characters and length, and characters potentially harmful in given context should be escaped (e.g. natural names with Unicode or apostrophes, such as ねこ or O'Hara)
|
|
|
|
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.
|
|
|
|
For auto-escaping template technology, if UI escaping is disabled, ensure that HTML sanitization is enabled instead.
|
|
|
|
Verify that data transferred from one DOM context to another, uses safe JavaScript methods, such as using .innerText and .val.
|
|
|
|
Verify that authenticated data is cleared from client storage, such as the browser DOM, after the session is terminated.
|
|
|
|
|
|
|
|
# Crypto
|
|
|
|
Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable oracle padding.
|
|
|
|
Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module’s approved random number generator when these random values are intended to be not guessable by an attacker.
|
|
|
|
Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard.
|
|
|
|
Verify that there is an explicit policy for how cryptographic keys are managed (e.g., generated, distributed, revoked, and expired). Verify that this key lifecycle is properly enforced.
|
|
|
|
Personally Identifiable Information should be stored encrypted at rest and ensure that communication goes via protected channels.
|
|
|
|
Verify that sensitive passwords or key material maintained in memory is overwritten with zeros as soon as it no longer required, to mitigate memory dumping attacks.
|
|
|
|
Verify that all keys and passwords are replaceable, and are generated or replaced at installation time.
|
|
|
|
|
|
|
|
# Error handling and logging
|
|
|
|
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
|
|
|
|
Verify that error handling logic in security controls denies access by default.
|
|
|
|
Verify security logging controls provide the ability to log success and particularly failure events that are identified as security-relevant
|
|
|
|
Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens.
|
|
|
|
Verify that all events that include untrusted data will not execute as code in the intended log viewing software.
|
|
|
|
Verify that security logs are protected from unauthorized access and modification.
|
|
|
|
Verify that the application does not log sensitive data as defined under local privacy laws or regulations, organizational sensitive data as defined by a risk assessment, or sensitive authentication data that could assist an attacker, including user’s session identifiers, passwords, hashes, or API tokens.
|
|
|
|
Time sources should be synchronized to ensure logs have the correct time
|
|
|
|
|
|
|
|
# Data protection
|
|
|
|
Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features.
|
|
|
|
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).
|
|
|
|
Verify that the application sets appropriate anti-caching headers as per the risk of the application, such as the following:
|
|
|
|
Verify that on the server, all cached or temporary copies of sensitive data stored are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data.
|
|
|
|
Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.
|
|
|
|
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.
|
|
|
|
Verify accessing sensitive data is logged, if the data is collected under relevant data protection directives or where logging of accesses is required.
|
|
|
|
Verify that sensitive information maintained in memory is overwritten with zeros as soon as it no longer required, to mitigate memory dumping attacks.
|
|
|
|
|
|
|
|
# Communication
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Verify that all connections to external systems that involve sensitive information or functions are authenticated
|
|
|
|
Verify that TLS certificate public key pinning (HPKP) is implemented with production and backup public keys.
|
|
|
|
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
|
|
|
|
Ensure forward secrecy ciphers are in use to mitigate passive attackers recording traffic.
|
|
|
|
Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.
|
|
|
|
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.
|
|
|
|
Verify that the TLS settings are in line with current leading practice, particularly as common configurations, ciphers, and algorithms become insecure.
|
|
|
|
|
|
|
|
# HTTP Security
|
|
|
|
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.
|
|
|
|
Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1).
|
|
|
|
Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.
|
|
|
|
Verify that a suitable X-FRAME-OPTIONS header is in use for sites where content should not be viewed in a 3rd-party X-Frame.
|
|
|
|
Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
|
|
|
|
Verify that all API responses contain X-ContentType-Options: nosniff and Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content type).
|
|
|
|
Verify that a content security policy (CSPv2) is in place that helps mitigate common DOM, XSS, JSON, and JavaScript injection vulnerabilities.
|
|
|
|
Verify that the X-XSS-Protection: 1; mode=block header is in place to enable browser reflected XSS filters.
|
|
|
|
|
|
|
|
# Bussines logic
|
|
|
|
Verify the application will only process business logic flows in sequential step order, with all steps being processed in realistic human time, and not process out of order, skipped steps, process steps from another user, or too quickly submitted transactions
|
|
|
|
Verify the application has business limits and correctly enforces on a per user basis, with configurable alerting and automated reactions to automated or unusual attack.
|
|
|
|
|
|
|
|
# Resources
|
|
|
|
"Verify that URL redirects and forwards only allow
|
|
|
|
whitelisted destinations, or show a warning when
|
|
|
|
redirecting to potentially untrusted content.
|
|
|
|
"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.
|
|
|
|
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.
|
|
|
|
Verify that untrusted data is not used within inclusion, class loader, or reflection capabilities to prevent remote/local file inclusion vulnerabilities.
|
|
|
|
Verify that untrusted data is not used within crossdomain resource sharing (CORS) to protect against arbitrary remote content.
|
|
|
|
Verify that files obtained from untrusted sources are stored outside the webroot, with limited permissions, preferably with strong validation.
|
|
|
|
Verify that the web or application server is configured by default to deny access to remote resources or systems outside the web or application server.
|
|
|
|
Verify the application code does not execute uploaded data obtained from untrusted sources.
|
|
|
|
|
|
|
|
# Mobile
|
|
|
|
Verify that ID values stored on the device and retrievable by other applications, such as the UDID or IMEI number are not used as authentication tokens.
|
|
|
|
Verify that the mobile app does not store sensitive data onto potentially unencrypted shared resources on the device (e.g. SD card or shared folders).
|
|
|
|
Verify that sensitive data is not stored unprotected on the device, even in system protected areas such as key chains.
|
|
|
|
Verify that secret keys, API tokens, or passwords are dynamically generated in mobile applications.
|
|
|
|
Verify that the mobile app prevents leaking of sensitive information (for example, screenshots are saved of the current application as the application is backgrounded or writing sensitive information in console).
|
|
|
|
Verify that the application is requesting minimal permissions for required functionality and resources.
|
|
|
|
Verify that the application sensitive code is laid out unpredictably in memory (For example ASLR).
|
|
|
|
Verify that the app does not export sensitive activities, intents, or content providers for other mobile apps on the same device to exploit.
|
|
|
|
Verify that sensitive information maintained in memory is overwritten with zeros as soon as it no longer required, to mitigate memory dumping attacks.
|
|
|
|
Verify that the app validates input to exported activities, intents, or content providers.
|
|
|
|
|
|
|
|
# Web
|
|
|
|
Verify that the same encoding style is used between the client and the server.
|
|
|
|
Verify that access to administration and management functions within the Web Service Application is limited to web service administrators.
|
|
|
|
Verify that all input is limited to an appropriate size limit.
|
|
|
|
Verify that SOAP based web services are compliant with Web Services-Interoperability (WS-I) Basic Profile at minimum. This essentially means TLS encryption.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Verify the REST service explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.
|
|
|
|
Verify that the message payload is signed to ensure reliable transport between client and service, using JSON Web Signing or WS-Security for SOAP requests.
|
|
|
|
Verify that alternative and less secure access paths do not exist.
|
|
|
|
|
|
|
|
# Configuration
|
|
|
|
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.
|
|
|
|
Communications between components, such as between the application server and the database server, should be encrypted, particularly when the components are in different containers or on different systems.
|
|
|
|
Communications between components, such as between the application server and the database server should be authenticated using an account with the least necessary privileges
|
|
|
|
Verify application deployments are adequately sandboxed, containerized or isolated to delay and deter attackers from attacking other applications.
|
|
|
|
Verify that the application build and deployment processes are performed in a secure fashion. |
|
|
\ No newline at end of file |